概要
Cloud SQL for MySQL (第 2 世代) がサポートしている、準同期レプリケーションによる高可用性構成で DB インスタンスを作ってみた話。
AWS の RDS で言うところの Multi-AZ 配置 に相当する機能かと。
設定
以下、新規 DB インスタンス作成時に高可用性向け設定を行う想定。
とりあえず、普通に DB インスタンスを作る。
推奨されている第 2 世代のインスタンスを選択。
適当にインスタンス設定を入力して、最下部にある設定オプションを表示を押下。
スペック等を適宜指定。
高可用性の箇所にあるフェイルオーバーレプリカの作成にチェックを入れる。
接続許可する IP を指定 (DB 作成後でも設定変更できる)。
これで作成すれば、高可用性構成の DB インスタンスができる。
DB インスタンス詳細画面
この画面から、ダンプファイルのエクスポートやインポート、手動フェイルオーバー等が可能。
また、接続時に指定する IP 等もここで確認できる。
Amazon RDS の場合、画面上、Multi-AZ のスタンバイ機はユーザーから隠蔽されていたような記憶がある。しかし、Cloud SQL の場合、わりと普通にフェイルオーバーレプリカが確認できる。
DB ユーザーの管理。
データベースの管理。
もう phpMyAdmin とかいらないんじゃないかというレベル (嘘)。
接続許可 IP の設定。
SSL 周りの GUI 管理機能も充実している。
フェイルオーバーの挙動
英語版ドキュメントに詳しく図示されている。フェイルオーバー後に自動的にフェイルオーバーレプリカを別のゾーンにまた新しく作るらしい。
フェイルオーバー実行条件
日本語ドキュメントだと若干引っかかる書かれ方。
マスターがあるゾーンが停止状態になると、Cloud SQL がフェイルオーバーを開始します。マスター インスタンスの問題の原因がゾーンの停止状態ではない場合、フェイルオーバーは開始されません。
フェイルオーバーがトリガーされるとき
ちなみに、Amazon RDS (MySQL) の場合、フェイルオーバーの実行条件は下記の通り。
・アベイラビリティーゾーン機能停止が発生しました。
・プライマリ DB インスタンスのエラー.
・この DB インスタンスの DB インスタンスクラスが変更されました。
・DB インスタンスのオペレーティングシステムでソフトウェアのパッチ適用中.
・DB インスタンスの手動フェイルオーバーが [Reboot with failover (フェイルオーバーで再起動)] を使用して開始されました。
Amazon RDS のフェイルオーバープロセス
GCP ショボくね？
ゾーン障害以外の異常は自分で監視、フェイルオーバーしなくちゃならないのか、と思いつつ英語版ドキュメントを見ると、下記の通り。
Each second, the primary instance writes to system database as a heartbeat signal. If multiple heartbeats aren’t detected (and the failover replica is healthy), failover is initiated. This occurs if the primary instance is unresponsive for approximately 60 seconds or the primary zone experiences an outage.
Failover overview
ゾーン障害以外だけでなく、 約 60 秒間プライマリが無応答の場合にフェイルオーバーするって書いてあるじゃん……。
接続先 IP
何もしなくて良い。 自動的に接続先 IP の指す DB インスタンスが変更される。
マスターがフェイルオーバー レプリカにフェイルオーバーすると、インスタンスへの既存の接続はすべて切断されます。しかし、アプリケーションは同じ接続文字列や IP アドレスを使用して再接続できます。フェイルオーバー後にアプリケーションを更新する必要はありません。
フェイルオーバーがアプリケーションやインスタンスに与える影響
終わりに
天下の Google 先生のインフラなので、しっかり監視すれば安心して使えそう。
