サンプル トポロジと障害回復
以下の図は、3 つの Multiwrite グループで構成されるサンプル トポロジを表しており、それぞれのグループには 3 つの Multiwrite DSA が含まれています。すべての DSA には同じプレフィックスがあります。
cad140jp
サンプル トポロジ
以下の図は、3 つの Multiwrite グループで構成されるサンプル トポロジを表しており、それぞれのグループには 3 つの Multiwrite DSA が含まれています。すべての DSA には同じプレフィックスがあります。
各グループには、設定されている Multiwrite ハブがあります(赤色)。各ルータ DSA の write-precedence の例が含まれています。

障害回復
MW-DISP リカバリでは、停止中にすべてのレプリケーション ピア間でデータの整合性が保たれるますが、DSA の再構築が必要になるときもあります。ハードウェアやディスクの障害、またはデータベースの破損がある場合は、DSA を再構築する必要があります。そのような場合には、障害回復の手順に従うことで、すべての DSA が整合したデータを使用して実行されます。一般的にこのような事態は、バックアップから DSA を再構築する必要があるとき、あるいはグリッドに関するエラーが原因で DSA が起動しないときに発生します。新しい Multiwrite グループまたは DSA を追加するには、ピア間のデータ同期に似たプロセスに従うことができます。長い停止の後には、障害回復手順の実行を検討することができます。MW-DISP が大きな変更を調整するよりも、回復手順を利用する方が効率的です。
どの障害回復手順とも同じように、展開に固有の手順を記録できるように、最初にテスト環境で利用します。
Multiwrite グループ ハブを使用するときには、2 つの障害回復シナリオがあります。以下の手順では、回復中に DSA がアクティブであり続けます。
回復手順では、サンプル トポロジを参考にして、特定の展開用にカスタマイズできます。
Multiwrite グループのピア回復
Multiwrite グループ内の Multiwrite グループ DSA がそのグループに対応している Multiwrite ハブに再び一致するように、DSA を再同期する必要があります。
障害シナリオ
DSA US2 を実行しているコンピュータがカーネル パニックのために停止した後に、グリッド関連エラーが原因で DSA US2 が起動しません。
手順 1:
回復させる DSA が停止状態であることを確認します。- dxserver stop US2
手順 2:
US2 を時刻(現在)に設定した後に、US1 からのデータのスナップショット(オンライン ダンプ)を作成します。この手順により、US2 をレプリケートする DSA のみが、データ スナップショット作成時からの回復更新を送信するようになります。- Host F: Run dxdisp US2 (このコマンドは、US3 によって US2 が最後に更新された時刻を設定します)
- Host D: Run dxdisp US2 (このコマンドは、US1 によって US2 が最後に更新された時刻を設定します)
手順 3:
可能であれば、ハブ DSA (US1)ハブからオンライン ダンプを実行します。dxdisp 実行後のスナップショットの作成が早いほど、回復中に US2 に再適用される更新は少なくなります。したがって、回復の方が効率的です。- Host D: US1 (ハブ)の DSA コンソールへの Telnet。「dump dxgrid-db;」コマンドを実行してオンライン ダンプを開始します。次に、「logout;」コマンドを使用して DSA コンソールを終了します。
- Host D: US1 warn-log でダンプの開始時刻を確認し、さらに重要であるダンプの完了時刻を確認します。
- Host D: ダンプが完了すると、$DXHOME/data/US1.zdb という名前のファイルが作成されます。このファイルを Host E にコピーします。たとえば、Host E: /tmp/US1.zdb にコピーします。
注:
ほとんどのグリッド ファイルは正常に圧縮されますので、ファイルを圧縮してから、マシン間でコピーしてください。オンライン バックアップ コマンドで作成されたファイルがコピーされるように、タイムスタンプが最近のものであることを確認します。手順 4:
US2 がハブおよびピアに更新を再生することを防止します。- Host E: dxdisp US1
- Host E: dxdisp US3
手順 5:
ハブからスナップショットが作成されたので、この情報をコピーすることができます。- Host E: 古いトランザクション ログの削除(有効になっている場合) - $DXHOME/data/US2.tx の削除
- Host E: 手順 3 で生成されたバックアップ グリッド ファイルをコピー(および解凍)します。たとえば、/tmp/US1.zdb $DXHOME/data/US2.db をコピーします。
- Host E: dxserver start US2
- Host E: 短い時間の後に US2 は US1 と再同期します。MW-DISP リカバリの進捗状況は、US2 の alarm-log で追跡できます。
注:
回復が完了するまで、US2 ではルータまたはアプリケーションからのバインドは許可されません。大きなボリュームの更新が並行してある場合は、回復時間が長くなる可能性があります。Multiwrite グループのハブ回復
Multiwrite グループ内の Multiwrite グループ ハブ DSA を再同期する必要がある場合は、このシナリオはもう少し複雑になります。このような場合は、このスタイルのネットワーク トポロジでの更新フローの仕組みのため、ハブが対応している DSA も再同期が必要になります。ハブが同期されたら、そのハブが対応しているグループ内のすべての DSA を同期する必要があります。
障害シナリオ:
DSA US1 を実行しているコンピュータがカーネル パニックのために停止した後に、グリッド関連エラーが原因で DSA US1 が起動しません。手順 1:
回復させる DSA グループが停止状態であることを確認します。- dxserver stop US1
- dxserver stop US2
- dxserver stop US3
手順 2:
各ハブの US1 を時刻(現在)に設定した後に、ほかのいずれかのハブからのデータのスナップショット(オンライン ダンプ)を作成します。この手順により、US1 をレプリケートする DSA のみが、データ スナップショット作成時からの回復更新を送信するようになります。- AU3 と UK1 の間のレプリケーションのステータスがOKであることを確認します。ハブ AU3 のコンソールで「get dsp;」コマンドを発行することにより、このステータスを確認できます。この手順により、UK1 からのスナップショットを作成するときには、AU3 からの更新がデータに含まれるようになります。dxdisp の実行後には、AU3 がこれらの更新を直接回復します。
- Host C: Run dxdisp US1 (このコマンドは、*hub* AU3 によって US1 が最後に更新された時刻を設定します)
- Host G: Run dxdisp US1 (このコマンドは、*hub* UK1 によって US1 が最後に更新された時刻を設定します)
手順 3:
可能であれば、ハブ(UK1)ハブからオンライン ダンプを実行します。- Host G: UK1 (ハブ)の DSA コンソールへの Telnet。「dump dxgrid-db;」コマンドを実行してオンライン ダンプを開始します。次に、「logout;」コマンドを使用して DSA コンソールを終了します。
- Host G: UK1 warn log でダンプの開始時刻を確認し、さらに重要であるダンプの完了時刻を確認します。
- Host G: ダンプが完了すると、$DXHOME/data/UK1.zdb という名前のファイルが作成されます。
- Host G: このファイルを Host D にコピーします。たとえば、Host D: /tmp/UK1.zdb にコピーします。
- Host G: このファイルを Host E にコピーします。たとえば、Host E: /tmp/UK1.zdb にコピーします。
- Host G: このファイルを Host F にコピーします。たとえば、Host F: /tmp/UK1.zdb にコピーします。
注:
ほとんどのグリッド ファイルは正常に圧縮されますので、ファイルを圧縮してから、マシン間でコピーしてください。オンライン バックアップ コマンドで作成されたファイルがコピーされるように、タイムスタンプが最近のものであることを確認します。手順 4:
US1 がハブに更新を再生することを防止します。US2 と US3 がハブ US1 に更新を再生することも防止します。- Host D: dxdisp AU3
- Host D: dxdisp UK1
- Host D: dxdisp US2
- Host D: dxdisp US3
- Host E: dxdisp US1
- Host E: dxdisp US3
- Host F: dxdisp US1
- Host F: dxdisp US2
手順 5:
US Multiwrite グループの各 DSA で UK1 からのスナップショットを作成します。- Host D: 古いトランザクション ログの削除(有効になっている場合) - $DXHOME/data/US1.tx の削除
- Host D: 手順 3 で生成されたバックアップ グリッド ファイルをコピー(および解凍)します。たとえば、/tmp/UK1.zdb $DXHOME/data/US1.db をコピーします。
- Host D: dxserver start US1
- Host E: 古いトランザクション ログの削除(有効になっている場合) - $DXHOME/data/US2.tx の削除
- Host E: 手順 3 で生成されたバックアップ グリッド ファイルをコピー(および解凍)します。たとえば、/tmp/UK1.zdb $DXHOME/data/US2.db をコピーします。
- Host E: dxserver start US2
- Host F: 古いトランザクション ログの削除(有効になっている場合) - $DXHOME/data/US3.tx の削除
- Host F: 手順 3 で生成されたバックアップ グリッド ファイルをコピー(および解凍)します。たとえば、/tmp/UK1.zdb $DXHOME/data/US3.db をコピーします。
- Host F: dxserver start US3
- Host D: 一定期間の後に US1 は AU3 および UK1 と再同期します。MW-DISP リカバリの進捗状況は、alarm-log US1 で追跡できます。US1 の再同期には、US2、US3 も含まれます。レプリケーションが期待どおりに動作するように、AU3、UK1、US1、US2、および US3 のコンソールで「get dsp;」コマンドを使用して回復プロセスを監視できます。
注:
回復が完了するまで、US1、US2、および US3 ではルータまたはアプリケーションからのバインドは許可されません。大きなボリュームの更新が並行してある場合は、回復時間が長くなる可能性があります。注意事項
- Windows の場合は、グリッド ファイルへのパスは %DXHOME%\data です。
- コピーまたは変更されたことのない .dp ファイルをコピーまたは変更しないでください。
- UNIX では、DSA ユーザ(すなわち dsa)としてこれらの手順を実行してください。
- ダンプが完了する前にグリッド ファイルをコピーしないでください。ダンプ完了前にコピーしたグリッド ファイルは、破損したり、不完全になったりする可能性があります。このような場合は、このプロセスを繰り返します。
- 古いバックアップが誤って使用されないように、.zdb ファイルのタイムスタンプを確認して、そのファイルが最近書き込まれたものであることを確かめます。