高可用性災害時リカバリー用のデータベース構成 (HADR)

データベース構成パラメーターを使用すると、 Db2® HADR で最適なパフォーマンスを実現できます。

通常、1 次データベースが置かれているシステムとスタンバイ・データベースが置かれているシステムのデータベース構成パラメーターおよびデータベース・マネージャー構成パラメーターには、同じ設定を使用します。スタンバイ・データベースの構成パラメーターの設定が 1 次の設定と異なる場合、以下の問題が発生する可能性があります。

1 次データベースから送られたログ・ファイルの再生中に、スタンバイ・データベースにエラー・メッセージが戻されることがあります。
テークオーバー操作後に、新しい 1 次データベースはワークロードを処理できない可能性があるため、パフォーマンス上の問題が生じるか、アプリケーションが元の 1 次データベースに接続されていたときには受け取ることのなかったエラー・メッセージを受け取ります。

1 次データベースの構成パラメーターの変更内容は、自動的にスタンバイ・データベースに伝搬されません。スタンバイ・データベースで手動で変更する必要があります。動的構成パラメーターの場合、データベース管理システム (DBMS) またはデータベースをシャットダウンして再始動しなくても、変更は有効になります。動的構成パラメーターではない場合、変更はスタンバイ・データベースの再始動後に有効になります。

以下に、HADR に関する特定の構成トピックのセクションを示します。

スタンバイ・データベースでのログ・ファイルのサイズ構成パラメーター

前の段落で説明した構成パラメーターの動作に関する 1 つの例外として、logfilsiz データベース構成パラメーターの動作があります。このパラメーターの値はスタンバイ・データベースに複製されませんが、両方のデータベースでログ・ファイルが同一になるようにするために、スタンバイの logfilsiz 構成パラメーターの設定は無視されます。代わりに、スタンバイ・データベースでは、1 次データベースのログ・ファイルのサイズと一致するサイズのローカル・ログ・ファイルが作成されます。

テークオーバー後、元のスタンバイ (新しい 1 次) は、元の 1 次で設定された logfilsiz パラメーター値を、データベースを再始動するまで使用します。その時点で、新しい 1 次は、ローカルに設定された値を再び使用します。さらに、新しい 1 次では、現在のログ・ファイルが切り捨てられ、以前に作成されたログ・ファイルのサイズが変更されます。

データベースが非強制テークオーバーの結果として役割の切り替えを維持し、どちらのデータベースも非アクティブにされない場合、使用されるログ・ファイル・サイズは常に元の 1 次データベースのサイズになります。ただし、元のスタンバイ (新しい 1 次) が非アクティブにされてから再始動されると、新しい 1 次ではローカルに構成されたログ・ファイル・サイズが使用されます。元の 1 次が再びテークオーバーする場合、このログ・ファイル・サイズが継続して使用されます。ログ・ファイル・サイズが元の 1 次の設定に戻るのは、元の 1 次の非アクティブ化と再始動が終わってからです。

データベース構成パラメーター autorestart

HADR システムでの autorestart パラメーターの推奨される構成は ON です。 autorestart パラメーターを OFF に設定した場合、サーバーに障害が起きたときの対応は、再始動するかスタンバイへのフェイルオーバーを行うかによって以下のように異なります。

再始動する場合は、RESTART DATABASE コマンドを手動で実行します。再始動が失敗した場合は、フェイルオーバーを実行します。
フェイルオーバーを行う場合は、以下のステップを実行します。
1. 古いプライマリーをシャットダウンして、スプリット脳が発生しないようにします。そのためには、Db2 インスタンスを停止するか、ホスト・マシンの電源をオフにします。管理するためにサーバーにアクセスできない場合は、クライアント/サーバー・ネットワークを使用不可にして、クライアントから分離します。
  注: クライアント接続によってデータベースをオンラインに戻すことができるため、データベースを非アクティブ化するだけでは十分ではありません。整合性のある状態で失敗した場合は、autorestart パラメーターが OFF に設定されているとしても、クライアント接続によってオンラインに戻されることがあります。
2. 古い 1 次をシャットダウンした後、スタンバイで BY FORCE オプションを指定して TAKEOVER HADR コマンドを発行します。

スタンバイ・データベースでのログ受信バッファー・サイズ

