ablog

不器用で落着きのない技術者のメモ

Aurora MySQL互換のフェイルオーバー

AWS
障害挿入クエリ（Fault Injection Queries）
  • INSTANCE はMySQLインスタンスをクラッシュさせる。
  • DISPATCHER はクラスターボリュームに書込むディスパッチャをクラッシュさせる。
  • NODEはMySQLインスタンスとディスパッチャの両方をクラッシュさせ、キャッシュが削除される。

Syntax

ALTER SYSTEM CRASH [ INSTANCE | DISPATCHER | NODE ];

Options
This fault injection query takes one of the following crash types:

  • INSTANCE—A crash of the MySQL-compatible database for the Amazon Aurora instance is simulated.
  • DISPATCHER—A crash of the dispatcher on the master instance for the Aurora DB cluster is simulated. The dispatcher writes updates to the cluster volume for an Amazon Aurora DB cluster.
  • NODE—A crash of both the MySQL-compatible database and the dispatcher for the Amazon Aurora instance is simulated. For this fault injection simulation, the cache is also deleted.

The default crash type is INSTANCE.

Testing Amazon Aurora Using Fault Injection Queries - Amazon Aurora
エンドポイント
  • クラスターエンドポイント（例:mycluster.cluster-************.us-east-1.rds.amazonaws.com）
  • 読み取りエンドポイント（例:mycluster.cluster-ro-************.us-east-1.rds.amazonaws.com）
    • リードレプリカに接続するエンドポイント。
    • 複数のリードレプリカがある場合、いずれかにルーティングする。
    • リードレプリカが存在しない場合はプライマリ DB インスタンスに接続する。
  • カスタムエンドポイント（例:mycluster.cluster-custom-************.us-east-1.rds.amazonaws.com）
    • 任意のインスタンスにルーティングするエンドポイントを作成できる。
  • インスタンスエンドポイント
フェイルオーバーの優先度
  • フェイルオーバーの優先度は、最も高い 0 から最も低い 15 まで設定できる。
  • プライマリインスタンスに障害が発生すると、優先度の高いリードレプリカをプライマリインスタンスに昇格する。
  • 同じ優先度のリードレプリカが複数ある場合は最大サイズのレプリカを昇格する。同じ優先度とサイズのリードレプリカが複数ある場合、任意のレプリカを昇格する。
  • クラスターにリードレプリカがない場合は障害時にプライマリインスタンスが再作成される。

補足

エンドポイントは CNAME
$ dig +noall +ans \
aurora-postgres105.cluster-********.ap-northeast-1.rds.amazonaws.com \
aurora-postgres105.cluster-ro-********.ap-northeast-1.rds.amazonaws.com \
tokyo-1a.cluster-custom-********.ap-northeast-1.rds.amazonaws.com \
aurora-postgres105-a.********.ap-northeast-1.rds.amazonaws.com \
aurora-postgres105-a-ap-northeast-1a.********.ap-northeast-1.rds.amazonaws.com \
aurora-postgres105-c.********.ap-northeast-1.rds.amazonaws.com

aurora-postgres105.cluster-********.ap-northeast-1.rds.amazonaws.com. 5 IN CNAME aurora-postgres105-a.********.ap-northeast-1.rds.amazonaws.com.
aurora-postgres105-a.********.ap-northeast-1.rds.amazonaws.com. 5 IN CNAME ec2-**-***-109-247.ap-northeast-1.compute.amazonaws.com.
ec2-**-***-109-247.ap-northeast-1.compute.amazonaws.com. 604800	IN A **.***.109.247
aurora-postgres105.cluster-ro-********.ap-northeast-1.rds.amazonaws.com. 1 IN CNAME	aurora-postgres105-c.********.ap-northeast-1.rds.amazonaws.com.
aurora-postgres105-c.********.ap-northeast-1.rds.amazonaws.com. 5 IN CNAME ec2-**-***-100-225.ap-northeast-1.compute.amazonaws.com.
ec2-**-***-100-225.ap-northeast-1.compute.amazonaws.com. 604800	IN A **.***.100.225
tokyo-1a.cluster-custom-********.ap-northeast-1.rds.amazonaws.com. 1 IN CNAME aurora-postgres105-a-ap-northeast-1a.********.ap-northeast-1.rds.amazonaws.com.
aurora-postgres105-a-ap-northeast-1a.********.ap-northeast-1.rds.amazonaws.com. 5 IN CNAME ec2-**-**-33-213.ap-northeast-1.compute.amazonaws.com.
ec2-**-**-33-213.ap-northeast-1.compute.amazonaws.com. 604800 IN A **.**.33.213
aurora-postgres105-a.********.ap-northeast-1.rds.amazonaws.com. 5 IN CNAME ec2-**-***-109-247.ap-northeast-1.compute.amazonaws.com.
ec2-**-***-109-247.ap-northeast-1.compute.amazonaws.com. 604800	IN A **.***.109.247
aurora-postgres105-a-ap-northeast-1a.********.ap-northeast-1.rds.amazonaws.com. 5 IN CNAME ec2-**-**-33-213.ap-northeast-1.compute.amazonaws.com.
ec2-**-**-33-213.ap-northeast-1.compute.amazonaws.com. 604800 IN A **.**.33.213
aurora-postgres105-c.********.ap-northeast-1.rds.amazonaws.com. 5 IN CNAME ec2-**-***-100-225.ap-northeast-1.compute.amazonaws.com.
ec2-**-***-100-225.ap-northeast-1.compute.amazonaws.com. 604800	IN A **.***.100.225
エンドポイントの TTL は短い
ストレージノードは同じデータを6つコピーしていない

