Db2 高可用性災害時リカバリー (HADR) のログ・アーカイブ構成

Db2 高可用性災害時リカバリー (HADR) でログ・アーカイブを使用するには、すべてのログ・アーカイブ・ロケーションから自動ログ検索機能が実行できるように 1 次データベースとスタンバイ・データベースの両方を構成します。 複数スタンバイ・システムの場合は、1 次データベースとすべてのスタンバイ・データベースでアーカイブを構成します。

現在の 1 次データベースだけがログ・アーカイブを実行できます。 セットアップされたアーカイブ・ロケーションが 1 次データベースとスタンバイ・データベースで別々の場合、ログは 1 次データベースのアーカイブ・ロケーションにしかアーカイブされません。 テークオーバーが行われると、スタンバイ・データベースが新しい 1 次データベースになります。その時以降アーカイブされるログは、元のスタンバイ・データベースのアーカイブ・ロケーションに保管されます。 このような構成の場合、ログのアーカイブ先は一方のロケーションかもう一方のロケーションのどちらかであり、両方にアーカイブされることはありません。ただし、すでに元の 1 次データベースがアーカイブを済ませたいくつかのログを、テークオーバーの後で新しい 1 次データベースがアーカイブする場合は別です。 複数スタンバイ・システムでは、アーカイブ・ログ・ファイルをすべてのデータベース (1 次とスタンバイ) のアーカイブ装置間で分散できます。 すべてのファイルが 1 つの場所に保管されるため、共有アーカイブが推奨されます。

多くの操作で、アーカイブ・ログ・ファイルのリトリーブを行う必要があります。 これらの操作には、データベースのロールフォワード、リモート・キャッチアップで HADR のスタンバイ・データベースに送るログ・ファイルの 1 次データベースでのリトリーブ、およびレプリケーション・プログラム (Q レプリケーションなど) によるログの読み取りがあります。 そのため、HADR システムの共有アーカイブが推奨されます。それ以外の場合は、必要なファイルを複数のアーカイブ装置に分散でき、必要なファイルを見つけて要求元のデータベースにコピーするためにユーザー介入が必要になります。 コピー先として、アーカイブ装置が推奨されます。 アーカイブにコピーできない場合は、ログをオーバーフロー・ログ・パスにコピーします。 最後の手段として、ログをログ・パスにコピーする方法がありますが、アクティブ・ログ・ファイルが損傷するリスクがあることに注意してください。 Db2 では、オーバーフロー・ログ・パスとアクティブ・ログ・パスにユーザーがコピーしたファイルが自動的に削除されないため、HADR のスタンバイやアプリケーションで必要なくなった場合に、手動でファイルを削除する必要があります。

特定のシナリオとして、複数の HADR スタンバイを使用したテークオーバーがあります。 テークオーバーの後、あるスタンバイが以前のログ位置にあることが原因で、他のスタンバイで必要なログ・ファイルの一部が新しい 1 次に含まれていない場合があります。 1 次は、要求されたログ・ファイルを検出できない場合、スタンバイに通知します。これにより、スタンバイは接続をクローズしてから数秒で再接続し、再試行します。 再試行期間は数分に制限されます。 再試行時間が過ぎると、スタンバイはシャットダウンします。 この場合、1 次にファイルをコピーして、最初の欠落ファイルから現在のログ・ファイルまでのファイルがあることを確認します。 ファイルがコピーされたら、必要に応じてスタンバイを再始動してください。