デフォルトでは、スタンバイ・データベースでのログ受信バッファー・サイズは、 1 次データベースの logbufsz 構成パラメーターに指定した値の 2 倍です。このサイズでは十分でない可能性があります。例えば、HADR 同期モードが ASYNC に設定されており、1 次データベースとスタンバイ・データベースがピア状態である場合に何が起こり得るかを考えます。また、1 次データベースのトランザクション負荷が高くなっている場合、スタンバイ・データベースのログ受信バッファーの容量がいっぱいになる可能性があり、1 次データベースからのログ・シッピング操作が停止する可能性があります。これらの一時的なピークを管理するために、以下の構成変更のいずれかを行うことができます。

DB2_HADR_BUF_SIZE レジストリー変数の値を変更して、スタンバイ・データベースのログ受信バッファーのサイズを増やします。
hadr_spool_limit 構成パラメーターを設定して、スタンバイ・データベースでログ・スプーリングを有効にする。

ロード操作および HADR

COPY YES パラメーターを指定して 1 次データベースに対して LOAD コマンドを発行すると、コマンドは 1 次データベースで実行され、コマンドによって指定されたパスまたはデバイスを介してロード・コピーにアクセスできる場合は、スタンバイ・データベースにデータが複製されます。スタンバイ・データベースからロード・コピー・データにアクセスできない場合、表が保管される表スペースがスタンバイ・データベース上で無効としてマークされます。この表スペースに関係する以降のログ・レコードはスキップされます。ロード操作がスタンバイ・データベース上のロード・コピーに確実にアクセスできるようにするため、COPY YES パラメーターからの出力ファイルに共有ロケーションを使用します。別の方法として、1 次でのロードの実行中に、スタンバイ・データベースを非アクティブにして、出力ファイルのコピーをスタンバイ・パスに置いてから、スタンバイ・データベースをアクティブにすることもできます。

1 次データベース上で NONRECOVERABLE パラメーターを指定して LOAD コマンドを発行すると、コマンドは 1 次データベース上で実行され、スタンバイ・データベース上の表に無効のマークが付けられます。この表に関係する以降のログ・レコードはスキップされます。 COPY YES パラメーターと REPLACE パラメーターを指定して LOAD コマンドを発行して表を元に戻すことも、表をドロップしてスペースをリカバリーすることもできます。

注: 表に以下のいずれかの特性がある場合、 COPY YES および REPLACE オプションを指定した LOAD コマンドを使用して表を元に戻すことはできません。

NOT LOGGED INITIALLY 属性を指定して表が作成されている。
表がマルチディメンション・クラスター (MDC) 表である。
表にコンプレッション・ディクショナリーがある。
表に XML 列があります。

COPY NO パラメーターを指定したロード操作は HADR ではサポートされないため、操作は NONRECOVERABLE パラメーターを指定したロード操作に自動的に変換されます。 COPY NO パラメーターを指定したロード操作を、 COPY YES パラメーターを指定したロード操作に変換できるようにするには、1 次データベースで DB2_LOAD_COPY_NO_OVERRIDE レジストリー変数を設定します。このレジストリー変数はスタンバイ・データベースでは無視されます。 1 次データベースに指定した装置またはディレクトリーが、スタンバイ・データベースで、同じパス、装置、またはロード・ライブラリーを使用してアクセス可能であることを確認してください。

Tivoli® Storage Manager (TSM) ソフトウェアを使用して COPY YES パラメーターを指定したロード操作を実行する場合は、1 次データベースとスタンバイ・データベースで vendoropt 構成パラメーターを設定する必要がある場合があります。 TSM の構成方法に応じて、1 次データベースの値とスタンバイ・データベースの値が同じでない場合があります。また、TSM を使用して COPY YES パラメーターを指定したロード操作を実行する場合は、 GRANT パラメーターを指定した db2adutl コマンドを発行して、ロードされるファイルに対する読み取り権限をスタンバイ・データベースに付与する必要があります。

表データが、COPY YES パラメーターをロード操作によって複製される場合、索引は、次のようにして複製されます。