Auroraでは、データベースボリュームは10GBのデータセグメントで構成されています。 これらのセグメントはプロテクショングループとして複製され、6つのコピーが3つのAZに分散しています。 しかし、6つのコピーはすべて同じではありません。 コピーの半分はフルセグメントで、ボリュームの10GB部分のデータページとログレコードの両方を含んでいます。 残りの半分は、ログレコードのみを含むテールセグメントです。 各AZには、1つのフルセグメントと1つのテールセグメントが含まれています。

ほとんどのデータベースには、REDOログストレージよりもはるかに多くのデータブロックストレージがあります。 フルセグメントとテールセグメントを組み合わせて使用すると、Auroraの物理ストレージに必要な要件がデータベースの6倍から、3倍より少し多い程度になります。 “AZ+1″の障害に耐えるように設計されたシステムでは、これは最小限のレプリケーションファクターです。

Amazon Aurora Under the Hood: クオーラムセットを使ったコスト削減 | Amazon Web Services ブログ

参考

DB クラスターのプライマリインスタンスが失敗した場合、Aurora は以下のいずれかの方法で、新しいプライマリインスタンスに自動的にフェイルオーバーします。

DB クラスターに 1 つ以上の Aurora レプリカがある場合は、障害発生中に 1 つの Aurora レプリカがプライマリインスタンスに昇格されます。障害イベントによって短い中断が発生し、その間例外によって読み取りと書き込みオペレーションが失敗します。ただし、一般的なサービスの復元時間は 120 秒未満であり、多くの場合 60 秒未満で復元されます。DB クラスターの可用性を高めるために、複数のアベイラビリティーゾーン内で少なくとも 1 つ以上の Aurora レプリカを作成することをお勧めします。

各レプリカに優先度を割り当てることで、Aurora レプリカがプライマリインスタンスに昇格される順序をカスタマイズできます。優先度の範囲は、最も高い 0 から最も低い 15 までです。プライマリインスタンスが失敗した場合、Amazon RDS は最も高い優先度の Aurora レプリカを新しいプライマリインスタンスに昇格します。Aurora レプリカの優先度はいつでも変更できます。優先度を変更しても、フェイルオーバーはトリガーされません。

複数の Aurora レプリカで同じ優先度を共有でき、その場合は昇格階層が発生します。複数の Aurora レプリカで同じ優先度を共有する場合、Amazon RDS は最大サイズのレプリカを昇格します。複数の Aurora レプリカで同じ優先度とサイズを共有する場合、Amazon RDS は同じ昇格階層の任意のレプリカを昇格します。

DB クラスターに Aurora レプリカが含まれていない場合、障害イベントの発生時にプライマリインスタンスが再作成されます。障害イベントによって中断が発生し、その間例外によって読み取りと書き込みオペレーションが失敗します。新しいプライマリインスタンスが再作成されると、サービスが回復します。これは、通常は 10 分未満で行われます。Aurora レプリカのプライマリインスタンスへの昇格は、新しいプライマリインスタンスの作成よりもはるかに短時間で実行されます。

Aurora DB クラスターのバックアップと復元の概要 - Amazon Aurora

dev.classmethod.jp
dev.classmethod.jp
https://www.allthingsdistributed.com/files/p1041-verbitski.pdf
atsuizo.hatenadiary.jp
qiita.com
docs.aws.amazon.com


2019/10/8追記:

  • RDS も TTL は5秒
% dig +noall +ans db1.************.ap-northeast-1.rds.amazonaws.com
db1.************.ap-northeast-1.rds.amazonaws.com. 5★TTLは5秒 IN	A 172.31.**.***