Db2 高可用性災害時リカバリー (HADR) データベースの状態

ローカル・キャッチアップ状態

HADR フィーチャーを使用する場合、データベースがスタンバイとして開始されるとローカル・キャッチアップ状態になります。そして、このスタンバイ・データベースのローカル・ログ・パスのログ・ファイルが読み取られて、ローカルで使用可能なログが判別されます。 この状態では、ログ・アーカイブ方式を構成した場合でも、ログはアーカイブからリトリーブされません。 また、この状態では、1 次データベースへの接続は必要ありません。ただし、接続が存在しない場合、 スタンバイ・データベースは 1 次データベースに接続しようとします。 ローカル・ログ・ファイルの最後になったら、スタンバイ・データベースは、 リモート・キャッチアップ・ペンディング状態になります。

リモート・キャッチアップ・ペンディング状態

スタンバイがリモート・キャッチアップ・ペンディング状態になったときに、1 次への接続が確立されていない場合、スタンバイは接続を待機します。 接続が確立された後、スタンバイは 1 次の現在のログ・チェーン情報を取得します。 これにより、ログ・アーカイブを構成した場合に、スタンバイがアーカイブからログ・ファイルをリトリーブし、ログ・ファイルが有効であることを検証できるようになります。

リモート・キャッチアップ状態およびピア状態では、スタンバイは 1 次から切断された場合、リモート・キャッチアップ・ペンディング状態に戻ります。 接続が再確立されると、スタンバイはアーカイブからログをリトリーブしようとします。 したがって、共有アーカイブ装置を構成する場合、スタンバイでは別個のアーカイブ装置を使用する場合より多くの使用可能なログを検出できる可能性があります。 そのため、HADR 接続を介した 1 次データベースからのシッピングよりも、アーカイブを使用したほうが 1 次データベースに与える影響が軽減される可能性があります。

リモート・キャッチアップ状態

リモート・キャッチアップ状態では、1 次データベースはログ・パスから、またはログ・アーカイブ方式によってログ・データを読み取り、ログ・データはスタンバイ・データベースに送信されます。 スタンバイ・データベースが 1 次データベースのディスク上のログ・データをすべて受け取ると、1 次データベースとスタンバイ・データベースはピア状態になります。 SUPERASYNC 同期モードを使用している場合、1 次とスタンバイがピア状態になることはありません。 これらは完全にリモート・キャッチアップ状態になるため、ピア状態での 1 次ログの書き込みがブロックされる可能性がなくなります。

1 次データベースとスタンバイ・データベースがリモート・キャッチアップ状態であるときにそれらのデータベースの間の接続が消失する場合、スタンバイ・データベースは、リモート・キャッチアップ・ペンディング状態になります。

リモート・キャッチアップ・アシスト

リモート・キャッチアップ・アシスト状態は、 Db2 pureScale® 環境の HADR に固有の状態です。

ネットワーク問題や、1 次側のメンバーが非アクティブであることが原因で、スタンバイ再生メンバーが 1 次側のメンバーに直接接続できないこともあります。 この場合、スタンバイ再生メンバーは、スタンバイに接続可能な 1 次側の別のメンバーの支援を受けて、到達不能なメンバーのログを取得します。 この支援する側のメンバー は、支援対象の各メンバーに対して専用 TCP 接続を使用します。 リモート・キャッチアップ・アシスト状態にあるログ・ストリームには間接接続が使用されるため、これらのログ・ストリームがピア状態になることは決してありません。 リモート・キャッチアップ・アシストは、スタンバイ再生メンバーが 1 次側のメンバーに直接接続できるようになると、自動的に終了します。

MON_GET_HADR 表関数または db2pd コマンドを使用すると、メンバーのログ・ストリームがリモート・キャッチアップ・アシスト状態にあるかどうかを判別できます。 1 次側のメンバーの場合、そのログ・ストリームは次のように表示されます。REMOTE_CATCHUP状態、およびHADR_FLAGSフィールドには、ASSISTED_REMOTE_CATCHUPフラグ

ピア状態

ピア状態では、1 次がログ・ページをディスクにフラッシュしたときは常に、ログ・データが 1 次のログ書き込みバッファーから直接スタンバイに送られます。 HADR 同期モードは、ログ・データが受信されたことを示す確認応答メッセージをスタンバイが送信するのを 1 次が待機するかどうかを指定します。 ログ・ページは常にスタンバイ・データベースのローカル・ログ・ファイルに書き込まれます。 古い 1 次にファイルがアーカイブされていない場合、この動作は、テークオーバー時のクラッシュを防ぎ、新しい 1 次にファイルをアーカイブできるようにします。 受信されたログ・ページは、ローカル・ディスクに書き込まれた後、スタンバイ・データベースで再生できます。 ログ・スプーリングが使用不可にされている場合 (デフォルト)、ログの適用では、ログ受信バッファーだけからログが読み取られます。