REBUILD 索引付けモード・オプションを LOAD コマンドで指定し、LOG INDEX BUILD 表属性が ON に設定されている場合 (ALTER TABLE ステートメントを使用)、または logindexbuild データベース構成パラメーターが NULL に設定されている場合に、再作成された索引オブジェクト (つまり、表に定義されたすべての索引) が 1 次データベースに含まれます ON。ロード操作の前に、スタンバイ・データベースの索引オブジェクトが無効としてマークされる場合、索引の再作成の結果として、ロード操作後に再び使用可能になります。
INCREMENTAL 索引付けモード・オプションを LOAD コマンドで指定し、LOG INDEX BUILD 表属性が ON に設定されている場合 (ALTER TABLE ステートメントを使用)、または 1 次データベースの logindexbuild データベース構成パラメーターが NULL に設定されていて、1 次データベースの索引オブジェクトが ONに設定されている場合にのみ、スタンバイ・データベースの索引オブジェクトが更新されます。それ以外の場合には、索引はスタンバイ・データベース上で無効としてマークされます。

Db2_HADR_PEER_WAIT_LIMIT レジストリー変数

制約事項: このセクションのいずれも補助スタンバイには適用されません。補助スタンバイは SUPERASYNC 同期モードであるため、ピア状態になることはありません。

DB2_HADR_PEER_WAIT_LIMIT レジストリー変数を設定すると、スタンバイ・データベースへのログ・レプリケーションのために 1 次データベースへのロギングが指定された秒数の間ブロックされた場合に、HADR 1 次データベースのピア状態が解除されます。この限度に達すると、1 次データベースはスタンバイ・データベースへの接続を切断します。 hadr_peer_window 構成パラメーターを 0 に設定して、ピア・ウィンドウを使用不可にすると、1 次は切断済み状態になり、ロギングが再開します。ピア・ウィンドウを使用可能にすると、1 次データベースは切断済みピア状態になり、ロギングのブロックが継続されます。 1 次データベースは、再接続時またはピア・ウィンドウの有効期限が切れた時に切断済みピア状態ではなくなります。 1 次データベースが切断済みピア状態でなくなると、ロギングが再開します。

注: DB2_HADR_PEER_WAIT_LIMITを設定した場合は、誤ったアラームが発動されないように、最小値 10 を使用してください。

データベースがピア状態から解除されるときのピア・ウィンドウの遷移を考慮すると、すべての事例で安全にテークオーバーが行われるようにピア・ウィンドウのセマンティクスが守られます。遷移の際に 1 次に障害が発生した場合でも、通常のピア・ウィンドウ保護が引き続き適用されます (引き続き切断済みピア状態である場合、スタンバイから安全にテークオーバーされます)。

スタンバイ・データベースの側では、切断の後、データベースは既に受け取ったログの再生を続行します。受け取ったログが再生されると、スタンバイ・データベースは 1 次データベースに再接続します。受け取ったログが再生されると、スタンバイは 1 次に再接続します。再接続時に、通常の状態遷移が行われます (まず、リモート・キャッチアップ状態になってから、ピア状態になります)。

hadr_timeout データベース構成パラメーターとの関係

1 次データベースがブロック中にスタンバイ・データベースからのハートビート・メッセージを受け取り続けている場合、hadr_timeout データベース構成パラメーターによって 1 次データベースがピア状態から解除されることはありません。 hadr_timeout データベース構成パラメーターでは、HADR ネットワーク層のタイムアウト値を指定します。 HADR データベースは、パートナー・データベースから hadr_timeout 構成パラメーターで指定された期間にまったくメッセージを受け取らなかった場合、そのパートナー・データベースへの接続を切断します。このタイムアウトでログ・シッピングや ACK (確認通知) シグナルなどの高位層の操作に対するタイムアウトは制御されません。スタンバイ・データベースでのログ再生がロードや再編成などの大規模な操作で滞っている場合でも、HADR コンポーネントは通常のスケジュールで 1 次データベースにハートビート・メッセージを送信します。このようなシナリオでは、 DB2_HADR_PEER_WAIT_LIMIT レジストリー変数を設定しない限り、スタンバイ適用がブロックされている限り、1 次はブロックされます。

DB2_HADR_PEER_WAIT_LIMIT レジストリー変数は、接続状況に関係なく 1 次ロギングをブロック解除します。 DB2_HADR_PEER_WAIT_LIMIT レジストリー変数を設定しない場合でも、 hadr_timeout 構成パラメーターの結果として、ネットワーク・エラーが検出されるか接続がクローズされると、常に 1 次側のピア状態が解除されます。

DB2_FAIL_RECOVERY_ON_TABLESPACE_ERROR レジストリー変数

注: このレジストリー変数は、 Db2バージョン 11.5.4 以降で使用可能です。