スタンバイ・データベースはそのログ・パスにあるログ・ファイルを自動的に管理します。 スタンバイ・データベースは、1 次データベースがログ・ファイルをアーカイブしたという通知を 1 次データベースから受けるまでは、自分のローカル・ログ・パスからログ・ファイルを削除しません。 この動作は、ログ・ファイルの消失に対して付加的な保護を提供します。 特定のログ・ファイルが 1 次データベースにアーカイブされる前に 1 次データベースに障害が起き、ログ・ディスクが破損した場合、スタンバイ・データベースは自分のディスクからそのログ・ファイルを削除しません。なぜなら、正常にログ・ファイルをアーカイブしたという通知を 1 次データベースから受け取っていないからです。 その後スタンバイ・データベースが新しい 1 次データベースとしてテークオーバーすると、スタンバイ・データベースはリサイクルの前にそのログ・ファイルをアーカイブします。 logarchmeth1 および logarchmeth2 構成パラメーターの両方を使用している場合、1 次データベースが両方の方式でログ・ファイルをアーカイブするまで、スタンバイ・データベースはそのログ・ファイルをリサイクルしません。

以前にリストした利点に加え、共有ログ・アーカイブ装置は、スタンバイ・データベースが、リモート・キャッチアップ状態で 1 次を介して間接的に古いログ・ファイルをリトリーブするのではなく、ローカル・キャッチアップ状態でアーカイブからそれらのファイルを直接リトリーブできるようにすることで、キャッチアップ処理を改善します。 ただし、磁気テープ・ドライブのようなシリアルのアーカイブ装置は、HADR データベースに 使用しないように推奨します。 シリアル装置では、読み取り操作と書き込み操作が混在するため、 1 次データベースとスタンバイ・データベースの両方で性能低下が生じる可能性があります。 1 次データベースはログ・ファイルをアーカイブする際に装置への書き込みを行い、 スタンバイ・データベースは装置から読み取りを行ってログを適用します。 共有するように装置を構成していない場合でも、パフォーマンスへの影響は生じる可能性があります。

拡張ログ・スペース管理 (ALSM)を使用するように構成されている場合は、1 次データベースとスタンバイ・データベースの間で共有アーカイブを使用することをお勧めします。 まれではありますが、(例えば、ディスク・エラーなどのために) 抽出ログ・ファイルを使用できない場合に、既にアーカイブされたログ・ファイルがアーカイブから取得され、適用またはロールバックに使用されるようになります。 アーカイブされたログ・ファイルにアクセスできない場合、操作は失敗し、ユーザーの手動による介入が必要になります。

Tivoli Storage Manager での共有ログ・アーカイブ

IBM® Tivoli® Storage Manager (TSM) で共有ログ・アーカイブを使用すると、1 つ以上のノードを TSM サーバーに対して単一ノードとして認識させることができます。これは、いずれかのマシンを任意の時点で 1 次とすることができる HADR 環境で特に有用です。

共有ログ・アーカイブをセットアップするには、プロキシー・ノードを使用する必要があります。このノードを使用すると、TSM クライアント・ノードは、TSM サーバー上の集中管理ネーム・スペースに対してデータ保護操作を実行できます。 ターゲット・クライアント・ノードがデータを所有し、エージェント・ノードがターゲット・ノードに代わってバックアップ・データを管理します。 プロキシー・ノード・ターゲットは、分散データのバックアップ・バージョンが関連付けられている TSM サーバー上で定義されているノード名です。 このデータは、TSM サーバー上の単一ネーム・スペースで、まったくこのノード用のデータであるかのように管理されます。 プロキシー・ノード・ターゲット名は実ノード (いずれかのアプリケーション・ホストなど) にすることも、仮想ノード名 (つまり、物理ノードには対応しないノード名) にすることもできます。 仮想プロキシー・ノード名を作成するには、TSM サーバーで以下のコマンドを使用します。
  Grant proxynode target=virtual-node-name agent=HADR-primary-name
  Grant proxynode target=virtual-node-name agent=HADR-standby-name
次に、1 次データベースとスタンバイ・データベースで、以下のデータベース構成パラメーターを virtual-node-name に設定する必要があります。
  • vendoropt
  • logarchopt
複数スタンバイ・セットアップでは、TSM サーバー上ですべてのマシンに対して proxynode 権限を付与し、すべてのスタンバイで vendoropt 構成パラメーターと logarchopt 構成パラメーターを設定する必要があります。