高可用性災害時リカバリー (HADR) の初期設定

CLP を使用して、初めてシステム上で HADR を初期設定する場合、次のようにします。

1. 各 HADR データベースのホスト名、ホスト IP アドレス、およびサービス名かポート番号を判別します。

   ホストに複数のネットワーク・インターフェースがある場合、 HADR ホスト名または IP アドレスが目的のインターフェースにマッピングされるようにします。 保護されるデータベースごとに、/etc/services で個別の HADR ポートを割り振る必要があります。 これらは、インスタンスに割り振られるポートと同じであってはなりません。 ホスト名は、1 つの IP アドレスにだけマッピング可能です。

   ホスト名を判別するには、 LIST データベース・ディレクトリー コマンドを参照してください。 ホスト IP アドレス、サービス名、およびポート番号を判別するには、 LIST ノード・ディレクトリー コマンドを参照してください。

   注: 1 次データベースとスタンバイ・データベースのインスタンス名は同じである必要はありません。
2. HADR 環境に推奨または必要とされるすべての構成パラメーターを 1 次データベースに設定して、次のステップで作成するすべてのスタンバイに、これらの構成パラメーターが設定されるようにします。
   例えば、以下のコマンドを発行して、推奨されるロギングおよび索引再作成動作を使用可能にし、ログに記録されないアクティビティをブロックします。

   "UPDATE DB CFG FOR dbname USING
        LOGINDEXBUILD   ON
        BLOCKNONLOGGED YES"

3. 1 次データベースとして設定する予定の既存のデータベースに基づき、 バックアップ・イメージをリストアするか、スプリット・ミラーを初期設定して、 スタンバイ・データベースを作成します。

   オプション	説明
   バックアップおよびリストア・メソッド	以下の例では、 BACKUP DATABASE コマンドと RESTORE DATABASE コマンドを使用してスタンバイ・データベースを初期化します。 この場合、両方のサイトから共有ファイル・システムにアクセス可能です。 1 次で、次のコマンドをオンラインで発行します。 BACKUP DB dbname データベースがスタンバイ・インスタンス上に既存の場合は、クリーンな状態で開始するために、最初にデータベースをドロップしてください。 既存のデータベース内のファイルにより、HADR 操作が妨げられる可能性があります。 例えば、ログ・ファイルが残っていると、スタンバイが 1 次と互換性のないログ・チェーンに置かれてしまう可能性があります。 次のコマンドを発行して、データベースをドロップします。 DROP DB dbname データベースがスタンバイ・インスタンスに既に存在する場合は、ログ・ファイルがアーカイブに存在する可能性があります。ログ・アーカイブが 1 次データベースとスタンバイ・データベースで共有されていない場合は、まずスタンバイのログ・ファイルを削除します。 各スタンバイ・インスタンスで、以下のコマンドを発行します。 RESTORE DB dbname スタンバイ・データベースのセットアップ時には、 RESTORE DATABASE コマンド・オプション TABLESPACE、 INTO、 REDIRECT、および WITHOUT ROLLING FORWARDを使用しないでください。 注: 自動ストレージが有効になっている複数のストレージ・パスに対して 1 次データベースが定義されている場合は、 リストア中のリバランスを回避することが重要です。 これを行うには、 RESTORE DATABASE コマンドの ON path-list オプションを使用して、1 次データベースと同じ順序でストレージ・パスのセットを指定します (この順序は db2pd -db dbname -storagepaths コマンドで確認できます)。 ON path-list オプションの目的は、スタンバイ・データベースに別のストレージ・パス・セットを使用させるのではなく、リバランスを回避することです。
   オンラインのスプリット・ミラー方式	次の例には、db2inidb ユーティリティーを使用して、 1 次データベースのスプリット・ミラーを使用したスタンバイ・データベースを初期設定する方法が示されています。 この手順は、前述のバックアップおよびリストアの手順の代わりに実行できるものです。 スタンバイ・データベースで次のコマンドを発行します。 DB2INIDB dbname AS STANDBY db2inidb ユーティリティーの SNAPSHOT オプションまたは MIRROR オプションは使用しないでください。 RELOCATE USING オプションを指定すると、インスタンス名、ログ・パス、およびデータベース・パスのうち 1 つ以上の構成属性を変更できます。 しかし、データベース名または表スペース・コンテナー・パスを変更してはなりません。
   オフラインのスプリット・ミラー方式	以下の例は、1 次データベースのオフライン・スプリット・ミラーを使用して、スタンバイ・データベースを初期化するための db2rfpen ユーティリティーの使用方法を示しています。 この手順は、バックアップおよびリストアの代替手順、または前述のオンライン・スプリット・ミラーの代替手順になります。 スプリット・ミラーのバックアップは、クリーンなデータベース・シャットダウンの後に行う必要があります。 クリーンなデータベース・シャットダウンとは、データベースがクラッシュ・リカバリー・ペンディング状態でないことを意味します。 スタンバイ・インスタンスで、オフライン・スプリット・ミラー・バックアップをリストアします。 スタンバイ・インスタンスで db2rfpen コマンドを発行します。 db2rfpen on dbname

   注: 1 次データベースとスタンバイ・データベースのデータベース名は同じでなければなりません。