HADR 環境ではデフォルトで、スタンバイ・データベースの表スペースが無効な状態またはエラー状態になると、その表スペース上でのトランザクションの再生が停止します。他の有効な表スペース上でのトランザクションの再生は続けられます。このデフォルトの動作は、影響を受ける表スペースがデータベースのごく一部であり、有効な表スペースでほとんどのアプリケーションが機能できる場合に適しています。

別の動作を指定するには、DB2_FAIL_RECOVERY_ON_TABLESPACE_ERROR レジストリー変数を ROLLFORWARD に設定します。この設定では、無効な表スペースまたはエラーのある表スペースが検出されると、スタンバイ・データベースがシャットダウンします。エラーを修正したら、スタンバイ・データベースを再始動できます。ただし、エラーを修正できない場合は、 HADR スタンバイ・データベースでの表スペース・エラーのリカバリーを参照して、影響を受けた表スペースをリカバリーすることができます。

HADR 構成パラメーター

一部の HADR 構成パラメーター ( hadr_local_host や hadr_remote_hostなど) は静的です。静的パラメーターはデータベースの始動時にロードされ、変更内容は実行時には無視されます。 HADR パラメーターは、START HADR コマンドの完了時にもロードされます。 1 次データベースの場合、データベースをオンラインにしたままの状態で、HADR を動的に開始および停止できます。したがって、データベースをシャットダウンせずに HADR 構成パラメーターの実効値をリフレッシュする 1 つの方法として、HADR を停止して再始動することができます。一方、STOP HADR をスタンバイで実行するとデータベースが停止するため、スタンバイのパラメーターはデータベースをオンラインにした状態ではリフレッシュできません。

ホスト名パラメーターおよびサービス名とポート名のパラメーター

HADR に設定する必要がある、相互に関連する 6 つの構成パラメーターがあります。

hadr_target_list
hadr_local_host
hadr_remote_host
hadr_local_svc
hadr_remote_svc (ただし、このパラメーターを使用しない Db2 pureScale® 環境の場合を除く)
hadr_remote_inst

ターゲット・リストは、(1 次に対する) スタンバイとして動作する一連の host:port のペア、またはスタンバイが新規 HADR 1 次データベースとしてテークオーバーした場合に使用するスタンバイ・ホストを指定します。このパラメーターの使用法について詳しくは、関連リンクの hadr_target_list のトピックを参照してください。

TCP 接続は、1 次データベースとスタンバイ・データベース間で通信する際に使用されます。ローカルパラメーターは、ローカル・アドレスを指定し、リモートパラメーターはリモート・アドレスを指定します。 1 次データベースまたは基本データベース・メンバーは、新しい接続のためにローカル・アドレスを listen します。 1 次データベースに接続されていないスタンバイ・データベースは、リモート・アドレスへの接続を再試行します。

スタンバイ・データベースもローカル・アドレスで listen します。一部のシナリオでは、別の HADR データベースがこのアドレスでスタンバイ・データベースに接続して、メッセージを送信できます。

HADR_NO_IP_CHECK レジストリー変数が設定されている場合を除き、HADR では接続時に 1 次側とプリンシパル・スタンバイのローカル・アドレスとリモート・アドレスのクロスチェックを以下のように行います。

 my local address = your remote address

および

my remote address = your local address

このチェックは、構成パラメーターのリテラル・ストリングではなく、IP アドレスとポート番号を使用して行われます。チェックを回避するには、NAT (ネットワーク・アドレス変換) 環境で HADR_NO_IP_CHECK レジストリー変数を設定する必要があります。

HADR データベースは、IPv4 または IPv6 のどちらかを使用して、そのパートナー・データベースを見つけるように構成することができます。ホスト・サーバーが IPv6 をサポートしていない場合は、IPv4 を使用する必要があります。サーバーが IPv6 をサポートしている場合、データベースが IPv4 か IPv6 のどちらを使用するかは、hadr_local_host および hadr_remote_host 構成パラメーターに指定されるアドレスのフォーマットによって決まります。データベースは、2 つのパラメーターを同一の IP フォーマットに解決し、可能な場合は IPv6 の使用を試みます。表 1 は、 IPv6-enabled サーバーの場合の IP モードの決定方法を示しています。

