Auroraメモ

Auroraの自動化機能

• ストレージの自動修復
• キャッシュを自動的に最適に「暖気」
• クラッシュからのリカバリ

ストレージの自動修復

• Auroraはクラスターボリュームを構成するディスクボリュームの障害を自動的に検知する
• ディスクボリュームのセグメントに障害が起きたとき、Auroraはすぐにそのセグメントを修復する。修復するときに、そのセグメントのデータが最新状態に一致するように、他のボリュームのデータを使用する。
• 上記によりデータの喪失を回避し、ディスク障害からの復旧のためにポイントインタイムのリストアの必要性を減少させている

キャッシュを自動的に最適に「暖気」

• シャットダウン後や再起動後のDB起動時に、Auroraはバッファプールキャッシュを「暖気」する。Auroraは、インメモリのページキャッシュに保持されている使用頻度の高いクエリが使用するページをバッファプールに事前に読み込む。
• バッファプールの「暖気」が不要になり、パフォーマンス上の利点になる
• AuroraのページキャッシュはDBとは別のプロセス(のメモリ)で管理されていて、それによりページキャッシュはDBとは関係なく存続している
• DB障害後の再起動時には、存続しているページキャッシュの最新の状態を使用してバッファプールは「暖気」されるようになっている

クラッシュからのリカバリ

• Auroraはバイナリログなしでもクラッシュから即座にリカバリし、稼働を続けられるように設計されている
• Auroraは複数のスレッドで並行して非同期的にクラッシュからのリカバリを行い、クラッシュ後すぐに再開し使用可能になるようにしている
• Auroraでは、DBのクラッシュ後のリカバリとして最後のチェックポイントからのREDOログを適用する必要はない(別の仕組みになっている)
• Auroraではほとんどの場合、DBが再度起動するまでの時間は60秒以内になる
• AuroraではDBのプロセスからバッファキャッシュが移されていて、DB再起動時にすぐに使用できる状態になっている。これによりキャッシュが載るまでの間、性能が低下するのを避けることができる
• クラッシュからのリカバリについてはこのページも参照
• Aurora MySQLでのバイナリログの使用とクラッシュからのリカバリにおける考慮事項
  • バイナリログを使用すると、クラッシュ後にバイナリログからリカバリすることをDBインスタンスに強制することになるので、リカバリの時間に直接的に影響する
  • 使用するバイナリログの種類によってログの量と情報量が異なる。binlog_formatパラメータの指定に応じてログのデータ量が異なる。
    • ROW 最も多い
    • STATEMENT 最も少ない
    • MIXED 中間。データ整合性とパフォーマンスのバランスが最も良い
    リカバリ時にDBインスタンスが処理する必要があるデータが多ければ多いほど、リカバリ時間は増加する
  • AuroraはDBクラスター内でのデータのレプリケーション、ポイントインタイムのリストア(PITR)にバイナリログを必要としない（つまりバイナリログは使用しなくても問題ないということか？）
  • 外部へのレプリケーションや外部へのバイナリログストリームのためにバイナリログを必要としないのであれば、binlog_formatパラメータにはOFFを指定して無効化しておくことを推奨。それによりリカバリ時間が減少する
  • Auroraのバイナリログとレプリケーションについてはこのページも参照