4. HADR 固有の構成パラメーターを設定します。 Db2 pureScale 環境の場合は、 以下のステップに従ってください。
   • Db2 pureScale以外の環境:
     1. 1 次データベースおよびスタンバイ・データベースで、hadr_local_host、hadr_local_svc、および hadr_syncmode の各構成パラメーターを設定します。

        "UPDATE DB CFG FOR dbname USING
        	HADR_LOCAL_HOST   hostname
        	HADR_LOCAL_SVC    servicename
        	HADR_SYNCMODE     syncmode"

        注: hadr_target_list が設定されている場合、 hadr_syncmode は、このデータベースが 1 次になるときにプリンシパル・スタンバイが使用するモードです。 補助スタンバイは、有効な同期モードとして常に SUPERANSYNC を使用します。
     2. 1 次データベースおよびスタンバイ・データベースで、次のように hadr_target_list 構成パラメーターを設定します。

        UPDATE DB CFG FOR dbname USING
        	HADR_TARGET_LIST  principalhostname:principalservicename|auxhostnameN:auxservicenameN1

        hadr_target_list パラメーターを設定しないと、1 つのスタンバイに制限されます。 HADR を構成するこの方法は、 バージョン 10.5以降非推奨になりました。

        複数のスタンバイ・データベースをセットアップしている場合、最初にリストするデータベースがプリンシパル・スタンバイとして指定されます。

     3. 1 次データベースおよびスタンバイ・データベースで、hadr_remote_host、hadr_remote_svc、および hadr_remote_inst の各構成パラメーターを設定します。
        1 次では、以下のコマンドを発行して、スタンバイ (複数スタンバイを構成している場合はプリンシパル・スタンバイ) の対応する値にパラメーターを設定します。

        "UPDATE DB CFG FOR dbname USING
        	HADR_REMOTE_HOST   principalhostname
        	HADR_REMOTE_SVC    principalservicename
         	HADR_REMOTE_INST   principalinstname"
        

        スタンバイでは、以下のコマンドを発行して、1 次の対応する値にパラメーターを設定します。

        "UPDATE DB CFG FOR dbname USING
        	HADR_REMOTE_HOST   primaryhostname
        	HADR_REMOTE_SVC    primaryservicename
        	HADR_REMOTE_INST   primaryinstname"
        

        hadr_target_list を構成した場合、これらの値は必要に応じて自動的に訂正されます。ただし、明示的に正しい値を設定すると、その正しい値がすぐに使用可能になります。 これらの値は、 IBM® Tivoli® System Automation for Multiplatforms (SA MP) ソフトウェアまたは Pacemaker ソフトウェアがリソース名を構成するために使用します。 統合クラスター・マネージャーを使用している場合、自動化を使用可能にする前にそれらが正しく設定されていることを確認してください。

   • Db2 pureScale 環境:
     1. 1 次データベースおよびスタンバイ・データベースで、クラスター・レベルの構成パラメーター hadr_target_list および hadr_syncmode を設定します。

        "UPDATE DB CFG FOR  dbname USING
        	HADR_TARGET_LIST   {memhostname1:memservicename1|memhostnameN:memservicenameN}
        	HADR_SYNCMODE      syncmode"

        以下の例は、コマンドを示しています。

        db2 "UPDATE DB CFG FOR hadr_db USING
             HADR_TARGET_LIST  {s0:4000|s1:4000|s2:4000|s3:4000}
             HADR_SYNCMODE     async"

        hadr_target_list パラメーターは、リモート・クラスターのメンバーをリストします。 クラスターのメンバーは、中括弧 {} で囲む必要があります。 リモート・クラスターのメンバー・アドレスのサブセットのみが必須です。

        hadr_remote_host、 hadr_remote_svc、および hadr_remote_inst 構成パラメーターは、 Db2 pureScale 環境では自動的に構成されるため、ブランク (論理的に NULL) のままにすることができます。 自動構成について詳しくは、 このセクションを参照してください。

     2. 1 次データベースおよびスタンバイ・データベースの各メンバーについて、メンバー・レベルの構成パラメーター hadr_local_host および hadr_local_svc を設定します。

        "UPDATE DB CFG FOR dbname MEMBER mname USING
        	HADR_LOCAL_HOST   memhostname
        	HADR_LOCAL_SVC    memservicename"

        以下に、コマンドの例を示します。

        • メンバー 0 の場合:

          db2 "UPDATE DB CFG FOR hadr_db MEMBER 0 USING
               HADR_LOCAL_HOST   p0
               HADR_LOCAL_SVC    4000"

        • メンバー 1 の場合:

          db2 "UPDATE DB CFG FOR hadr_db MEMBER 1 USING
               HADR_LOCAL_HOST   p1
               HADR_LOCAL_SVC    4000"

        • メンバー 2 の場合:

          db2 "UPDATE DB CFG FOR hadr_db MEMBER 2 USING
               HADR_LOCAL_HOST   p2
               HADR_LOCAL_SVC    4000"

        • メンバー 3 の場合:

          db2 "UPDATE DB CFG FOR hadr_db MEMBER 3 USING
               HADR_LOCAL_HOST   p3
               HADR_LOCAL_SVC    4000"