表 1. HADR 通信に使用されるアドレス・スペースの決定方法
hadr_local_host パラメーターに使用される IP モード	hadr_remote_host パラメーターに使用される IP モード	HADR 通信に使用される IP モード
IPv4 アドレス	IPv4 アドレス	IPv4
IPv4 アドレス	IPv6 アドレス	エラー
IPv4 アドレス	ホスト名、IPv4 のみにマップ	IPv4
IPv4 アドレス	ホスト名、IPv6 のみにマップ	エラー
IPv4 アドレス	ホスト名、IPv4 と v6 にマップ	IPv4
IPv6 アドレス	IPv4 アドレス	エラー
IPv6 アドレス	IPv6 アドレス	IPv6
IPv6 アドレス	ホスト名、IPv4 のみにマップ	エラー
IPv6 アドレス	ホスト名、IPv6 のみにマップ	IPv6
IPv6 アドレス	ホスト名、IPv4 と IPv6 にマップ	IPv6
ホスト名、IPv4 のみにマップ	IPv4 アドレス	IPv4
ホスト名、IPv4 のみにマップ	IPv6 アドレス	エラー
ホスト名、IPv4 のみにマップ	ホスト名、IPv4 のみにマップ	IPv4
ホスト名、IPv4 のみにマップ	ホスト名、IPv6 のみにマップ	エラー
ホスト名、IPv4 のみにマップ	ホスト名、IPv4 と IPv6 にマップ	IPv4
ホスト名、IPv6 のみにマップ	IPv4 アドレス	エラー
ホスト名、IPv6 のみにマップ	IPv6 アドレス	IPv6
ホスト名、IPv6 のみにマップ	ホスト名、IPv4 のみにマップ	エラー
ホスト名、IPv6 のみにマップ	ホスト名、IPv6 のみにマップ	IPv6
ホスト名、IPv6 のみにマップ	ホスト名、IPv4 と IPv6 にマップ	IPv6
ホスト名、IPv4 と IPv6 にマップ	IPv4 アドレス	IPv4
ホスト名、IPv4 と IPv6 にマップ	IPv6 アドレス	IPv6
ホスト名、IPv4 と IPv6 にマップ	ホスト名、IPv4 のみにマップ	IPv4
ホスト名、IPv4 と IPv6 にマップ	ホスト名、IPv6 のみにマップ	IPv6
ホスト名、IPv4 と IPv6 にマップ	ホスト名、IPv4 と IPv6 にマップ	IPv6

1 次およびスタンバイ・データベースが同じ IPv4 または IPv6 フォーマットを使用する場合にのみ、両者は HADR 接続を作成できます。一方のサーバーが IPv6 対応 (ただし、 IPv4もサポート) で、他方のサーバーが IPv4 のみをサポートする場合、 IPv6 サーバー上のhadr_local_host および hadr_remote_host パラメーターの少なくとも 1 つは、 IPv4 アドレスを指定して、このサーバー上のデータベースが強制的に IPv4を使用するようにする必要があります。

HADR のローカル・サービスとリモート・サービスの各パラメーター (hadr_local_svc および hadr_remote_svc) は、ポート番号またはサービス名のいずれかに設定できます。指定した値は、他のサービス (他の Db2 コンポーネントや他の HADR データベースを含む) で使用されていないポートにマップする必要があります。特に、どちらのパラメーター値も、サーバーがリモート・クライアントからの通信を待機するために使用する TCP/IP ポート (svcename データベース・マネージャー構成パラメーターの値)、またはその次のポート (svcename パラメーターの値 + 1) に設定することはできません。

1 次データベースとスタンバイ・データベースが異なるサーバー上にある場合、両方のデータベースで同じポート番号またはサービス名を使用できます。それ以外の場合は、異なる値を使用する必要があります。

自動再構成

hadr_remote_host、hadr_remote_svc、および hadr_remote_inst の各構成パラメーターは、正しく設定されていない場合、HADR の開始時に自動的にリセットされます。この再構成は自動で行われますが、常に正しい初期値を設定するようにしてください。自動再構成はスタンバイとその 1 次の間の接続が確立されるまで有効にならない可能性があるからです。一部の HADR デプロイメントでは、その初期値が必要になる可能性があります。例えば、 IBM® Tivoli System Automation for Multiplatforms ソフトウェアを使用している場合、リソース名を構成するには hadr_remote_inst 構成パラメーターの値が必要です。

注: DB2_HADR_NO_IP_CHECK レジストリー変数が ONに設定されている場合、 hadr_remote_host および hadr_remote_svc は自動的に更新されません。

