HADR 遅延再生

HADR 遅延再生は、問題のあるトランザクションによるデータ損失を防ぐのに役立ちます。 HADR 遅延再生を実装するには、HADR スタンバイ・データベースで hadr_replay_delay データベース構成パラメーターを設定します。

遅延再生では、スタンバイ・データベースでログの再生を遅らせることにより、意図的にスタンバイが 1 次データベースより前の時点のものになるようにします。 問題のあるトランザクションが 1 次で実行された場合、構成された遅延時間が経過するまで、問題のあるトランザクションがスタンバイで再生されないように処置を行うことができます。 データ損失をリカバリーするために、このデータを再び 1 次にコピーすることも、スタンバイを新しい 1 次データベースとしてテークオーバーさせることもできます。

遅延再生は、(1 次で生成される) ログ・ストリームのタイム・スタンプとスタンバイの現行時刻を比較することで機能します。 したがって、1 次データベースとスタンバイ・データベースのクロックを同期することが重要です。 トランザクション・コミットは以下の式に従ってスタンバイで再生されます。
(current time on the standby - value of the hadr_replay_delay configuration parameter) >= 
	timestamp of the committed log record
hadr_replay_delay データベース構成パラメーターは、1 次の問題のあるトランザクションを検出して対処するのに十分な大きさの値に設定する必要があります。

この機能は、1 つのスタンバイ、複数のスタンバイ、および Db2® pureScale® 環境で使用できます。 複数スタンバイでは、通常、高可用性または災害時リカバリーのために 1 つ以上のスタンバイを 1 次と同期が取られるようにし、1 つのスタンバイを問題のあるトランザクションから保護するために遅延再生されるように構成します。 この機能を 1 つのスタンバイで使用する場合は、テークオーバーが失敗するため、 IBM® Tivoli® System Automation for Multiplatforms を有効にしないでください。

遅延再生に関する重要な制約事項をいくつか以下に示します。
  • hadr_replay_delay 構成パラメーターはスタンバイ・データベースでのみ設定可能です。
  • 遅延再生を使用可能にしたスタンバイでは、TAKEOVER コマンドは失敗します。 最初に、hadr_replay_delay 構成パラメーターを 0 に設定し、スタンバイを非アクティブにしてから再度アクティブにして新しい値を取得した後で、TAKEOVER コマンドを発行してください。
  • 遅延再生フィーチャーは SUPERASYNC モードの場合のみサポートされています。 ログ再生が遅れるため、スタンバイで多くの未再生ログ・データが累積され、受信バッファーとスプール (構成されている場合) がいっぱいになる可能性があります。 他の同期モードでは、これにより 1 次がブロックされます。

    このフィーチャーの目的は、アプリケーション・エラーから保護することにあります。 このフィーチャーを使用して 1 次で障害が発生したときにデータが失われないようにする場合は、複数スタンバイ・セットアップにおけるプリンシパル・スタンバイの同期設定を増やすことを検討してください。

  • HADR データベースをアップグレードするときの重要な確認ステップとして、1 次のログのシップ位置がスタンバイのログの再生位置と一致することを確認することがあります。 必然的に、スタンバイで再生遅延が構成されていると、この確認ステップが妨げられ、失敗の原因となる可能性があります。 失敗が生じないようにするには、最初に hadr_replay_delay 構成パラメーターを 0 に設定し、スタンバイ・データベースを非アクティブにしてから再度アクティブにして新しい値を取得した後で、アップグレード手順を開始してください。

推奨事項

遅延再生と災害時リカバリー
災害時リカバリーや、問題のあるトランザクションからの保護を目的としてスタンバイ・データベースを使用する場合は、遅延を短くすることを検討してください。
遅延再生と HADR スタンバイ・データベースの読み取りフィーチャー
リーダー・セッションでより最新のデータを確認できるように、スタンバイ・データベースの読み取りのためにスタンバイ・データベースを使用する場合は、遅延を短くすることを検討してください。 さらに、スタンバイでの読み取りは未コミット読み取り分離レベルで実行されるため、適用されているがまだコミットされていない変更を確認でき、再生からの技術遅延がまた発生しています。 これらのコミットされていないトランザクションは、必要な PIT までスタンバイをロールフォワードしてから停止する際に、問題のあるトランザクションのリカバリー手順でロールバックされる可能性があります。
遅延再生とログ・スプーリング
遅延再生を使用可能にする場合には、ログ・スプーリングも使用可能にすることをお勧めします。これは、hadr_spool_limit データベース構成パラメーターを設定することによって行います。 意図的な遅延により、スタンバイでのログの再生位置がログの受信位置よりかなり後になる場合があります。 スプーリングを使用しないと、再生位置を越えた部分のログの受け取りが可能になるのは、受信バッファーの量だけになります。 スプーリングを使用すると、スタンバイは再生位置を超える量のログを受信することができ、1 次で障害が発生した場合のデータ損失に対する保護を強化することができます。 どちらの場合も、SUPERASYNC モードが必須であるため、遅延再生によって 1 次がブロックされることはありません。