Db2 高可用性災害時リカバリー (HADR) コマンド

Db2 高可用性災害時リカバリー (HADR) フィーチャーは、 Db2 高可用性データベース・ソリューションの複雑なロギング、フェイルオーバー、およびリカバリー機能を提供します。 HADR が提供する機能は複雑なものですが、HADR コマンドを直接実行する必要があるアクションはごくわずかです。HADR を開始すること、HADR を停止すること、およびスタンバイ・データベースに 1 次データベースをテークオーバーさせることだけです。

HADR の管理に使用される高可用性災害時リカバリー (HADR) コマンドは以下の 3 つです。

START HADR
STOP HADR
TAKEOVER HADR

これらのコマンドを呼び出すには、コマンド行プロセッサーまたは管理 API を使用します。

AS PRIMARY または AS STANDBY オプションを指定して START HADR コマンドを発行すると、データベースがまだそのロールに含まれていない場合は、データベースのロールが指定されたロールに変更されます。また、このコマンドを発行すると、データベースがまだアクティブでない場合、アクティブになります。

STOP HADR コマンドは、HADR データベース (1 次またはスタンバイ) を標準データベースに変更します。 HADR に関連したデータベース構成パラメーターがあれば、データベースを HADR データベースとして再度アクティブにしやすいように、未変更のまま残されます。

TAKEOVER HADR コマンドはスタンバイ・データベースでのみ発行可能で、スタンバイ・データベースを 1 次データベースに変更します。 BY FORCE オプションを指定しないと、1 次データベースとスタンバイ・データベースの役割が切り替わります。 BY FORCE オプションを指定すると、一方的にスタンバイ・データベースが 1 次データベースに切り替わります。この場合、スタンバイ・データベースは古い 1 次データベース上でのトランザクション処理を停止しようと試みます。しかし、トランザクション処理が停止するという保証はありません。 BY FORCE オプションを使用して強制的にテークオーバー操作を実行するのは、フェイルオーバー状態の場合だけにしてください。可能な限り、 BY FORCE オプションを指定して TAKEOVER HADR コマンドを発行する前に、現行の 1 次が確実に失敗したことを確認するか、自分でシャットダウンしてください。

HADR データベース役割の切り替え

データベースの 1 次役割と標準役割との間の切り替えは、動的に、かつ繰り返し行うことができます。データベースがオンラインとオフラインのどちらであっても、START HADR コマンドに AS PRIMARY オプションを指定して発行することと、STOP HADR コマンドを発行することの両方が可能です。

データベースのスタンバイ役割と標準役割との間の切り替えは、静的に行うことができます。これを繰り返し行えるのは、データベースがロールフォワード・ペンディング状態に留まる場合だけです。データベースがオフラインで、ロールフォワード・ペンディング状態である場合、START HADR コマンドに AS STANDBY オプションを指定して発行し、標準データベースをスタンバイに変更することができます。データベースがオフラインの場合にスタンバイ・データベースを標準データベースに変更するには、STOP HADR コマンドを使用します。 STOP HADR コマンドを発行した後も、データベースはロールフォワード・ペンディング状態のままです。 AS STANDBY オプションを指定して後続の START HADR コマンドを発行すると、データベースはスタンバイに戻ります。スタンバイ・データベースで HADR を停止した後に STOP オプションを指定して ROLLFORWARD DATABASE コマンドを発行すると、スタンバイに戻すことはできません。データベースはロールフォワード・ペンディング状態ではなくなったので、これを標準データベースとして使用できます。これを、スタンバイ・データベースのスナップショットを取ると言います。既存のスタンバイ・データベースを標準データベースに変更した後は、高可用性を目的として新しいスタンバイ・データベースを作成することを考慮してください。

1 次データベースの役割とスタンバイ・データベースの役割を切り替えるには、BY FORCE オプションを指定しないでテークオーバー操作を実行します。

一方的にスタンバイを 1 次に変更する (1 次をスタンバイに変更しない) 場合、強制テークオーバーを使用します。その後、古い 1 次を新しいスタンバイとして再統合できるかもしれません。

HADR 役割は永続的です。 HADR 役割は一度確立されると、Db2 インスタンスの停止や開始、または Db2 データベースの非アクティブ化およびアクティブ化が繰り返されても、データベースに残ります。

スタンバイの開始は非同期

START HADR コマンドに AS STANDBY オプションを指定して発行した場合、関連するエンジン・ディスパッチ可能単位 (EDU) が正常に開始されるとすぐに、そのコマンドは戻ります。コマンドはスタンバイが 1 次データベースに接続するのを待機しません。対照的に 1 次データベースは、スタンバイ・データベースに接続するまで、開始されたとは見なされません (START HADR コマンドに BY FORCE オプションを指定して、1 次データベースに発行した場合を除く)。 1 次データベースによって接続が拒否されるなどのエラーがスタンバイ・データベースで発生した場合は、 AS STANDBY オプションを指定した START HADR コマンドが既に正常に返されている可能性があります。その結果、HADR がエラー表示を戻すことのできるユーザー・プロンプトがないということになります。 HADR スタンバイは、Db2 診断ログにメッセージを書き込み、シャットダウンします。 HADR スタンバイの状況をモニターして、正常に HADR 1 次と接続したことを確認する必要があります。

再生エラー (ログ・レコードの再生中にスタンバイで発生するエラー) も、スタンバイ・データベースをダウンさせる場合があります。これらのエラーは、例えばバッファー・プールを作成するのに十分なメモリーがない場合、または表スペース作成中にパスが見つからない場合などに発生することがあります。スタンバイ・データベースの状況を、継続してモニターすることが必要です。

クライアント・リルート可能なデータベース別名を使用してクライアントから HADR コマンドを実行しない

自動クライアント・リルートがセットアップされている場合、データベース・サーバーは、事前定義された代替サーバーを持ちます。これは、クライアント・アプリケーションが元のデータベース・サーバーと代替サーバーとの間で作業を切り替えて、作業の中断を最低限で済ませるためです。そのような環境でクライアントが TCP を介してデータベースに接続すると、実際の接続先は、元のデータベースか代替データベースのどちらかになります。 HADR コマンドは、通常のクライアント接続ロジックを介してターゲット・データベースを識別するようインプリメントされます。その結果、ターゲット・データベースで代替データベースが定義されている場合、コマンドが実際に操作しているデータベースを判別することは困難です。 SQL クライアントは接続先のデータベースを知らなくてもかまいませんが、その一方で HADR コマンドは特定のデータベースに対して適用される必要があります。この制限に対処するには、HADR コマンドをサーバー・マシン上でローカルに発行し、クライアント・リルートを回避する必要があります (クライアント・リルートは TCP/IP 接続にしか影響しません)。