フェイルオーバー訓練 / 計画的なロール移行

ロール変更の種類 (計画的なスイッチオーバー、緊急フェイルオーバー、本番に影響しない訓練) を判別し、シナリオごとに正しいコマンド手順と検証手順を示す診断フロー。目的: 計画時はデータ損失ゼロ、緊急時は最小限の損失、訓練時はダウンタイムなしで移行できる状態を整えること。

何をしたいか?

ロール変更の状況を選択する。プライマリが正常な状態で計画的な移行 (メンテナンス/移行) を行うのか、プライマリが実際に停止して緊急移行が必要なのか、それとも本番に触れずに訓練/準備状況の検証を行うのか?

• 計画的なスイッチオーバー (プライマリは正常)
• 緊急フェイルオーバー (プライマリが停止)
• 訓練 / 準備状況テスト (本番には触れない)

計画的な移行 — まず準備はできているか?

計画的なスイッチオーバーの目標はデータ損失ゼロ。そのため移行前に、レプリカがプライマリに追いついており (遅延 ~0)、正常であることを確認する必要がある。以下のコマンドで遅延を確認し、遅延がゼロに近ければ移行手順に進む。

SELECT thread#, MAX(sequence#) FROM v$archived_log GROUP BY thread#;   -- DG: SELECT name, value FROM v$dataguard_stats WHERE name LIKE '%lag%';

• 遅延はゼロに近く、移行の準備完了
• 遅延が大きいため、まず同期を待つ

計画的なスイッチオーバー (データ損失のない制御された移行)

プライマリとスタンバイが正常かつ同期している間に、制御された方法でロールを入れ替える。順序が重要: 書き込みを停止し、残りの変更がスタンバイに到達したことを確認してからロールを引き渡し、アプリケーションを新しいプライマリにリダイレクトする。

緊急移行 — プライマリは本当に停止しているか?

フェイルオーバーを強制する前に、プライマリが本当に到達不能であることを確認し、スプリットブレインのリスクを評価する。プライマリが実際には稼働している場合 (例: 一時的なネットワーク障害)、強制移行により書き込み可能なコピーが 2 つ生じる (スプリットブレイン)。最新のスタンバイを選ぶため、遅延も比較する。

-- try to reach the primary: tnsping primary_db; and on the standby: SELECT thread#, MAX(sequence#) FROM v$archived_log GROUP BY thread#;

• はい、プライマリは停止している — 移行を強制する
• 確信がない / プライマリが復帰する可能性がある

緊急フェイルオーバー (プライマリが停止、データ損失リスクを伴う移行)

プライマリが到達不能で、復帰を待てない。スタンバイを強制昇格させる必要があり、非同期レプリケーションでは直近のトランザクションの一部が失われる可能性がある。優先すべきはサービスの復旧であり、その後に損失範囲を特定し、旧プライマリを安全に復帰させる。

訓練 / 準備状況テスト (本番に触れずに検証)

実際の移行を行わずに、フェイルオーバーの準備ができていることを証明する。本番に影響を与えずに、レプリカの健全性、遅延が許容範囲内であること、アプリケーションをリダイレクトできることを検証する。必要に応じて、隔離したコピー上で実際のスイッチオーバーをリハーサルする。