ログ再生に長い時間がかかる場合、受信バッファー・ログがいっぱいになっている可能性があり、スタンバイでの新規ログの受信は停止します。 この場合、1 次ログの書き込みがブロックされます。 ログ・スプーリングを使用可能にすると、まだ適用されていない部分であってもログ・バッファーの一部が解放されるため、1 次ログの書き込みを続行できます。 その後、ログの適用でディスクからログ・データが読み取られます。 スプーリング装置がいっぱいになっている場合、または構成されたスプール制限に達した場合、スタンバイでの受信は停止したままになり、1 次ログの書き込みは再びブロックされます。

1 次データベースとスタンバイ・データベースがピア状態であるときにそれらのデータベースの間の接続が失われた場合、hadr_peer_window データベース構成パラメーターが 0 (デフォルト) に設定されていると、スタンバイ・データベースはリモート・キャッチアップ・ペンディング状態になります。 ただし、1 次データベースとスタンバイ・データベースがピア状態であるときにそれらのデータベースの間の接続が失われ、hadr_peer_window パラメーターがゼロ以外の値 (ピア・ウィンドウ が構成されていることを意味します) に設定されている場合には、スタンバイ・データベースは切断済みピア状態になります。

切断済みピア状態

ピア・ウィンドウが構成されている場合、ピア状態にある 1 次データベースとスタンバイ・データベースの間の接続が失われると、1 次データベースは、それらのデータベースがピア状態であるかのように動作し続けます。 この動作は、ピア・ウィンドウの満了またはスタンバイ・データベースの再接続のどちらかが先に発生するまで続きます。 1 次データベースとスタンバイ・データベースは切断されているが、ピア状態であるかのように作動する状態を切断済みピア と呼びます。

ピア・ウィンドウを構成する利点は、複数の障害または連鎖する障害の発生時にトランザクションの損失のリスクが低くなることです。 ピア・ウィンドウを使用しない場合、1 次データベースは、スタンバイ・データベースとの接続を失うとすぐにピア状態ではなくなり、トランザクション処理を続行します。 これらのトランザクションはスタンバイに複製されません。 スタンバイとの接続を失った直後に 1 次サーバーで障害が発生した場合、フェイルオーバーでのトランザクションの損失のリスクが高くなります。 ピア・ウィンドウを使用可能にすることで、1 次データベースは、ピア状態でスタンバイへの接続を失った後、一定時間の間、トランザクション処理をブロックして、連鎖する障害から保護します。 また、スタンバイは、データ損失のリスクを伴うことなく、ピア・ウィンドウ内でテークオーバーすることができます。

ピア・ウィンドウを構成することの欠点は、1 次データベースがピア・ウィンドウにあり、スタンバイ・データベースとの接続が復元されるか、ピア・ウィンドウの有効期限が切れるまで待っている間に、1 次データベース上のトランザクションに長い時間がかかり、タイムアウトになることさえあるという点です。 また、断続的なネットワーク障害が 1 次でのトランザクション処理に重大な影響を与える可能性があります。

ピア・ウィンドウ・サイズ ( hadr_peer_window データベース構成パラメーターの値) を判別するには、MON_GET_HADR 表関数を使用するか、 -hadr パラメーターを指定した db2pd コマンドを使用します。

1 次データベースからスタンバイ・データベースへのログ・ファイルの手動によるコピー

1 次データベースおよびスタンバイ・データベースを同期化するための 1 つの方法は、1 次データベースのログ・ファイルをスタンバイ・データベースのログ・パスまたはオーバーフロー・ログ・パス (構成されている場合) に手動でコピーすることです。 例えば、スタンバイ・データベースが長時間停止したことが原因で、1 次データベースとスタンバイ・データベースの間に大きなログ・ギャップがある場合には、手動によるファイルのコピーが特に役立ちます。 手動でファイルをコピーすると、アーカイブからログを取得しなければならないスタンバイ・データベースの遅延や、これらのログ・ファイルをおそらくアーカイブから取得して送らなければならない 1 次データベースへの影響を軽減できます。

このステップは、スタンバイ・データベースをアクティブにする前に行うことが重要です。 スタンバイ・データベースを非アクティブにすると、スタンバイ・データベースは、前述のように、ローカル・ログ・ファイルの検索、アーカイブからのリトリーブ、およびログ・シッピングのための 1 次データベースへの関与を続行します。 スタンバイ・データベースをアクティブにした後にログ・ファイルをコピーすると、スタンバイ・データベースの通常の操作が妨げられる可能性があります。