Db2 pureScale 環境での高可用性災害時リカバリー (HADR)

Db2 高可用性災害時リカバリー (HADR) は、優れた連続可用性を提供する Db2 pureScale 環境でサポートされます。 HADR を使用すると、DR (災害復旧) 保護も行えます。 スタンバイ・サイトにデータの第 2 のコピーがあるので、1 次サイトで全面的な障害が生じても保護されます。

Db2 pureScale 環境での HADR の構成と管理は、他の環境での HADR の構成と管理に非常に似ています。 1 次データベースのバックアップ・イメージまたはスプリット・ミラーを使用したリストアによってスタンバイ・データベースを作成し、各種の HADR 構成パラメーターを設定した後、スタンバイ・データベース、次に 1 次データベースの順で HADR を開始します。 役割の切り替えが発生すると、すぐにスタンバイ・データベースが 1 次データベースとしてテークオーバーします。 すべての管理コマンドは、他の環境の HADR で使用する管理コマンドと同じですが、HADR をモニターする場合に使用できるのは、db2pd コマンドと MON_GET_HADR 表関数のみです。 スナップショットなどの他のモニター・インターフェースは、 Db2 pureScale 環境では HADR 情報を報告 しません 。

ただし、 Db2 pureScale 環境では HADR に関して重要な相違点がいくつかあります。 HADR ペアは、1 次クラスターとスタンバイ・クラスターで構成されます。 各クラスターは、複数のメンバーと、少なくとも 1 つの クラスター・キャッシング・ファシリティーで構成されます。メンバー・トポロジーは、2 つのクラスターで同じでなければなりません。 1 次とスタンバイの両方で、 START HADR コマンドの発行元のメンバーが 優先再生メンバーとして指定されます。 データベースがスタンバイとして作動する場合、1 つのメンバー (再生メンバー) だけがアクティブ化されます。 Db2 インスタンスが優先再生メンバー上でオンラインになっている場合、データベースはそのメンバーを再生メンバーとして選択しますが、それ以外の場合には別のメンバーが選択されます。 その再生メンバーがすべてのログを適用し、その他のメンバーはアクティブ化されません。 1 次側の各メンバーとスタンバイ側の現行再生メンバーとの間で HADR TCP 接続が確立されます。 1 次側の各メンバーのログは TCP 接続を介してスタンバイの再生メンバーに配送されます。 HADR スタンバイは、ログ・ストリームをマージして再生します。 スタンバイが 1 次側の特定のメンバー A に接続できない場合 (ネットワーク問題のため、またはメンバーが非アクティブであるため)、スタンバイ側に接続できる 1 次側の別のメンバー B が、メンバー A のログをスタンバイ側に送信します。 この処理は、リモート・キャッチアップ・アシスト と呼ばれます。