再構成では、hadr_target_list 構成パラメーターの値が正しいものであることが前提となります。ターゲット・リスト項目に間違いがある場合、手動で訂正する必要があります。

1 次の場合、再構成は次のように行われます。

hadr_remote_host 構成パラメーターと hadr_remote_svc 構成パラメーターの値が、 hadr_target_list 構成パラメーターの最初の項目である host:port のペア (つまり、プリンシパル・スタンバイ) と一致しない場合は、以下のようになります。 hadr_remote_host および hadr_remote_svc 構成パラメーターが、ターゲット・リストの値で更新されます。
hadr_remote_inst 構成パラメーターの値がプリンシパル・スタンバイのインスタンス名と一致しない場合、プリンシパル・スタンバイが 1 次に接続した後、正しいインスタンス名が 1 次の hadr_remote_inst 構成パラメーターにコピーされます。

スタンバイ・データベースの場合、再構成は次のように行われます。

スタンバイは、始動時に、hadr_remote_host、hadr_remote_inst、および hadr_remote_svc の各構成パラメーターに指定されたデータベースへの接続を試行します。
スタンバイが 1 次に接続できない場合、1 次がそのスタンバイに接続するのを待機します。
1 次は、hadr_target_list パラメーターにリストされているアドレスを使用して、そのスタンバイへの接続を試行します。 1 次がスタンバイに接続した後、スタンバイの hadr_remote_host、hadr_remote_inst、および hadr_remote_svc の各構成パラメーターが 1 次の正しい値で更新されます。

非強制テークオーバーでは、新しい 1 次の hadr_remote_host、hadr_remote_inst、および hadr_remote_svc の各構成パラメーターの値はそのプリンシパル・スタンバイに自動的に更新され、新しい 1 次の hadr_target_list にリストされているスタンバイのこれらのパラメーターは新しい 1 次を指すように自動的に更新されます。新しい 1 次の hadr_target_list にリストされていないデータベースは更新されません。それらのデータベースは引き続き古い 1 次への接続を試行しますが、古い 1 次はスタンバイになっているため、拒否されます。古い 1 次は、ターゲット・リストで相互包括が必要であるため、新しい 1 次のターゲット・リストに確実に保管されます。

強制テークオーバーでは、新しい 1 次とそのスタンバイ (古い 1 次を除く) の自動更新は非強制テークオーバーと同じように機能します。ただし、古い 1 次の自動更新は、再統合のためにシャットダウンして、スタンバイとして再始動するまでは行われません。

テークオーバーの際にオンラインになっていないデータベースはすべて、その開始後に自動的に再構成されます。自動再構成は、定期的にスタンバイに接続する場合に新しい 1 次に依存するため、開始してすぐには有効にならない可能性があります。スタンバイは開始時に古い 1 次への接続を試行し、古い 1 次のログ・ストリームに従う可能性があります。これにより、スタンバイは新しい 1 次のログ・ストリームから分岐し、そのスタンバイと新しい 1 次をペアにすることができなくなります。したがって、このようなスプリット・ブレインのシナリオを回避するために、テークオーバーの前に古い 1 次をシャットダウンする必要があります。

同期モード

hadr_syncmode 構成パラメーターの設定が 1 次データベースとスタンバイ・データベースで同じである必要はありません。スタンバイで指定される hadr_syncmode 構成パラメーターの設定はすべて、その構成済み同期モードと見なされます。この設定は、スタンバイが 1 次になる場合にのみ関係します。スタンバイに有効同期モードが割り当てられます。どの補助スタンバイでも、有効同期モードは常に SUPERASYNC になります。プリンシパル・スタンバイの場合、有効同期モードは、1 次の hadr_syncmode 構成パラメーターの設定です。スタンバイの場合は、モニター・インターフェースに有効同期モードが同期モードとして表示されます。

注: hadr_target_list 構成パラメーター ( 10.5以降では推奨されない方式) を使用せずに HADR をセットアップした場合、 hadr_syncmode 構成パラメーターは 1 次データベースとスタンバイ・データベースで同一でなければなりません。

詳しくは、 Db2 高可用性災害時リカバリー (HADR) 同期モードを参照してください。

HADR のタイムアウトとピア・ウィンドウ

タイムアウト期間 (hadr_timeout 構成パラメーターで指定) は 1 次データベースとスタンバイ・データベースで同じでなければなりません。これらの構成パラメーターの値の整合性は、HADR ペアが接続を確立するときに検査されます。

