【要約】ExaDB-XSの新機能「Automatic Failover(FSFO)」を試す - その2：フェイルオーバー [Qiita_Trend] | Summary by TechDistill
> Source: Qiita_Trend
Execute Primary Source
// Problem
データベース管理者は、プライマリ障害発生時の復旧遅延や、手動操作に伴う人的ミスという課題に直面している。特に大規模システムでは、以下の点が問題となる。
- ・障害検知からフェイルオーバー実行までのダウンタイム。
- ・手動でのロール切り替え操作による判断ミスや手順の遅れ。
- ・障害発生後の旧プライマリの復旧および再参加プロセスの複雑さ。
// Approach
検証者は、OCI管理のObserverを用いたFSFO機能を活用し、自動的なロール切り替えを実現する手法を試みた。具体的な検証ステップは以下の通りである。
- ・Data Guard GroupにてFSFOを有効化し、準備状態を確認。
- ・
srvctl stop database -db P -stopoption ABORTを実行し、プライマリの全インスタンスを強制停止。 - ・Observerによる監視に基づき、スタンバイ(S)が自動でPRIMARY/READ WRITEへ昇格するプロセスを観測。
- ・旧プライマリ(P)を起動し、PHYSICAL STANDBY/MOUNTEDとして正常に再参加することを確認。
// Result
検証の結果、手動のFAILOVER操作を行わずに、スタンバイが自動で新プライマリへ昇格することを確認した。これにより、以下の成果が得られた。
- ・FSFOによる自動フェイルオーバーの正常動作を実証。
- ・旧プライマリがスタンバイとして自動的に再参加するプロセスの確認。
- ・OCI管理Observerによる、高度な可用性管理の有効性を立証。
Senior Engineer Insight
> FSFOによる自動化は、RTO削減において極めて強力な武器となる。しかし、本検証のASYNC構成ではデータ損失のリスクが伴う。実戦投入時は、RPO（目標復旧時点）の要件を再確認せよ。データ整合性を最優先するなら、Maximum Availabilityモード（SYNC）の採用を検討すべきだ。可用性とデータ保護のバランスを、システムの重要度に応じて厳格に設計せよ。