Help us understand the problem. What is going on with this article?

Amazon Auroraの障害シミュレーションとバッファキャッシュの維持(ウォームアップ)の関係について確かめてみた

More than 3 years have passed since last update.

以前書いた、

の続きです。

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のサイト(以下のページ)に以前あったはずの、障害シミュレーションコマンドのリファレンスが、なぜか見当たらないですね…。

また、以下の記事で書かれた内容とは、実際の挙動が変わっているところがあるようです(フェイルオーバーしません)。

こちらの記事にも「フェイルオーバーしない」旨、記されていますね。

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)が停止するとストレージ上のデータとの間で不整合が生じるため、安全を考慮してクリアされるのではないかと想像しています。

(※)ストレージに記録されるものではなく、レプリカインスタンスのバッファキャッシュに更新データを反映するためにプライマリインスタンスから送信されるもののことです。


hmatsu47
名古屋で士業向けWebサービスのインフラ構築管理、たまにアプリケーション開発をやっています。 業務利用しているもの、個人研究など、気長にのんびり投稿していきます。ニッチ狙いが多めです。 IPA RISS(001158)・NW・DB/日商・大商2級コレクター?(簿記・ビジネス法務・ビジネス会計)。
https://hmatsu47.hatenablog.com/
infra-workshop
インフラ技術を勉強したい人たちのためのオンライン勉強会です
https://wp.infra-workshop.tech/
Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away