5. スタンバイ・インスタンスに接続し、スタンバイ・データベースで HADR を開始します。 Db2 pureScale 環境では、優先再生メンバーとして指定するメンバーから HADR を開始していることを確認してください。

   START HADR ON DB dbname AS STANDBY

   注: 通常、スタンバイ・データベースが最初に開始されます。 1 次データベースを最初に開始する場合、hadr_timeout データベース構成パラメーターで指定した時間間隔内にスタンバイ・データベースが開始されなければ、この開始手順は失敗します。
   スタンバイ・データベースは開始後に、ローカルに使用可能なログ・ファイルが読み取られて再生されるローカル・キャッチアップ 状態になります。 ローカル・ログをすべて再生した後、リモート・キャッチアップ・ペンディング 状態になります。
6. 1 次インスタンスに接続し、1 次データベースで HADR を開始します。 Db2 pureScale 環境では、優先再生メンバーとして指定するメンバーから HADR を開始していることを確認してください。

   START HADR ON DB dbname AS PRIMARY

   1 次データベースの開始後、スタンバイ・データベースはリモート・キャッチアップ 状態になり、1 次データベースからログ・ページを受け取って再生します。 1 次データベース・マシンのディスク上にあるすべてのログ・ファイルを再生した後で、両方のデータベースが 同業者 state ( SUPERASYNC が同期モードでない場合 )状態になります。