更新日： 2019/7/28
フェイルオーバー
-
Auroraクラスター側
-
マスターのダウン
- レプリカがあれば、そのうちの1台にフェイルオーバーする（マスターに昇格する）。フェイルオーバーは通常30秒以内に完了する。
- フェイルオーバーによってクラスターエンドポイントが指すIPアドレスが変更される。（DNSレコードの更新）
- フェイルオーバーによってマスターが変わった際にすべてのレプリカも再起動される。つまりレプリカへの接続は一旦切断される。
- レプリカにマスターに昇格させる優先順位を指定することができる
- レプリカがいない場合は、マスターと同じAZに新しくDBインスタンスを作成する。
- クライアントに正常完了が返った書き込みついてはマスターのクラッシュでも消えていることはない。クラッシュのタイミングによっては正常完了が返らなかった書き込みが実際は完了しているということはありえそうである
-
レプリカのダウン
- そのレプリカに接続していたクライアントは切断されるので影響あり
- 読み取りエンドポイントからは自動的に振り分け対象から削除される
- マスターに対する影響は特になさそうである
- 一定数のレプリカを保ちたいのであれば Auto Scaling Group を構成する（要確認)
-
クライアント側
-
エンドポイント(DNS)を利用したフェイルオーバー
- クラスターエンドポイントはその時のマスターのIPアドレスを返すので、通常30秒以内で新しいマスターに接続できるようになるはずである
- クライアント側で再接続する仕組みは必要
- DNSの情報はいろいろなレイヤーでキャッシュされるので、キャッシュの保持期間など設定の変更が推奨されるとのこと
-
高速フェイルオーバー
- INFORMATION_SCHEMA.REPLICA_HOST_STATUS や @@innodb_read_only を利用したフェイルオーバー。どのインスタンスがマスターなのかや接続しているインスタンスがマスターなのかレプリカなのかがわかる。ニアリアルタイムの情報とのこと
- mariadb connector/jを使用した検証では4秒以下でフェイルオーバーした
- クライアント側に専用の処理が必要。公式でお勧めしているのはmariadb connector/jのドライバー
-
mariadb connector/j (JDBCドライバー)
- マスターとレプリカの両方に同時に接続をはる。
- マスターには指定した接続数だけはられるが、レプリカが複数ある場合は、レプリカについては指定した接続数が案分されて接続されるようである
- 通常はマスターへの接続が使用される。Connection の setReadOnly を使用してtrueを設定した場合のみ、レプリカの接続が使用される
- 高速フェイルオーバーを使用したい場合は、JDBC接続文字列に aurora オプションとクラスターエンドポイントを指定する必要がある。そこからドライバーがクラスターの情報を取得するとのこと
- 読み取りエンドポイントのみを使用する場合はJDBC接続文字列にはフェイルオーバーオプション無しで、読み取りエンドポイントを指定する形になる
- レプリカからレプリカ(またはマスター)への高速フェイルオーバーはサポートしていないようである(マスタのみ)。読み取りエンドポイントを利用する方法のみ（要調査）
-
ProxySQL
- クライアント(アプリ)とDBの間にプロキシとして配置する形になる。最近AWSの紹介ブログがあり、推しているぽい。高機能とのこと
- 無償、OSS、GPLライセンス
- 要調査。これはこれで管理する必要があるレイヤーが増えるが・・・