以前書いた、
の続きです。
1. 確認する事項
AWS Aurora（MySQL互換）では、SQL（コマンド）で障害をシミュレートできますが、
- プライマリインスタンス（Writer）のみ
- プライマリ／レプリカインスタンスでクラスタを組んでいるときのプライマリ（Writer）側
- プライマリ／レプリカインスタンスでクラスタを組んでいるときのレプリカ（Reader）側
で、
- インスタンス障害（
ALTER SYSTEM CRASH INSTANCE） - ディスパッチャー障害（
ALTER SYSTEM CRASH DISPATCHER） - ノード障害（
ALTER SYSTEM CRASH NODE） - 1分間／100%のディスク障害（
ALTER SYSTEM SIMULATE 100 PERCENT DISK FAILURE FOR INTERVAL 1 MINUTE） - 1分間／100%のレプリカ障害（
ALTER SYSTEM SIMULATE 100 PERCENT READ REPLICA FAILURE TO ALL FOR INTERVAL 1 MINUTE）※クラスタ構成時のみ
を疑似的に発生させて、各インスタンスのバッファキャッシュが維持またはウォームアップされるかを確認します。
なお、利用するDB・テーブル・データは前回のものをそのまま利用します。
※AWSのサイト（以下のページ）に以前あったはずの、障害シミュレーションコマンドのリファレンスが、なぜか見当たらないですね…。
- Amazon Aurora DB クラスターの管理（
AWS Documentation RDS ユーザーガイド）
また、以下の記事で書かれた内容とは、実際の挙動が変わっているところがあるようです（フェイルオーバーしません）。
- Amazon Auroraの障害テストを試してみた。（Developers.IO／きうちさん）
こちらの記事にも「フェイルオーバーしない」旨、記されていますね。
- Amazon Auroraの耐障害性を検証してみました（ムラウチドットコム エンジニアブログ）
2. 結果
「○」は維持（ウォームアップ）される／「×」はクリアされることを示します。
2-1. プライマリインスタンス（Writer）のみで疑似障害
| テストケース | プライマリ（Writer）で維持 | レプリカ（Reader）で維持 |
|---|---|---|
| インスタンス障害 | ○ | - |
| ディスパッチャー障害 | ○ | - |
| ノード障害 | ○ | - |
| ディスク障害 | ○ | - |
2-2. クラスタを組んでいるときのプライマリ（Writer）側疑似障害
| テストケース | プライマリ（Writer）で維持 | レプリカ（Reader）で維持 |
|---|---|---|
| インスタンス障害 | ○ | × |
| ディスパッチャー障害 | ○ | × |
| ノード障害 | ○ | × |
| ディスク障害 | ○ | ○ |
| レプリカ障害 | ○ | ○ |
2-3. クラスタを組んでいるときのレプリカ（Reader）側疑似障害
| テストケース | プライマリ（Writer）で維持 | レプリカ（Reader）で維持 |
|---|---|---|
| インスタンス障害 | ○ | ○ |
| ディスパッチャー障害 | ○ | ○ |
| ノード障害 | ○ | ○ |
| ディスク障害 | ○ | ○ |
| レプリカ障害 | ○ | ○ |
プライマリインスタンス（Writer）側障害でインスタンス／ディスパッチャー／ノード障害が発生した場合、レプリカインスタンス（Reader）が再起動して一旦接続が切れ、再接続した時点ではバッファキャッシュが残っていませんでした。
それ以外では、プライマリインスタンス（Writer）が再起動する場合でも、バッファキャッシュは維持されました。
ノード障害の時はクリアされると思ったのですが（「キャッシュ消えるよ」という説明が書かれているようですし）、インスタンス／ディスパッチャー障害を個別に発生させるのと同じ結果になりました。
※ログは省略します。
3. まとめ
やはり、レプリカインスタンス（Reader）側のバッファキャッシュのウォームアップについては注意が必要なようです。
なお、シミュレーションではなく実際の障害では、DBサービスだけでなくインスタンスのOSレベルの障害が発生する可能性もあるため、先に示したものとは違う結果になる可能性があります。
そのため、この結果は参考程度に見ておいてください。
※勝手な想像では、リアルなノード障害は以下のようになると思っています。
| 障害パターン | プライマリ（Writer）の挙動 | レプリカ（Reader）の挙動 |
|---|---|---|
| プライマリのみ存在 | 再作成される間停止し、再作成後はクリアされて起動 | - |
| クラスタ構成でプライマリ障害 | レプリカからのフェイルオーバーが発生し、クリアされる | 再作成される間停止し、再作成後はクリアされて起動 |
| クラスタ構成でレプリカ障害 | 維持される | 再作成される間停止し、再作成後はクリアされて起動 |
2番目のケースではプライマリインスタンス（Writer）側のバッファキャッシュが維持されそうな気もしますが、レプリカインスタンス（Reader）にREDOログ（※）／メタデータが送られる前または送られる途中でプライマリインスタンス（Writer）が停止するとストレージ上のデータとの間で不整合が生じるため、安全を考慮してクリアされるのではないかと想像しています。
（※）ストレージに記録されるものではなく、レプリカインスタンスのバッファキャッシュに更新データを反映するためにプライマリインスタンスから送信されるもののことです。