ただし、1 つの例外があります。1 次データベースは始動時に、以下の 2 つのうち長い方の時間の間、スタンバイの接続を待機します。

最低 30 秒
hadr_timeout データベース構成パラメーターで指定される秒数。

指定された時間内にプリンシパル・スタンバイが接続しなければ、開始は失敗します。補助スタンバイへの接続はオプションです。この動作の 1 つの例外は、 BY FORCE パラメーターを指定して START HADR コマンドを発行する場合です。この場合、1 次データベースは、スタンバイ・データベースが接続されるのを待機せずに始動します。

HADR のペアが接続を確立した後、両者はハートビート・メッセージを交換します。ハートビート・インターバルは、hadr_timeout や hadr_peer_window 構成パラメーターのような要因から計算されます。これは、以下によって報告されます。HEARTBEAT_INTERVALMON_GET_HADR 表関数および db2pd コマンドのフィールド。あるデータベースが、hadr_timeout 構成パラメーターにより指定された秒数内に別のデータベースからメッセージを受け取らないと、切断が開始されます。この動作は、パートナー・データベースまたは介在するネットワークのいずれかの障害を検出するために、最大で、HADR データベースの hadr_timeout 構成パラメーターで指定される秒数を要することを意味します。 hadr_timeout の構成パラメーターの値の設定が低すぎると、偽のアラームが出され、頻繁に切断が起きる可能性があります。

hadr_peer_window 構成パラメーターの設定が 1 次データベースとスタンバイ・データベースで同じである必要はありません。プリンシパル・スタンバイはプライマリーのピア・ウィンドウ設定を使用します。これに対する例外は、 hadr_target_list 構成パラメーター ( 10.5以降では推奨されない方式) を使用せずに HADR をセットアップする場合です。この場合、 hadr_peer_window 構成パラメーターは 1 次データベースとスタンバイ・データベースで同一でなければなりません。

以下の場合、ピア・ウィンドウを有効にすることができません (つまり、0 に設定する必要があります)。

Db2 pureScale フィーチャーを使用している場合
hadr_syncmode パラメーターが ASYNC または SUPERASYNC に設定される場合
補助スタンバイを構成している場合

hadr_peer_window 構成パラメーターをゼロ以外の値に設定した場合に、1 次がピア状態でスタンバイとの接続を失うと、1 次データベースは、スタンバイ・データベースとの接続が復元されるか、hadr_peer_window 構成パラメーターの時間値が経過するかのいずれか早い時点まで、トランザクションをコミットしません。

最大限の可用性の場合、 hadr_peer_window データベース構成パラメーターのデフォルト値は 0です。このパラメーターが 0に設定されている場合、 1 次側とスタンバイ間の接続がクローズされるとすぐに、ブロッキング・トランザクションを回避するために 1 次ドロップがピア状態から低下します。接続は、スタンバイが接続をクローズしたか、ネットワーク・エラーが検出されたか、あるいはタイムアウトに達したことが原因でクローズする可能性があります。データの整合性を高めつつ、可用性を低くするために、hadr_peer_window データベース構成パラメーターをゼロ以外の値に設定できます。

詳しくは、 hadr_timeout および hadr_peer_window データベース構成パラメーターの設定を参照してください。

次のサンプル構成は、1 次データベースおよびスタンバイ・データベース用です。

1 次データベース:

   HADR_TARGET_LIST          host2.ibm.com:hadr_service
   HADR_LOCAL_HOST           host1.ibm.com
   HADR_LOCAL_SVC            hadr_service
   HADR_REMOTE_HOST          host2.ibm.com
   HADR_REMOTE_SVC           hadr_service
   HADR_REMOTE_INST          dbinst2
   HADR_TIMEOUT              120
   HADR_SYNCMODE             NEARSYNC
   HADR_PEER_WINDOW          120

スタンバイ・データベース:

   HADR_TARGET_LIST          host1.ibm.com:hadr_service
   HADR_LOCAL_HOST           host2.ibm.com
   HADR_LOCAL_SVC            hadr_service
   HADR_REMOTE_HOST          host1.ibm.com
   HADR_REMOTE_SVC           hadr_service
   HADR_REMOTE_INST          dbinst1
   HADR_TIMEOUT              120
   HADR_SYNCMODE             NEARSYNC
   HADR_PEER_WINDOW          120