Amazon Aurora PostgreSQL での擬似障害の実行 (1)
はじめに
Amazon Aurora PostgreSQL (以下、Aurora PostgreSQL) で擬似障害試験を実施することがあったのでまとめる。
Amazon Aurora における擬似障害
Amazon Aurora で擬似障害を発生させる方法には、大きく3つの方法がある。
- AWS マネジメントコンソールによる手動のフェイルオーバーを発生させる方法
- 障害挿入クエリを利用して DB インスタンスをクラッシュさせる方法
- AWS Fault Injection Simulator を利用する方法
Amazon Aurora には MySQL 互換の DB エンジン (以下、Aurora MySQL) も用意されているが、Aurora PostgreSQL と Aurora MySQL で障害挿入クエリが異なるため、具体的な擬似障害の発生方法が異なる点に注意する。
今回は Aurora PostgreSQL を対象とする。
検証環境の構成
Aurora PostgreSQL のバージョンは 3.2 (PostgreSQL バージョン 11.7 との互換性あり) とし、DB クラスタの構成を下記とする。
| DB 識別子 | ロール | フェイルオーバー優先順位 |
|---|---|---|
| aurora-test-cluster-instance-1 | 書き込み | 1 |
| aurora-test-cluster-read-replica-1 | 読み込み | 1 |
| aurora-test-cluster-read-replica-2 | 読み込み | 2 |
「フェイルオーバー優先順位」は、0 (最高) から 15 (最低) までの16段階で設定可能である。
プライマリ DB (aurora-test-cluster-instance-1) に障害があった場合、優先度の高いリードレプリカ 1 (aurora-test-cluster-read-replica-1) がプライマリ DB に昇格することになる。
なお、Amazon Aurora の仕様では、優先度が同じ場合は、その中でサイズが最も大きいリードレプリカが選択される。 優先度もサイズも同じ場合は、その中からランダムに選択される。
AWS マネジメントコンソールによる手動のフェイルオーバーを発生させる方法
事前の準備が必要ないので、最も単純に実施できる方法である。
1. AWS マネジメントコンソールで Amazon RDS のコンソールに移動する
2. 「データベース」を選択する
3. DB クラスタと DB インスタンスの「ステータス」を確認する
DB クラスタと DB インスタンスとリードレプリカの「ステータス」が「利用可能」であることを確認する。
4. フェイルオーバーを発生させる
「アクション > フェイルオーバー」を選択する。
フェイルオーバーを発生させるクラスタのクラスタ名 (ここでは、aurora-test-cluster) を確認する。 間違いがなければ「フェイルオーバー」を選択する。
5. フェイルオーバーの発生を確認する
問題がなければ、元の「データベース」の画面に戻る。 画面のリフレッシュを行うと、DB クラスタののステータスが「Failing-over」となる。
DB クラスタに1つ以上のリードレプリカが含まれる場合、一般的には120秒未満、多くの場合は60秒未満でリードレプリカの1つへのフェイルオーバーが完了する。
DB クラスタに1つ以上のリードレプリカが含まれない場合は、DB インスタンスの再作成処理が行われる。通常は10分未満で完了する。
6. フェイルオーバーの完了を確認する
1分程度待ち、「ステータス」が「利用可能」となれば、フェイルオーバーは完了。
今回のフェイルオーバーにより、リードレプリカ 1 (aurora-test-cluster-read-replica-1) がプライマリ DB に昇格して、元プライマリ DB がリードレプリカとなったため、期待通り。
