スタンバイ・サーバーへのフェイルオーバーとフェイルバック
レプリケーション・コンソールを使用して、プライマリー・データベース・サイトとスタンバイ・データベース・サイトを構成できます。こうすることで、プライマリー・サイトをシャットダウンせざるを得ない場合 (または計画外の停止がある場合) に、プライマリーが復元するまでスタンバイ・サイトにアプリケーションを再ルーティングできるようになります。
始める前に
レプリケーションを構成する前に、管理者として Web コンソールを使用して、プライマリー・サイトとスタンバイ・サイトの 2 つの固有のレプリケーション・ユーザー ID を作成します。 各 ID は、フェイルオーバーのセットアップに必要な両方向構成のレプリケーションの 1 つの方向を表します。
- repluser1: この ID をプライマリー・サーバーに作成します。これを使用して、プライマリー・サーバーにあるソース・データベースと、プライマリー・サーバーから複製されたトランザクションを受け取るスタンバイ・サーバーにあるターゲット・データベースを使用可能にします。
- repluser2: この ID をスタンバイ・サーバーに作成します。これを使用して、スタンバイ・サーバーにあるソース・データベースと、スタンバイ・サーバーから複製されたトランザクションを受け取るプライマリー・サーバーにあるターゲット・データベースを使用可能にします。
ターゲットを使用可能にするときに使用する ID は、ソースにある IBMQREP_IGNTRAN というメタデータ表に挿入されます。 このユーザー ID によって行われる変更はすべて、レプリケーション・キャプチャー・プロセスでは無視されます。これは、「循環」レプリケーション (同じ変更が 2 つのサイト間で交互に複製され続けること) を防止するためです。
これらのユーザー ID は、レプリケーション専用に予約しておく必要があります。レプリケーション・シグナルの挿入を含め、データベース操作の手動実行には、レプリケーション・ユーザー ID を使用しないでください。
このタスクについて
このトピックの手順は、計画されたフェイルオーバーとフェイルバックのシナリオを示しています。計画外または災害時のシナリオにおける追加の考慮事項については、下記を参照してください。
手順
-
プライマリー・サーバーからスタンバイ・サーバーへのレプリケーション・セットのモニター・ページにある、最終整合点をメモします。
最終整合点は、ターゲットでの UTC 時間で示されます。必要に応じて、ソースでの現地時間に調整してください。
次のタスク
計画外の障害がプライマリー・サイトで発生した場合、プライマリー・サイトからスタンバイ・サイトへのレプリケーション・セットの最終整合点は、アプリケーションが最後にプライマリー・サイトを更新した時刻よりも前の時刻になります。レプリケーションはこれらの新しい更新を取り入れていないためです。
アプリケーションをスタンバイ・サイトに切り替えると、レプリケーション・セットの最終整合点は、アプリケーションが最後にプライマリー・サイトを更新した時刻と同じかそれよりも後になります。
フェイルオーバー後、新しいプライマリー・サイト (以前のスタンバイ・サイト) から新しいスタンバイ・サイト (以前のプライマリー・サイト) に新しいデータが流れ始めます。
新しいスタンバイ・サイトから新しいプライマリー・サイトへの逆方向のレプリケーションには、フェイルオーバー前に元のプライマリー・サイトで行われた変更が取り入れられます。 この取り入れ期間中に同じ行が更新されると、何らかの競合が発生する可能性があります。 行の競合はターゲット・データベースの IBMQREP_EXCEPTIONS 表に記録されます。この表を確認するには、次の SQL SELECT ステートメントを使用します。
SELECT * FROM schema.IBMQREP_EXCEPTIONS ORDER BY EXCEPTION_TIME DESC;