はじめに
前回は、ExaDB-XSのData Guard GroupでOCI管理のAutomatic Failoverを有効化し、Fast-Start Failover（FSFO）が有効になっていることを確認しました。
今回は、プライマリ・データベースPの障害を模擬し、手動のフェイルオーバー操作を行わずに、Physical StandbyであるSが自動でプライマリへ昇格するかを確認します。
Automatic Failoverでは、OCI管理のObserverがプライマリとスタンバイを監視します。プライマリが利用不可と判断されると、FSFOがフェイルオーバーを実行します。
本記事は検証環境で実施した結果です。本番環境で同様の停止操作を実行する前には、業務影響、アプリケーションの接続方式、データ保護要件、復旧手順を十分に確認してください。
構成と試験条件
| 項目 | 内容 |
|---|---|
| サービス | Oracle Exadata Database Service on Exascale Infrastructure（ExaDB-XS） |
| Data Guardリソース | Data Guard Group |
| データベース・バージョン | Oracle AI Database 26ai 23.26.3.0.0 |
| 障害前のプライマリ | P（Oracle RAC、2インスタンス） |
| 障害前のスタンバイ | S（Physical Standby、Oracle RAC、2インスタンス） |
| Protection Mode | Maximum Performance |
| Redo転送 | ASYNC |
| FSFO | Enabled in Potential Data Loss Mode |
| Failover Target | S |
| Observer | OCI管理Observer |
| Failover Threshold | 30秒 |
| Lag Limit | 30秒 |
今回の構成はMaximum Performance/ASYNCです。ASYNCは、プライマリの処理をスタンバイへのRedo到達完了まで待たせない非同期転送方式です。そのため、障害時には未転送Redoの範囲でデータ損失が起こる可能性があります。
Oracle公式ドキュメントでも、Maximum Performanceでのフェイルオーバーではデータ損失が発生する可能性があると説明されています。
Use Oracle Data Guard with Oracle Exadata Database Service on Exascale Infrastructure
試験前の確認
障害を模擬する前に、DGMGRLでFSFO、Observer、スタンバイのフェイルオーバー準備状態を確認しました。
show configuration verbose;
show fast_start failover;
show observer;
validate database verbose S;
主な確認結果は以下です。
Configuration Status:
SUCCESS
Fast-Start Failover: Enabled in Potential Data Loss Mode
Active Target: S
Potential Targets: "S"
S valid
Observer: primary-5k524-1787101929052
Shutdown Primary: TRUE
Auto-reinstate: TRUE
Ready for Failover: Yes (Primary Running)
Apply State: Running
Apply Lag: 5 seconds
Transport Lag: 0 seconds
Transport Status: Success
この時点で、Sはフェイルオーバー・ターゲットとして有効であり、Redo Applyも実行中でした。
障害を模擬する
Pは2インスタンスのOracle RAC構成です。片方のインスタンスだけが停止してもデータベース全体としては稼働し続けるため、今回は両インスタンスを停止しました。
P側で、以下を実行します。
srvctl status database -db P
srvctl stop database -db P -stopoption ABORT
srvctl status database -db P
実行結果です。
Instance Primary1 is running on node momo1-beyai
Instance Primary2 is running on node momo2-uhszk
Instance Primary1 is not running on node momo1-beyai
Instance Primary2 is not running on node momo2-uhszk
-stopoption ABORTは、通常の停止処理を待たずにデータベースを停止する指定です。今回はプライマリが利用不可になった状況を明確に作るために使用しました。
重要な点として、手動のFAILOVER TO Sは実行していません。Sへの昇格がFSFOによる自動フェイルオーバーであることを確認するためです。
Sが自動昇格したことを確認する
P停止後、S側でDGMGRLを実行してBroker構成を確認しました。
show configuration verbose;
show fast_start failover;
show observer;
DGMGRLでは、SがPrimary databaseとして表示されました。
Configuration - primary_dgconf
Members:
S - Primary database
P - (*) Physical standby database (disabled)
ORA-16661: The standby database must be reinstated.
この時点で、旧プライマリPは障害状態のためdisabledなPhysical Standbyとして表示されます。これは、フェイルオーバー直後の旧プライマリが再参加できる状態になるまでの想定された表示です。
さらに、SでSQLを実行してデータベース・ロールとオープン・モードを確認します。
select database_role, open_mode
from v$database;
結果は以下でした。
DATABASE_ROLE OPEN_MODE
---------------- --------------------
PRIMARY READ WRITE
PRIMARY/READ WRITEであるため、Sが読み書き可能な新プライマリとして稼働していることを確認できました。
ここまでの結果から、PのRAC全インスタンス停止後、手動フェイルオーバーを実行することなく、SがFSFOによって自動昇格したと判断できます。
フェイルオーバー後、しばらくするとコンソールにも反映され、旧スタンバイは「無効化されたスタンバイ」と表示されます。
Oracle公式ドキュメントでも、Automatic Failoverを有効化した場合、プライマリが利用不可になるとOracleがスタンバイへのフェイルオーバーを開始すると説明されています。
Oracle Exadata Database Service on Exascale InfrastructureでのOracle Data Guardの使用
旧プライマリPを起動する
続いて、旧プライマリPを起動します。
srvctl start database -db P
srvctl status database -db P
起動後、旧Pで以下を実行します。
select database_role, open_mode
from v$database;
結果は以下でした。
DATABASE_ROLE OPEN_MODE
----------------- --------------------
PHYSICAL STANDBY MOUNTED
PはPHYSICAL STANDBY / MOUNTEDとして起動しました。また、DGMGRLでも現在のロールは以下のとおりでした。
S - Primary database
P - Physical standby database
コンソールでもスタンバイに昇格したことが確認できます。
MOUNTEDは、Physical StandbyがRedo Applyを行う一般的な状態です。今回の結果から、旧Pはプライマリではなく、Physical Standbyのロールで起動・再参加したことを確認できました。
結果
成功したこと
- PのRAC全インスタンスを停止して、プライマリ障害を模擬した
- 手動の
FAILOVER TO Sを実行しなかった - P停止後、Sが
Primary databaseとして表示された - Sで
PRIMARY / READ WRITEを確認した - 旧Pを起動後、
PHYSICAL STANDBY / MOUNTEDを確認した - OCI管理のAutomatic Failoverによるロール切替を確認できた
まとめ
ExaDB-XSのAutomatic Failoverを有効にしたData Guard Groupで、プライマリPのRAC全インスタンスを停止して障害を模擬しました。
結果として、手動のFAILOVER TOを実行せずに、Physical StandbyであったSがPRIMARY / READ WRITEへ自動昇格しました。これは、OCI管理ObserverとFSFOによる自動フェイルオーバーが動作したことを示していおり、正常にFSFOが動作していることが確認できました。