スマートスタイル TECH BLOG

MySQL InnoDB Cluster on EC2での可用性について

はじめに

MySQL InnoDB ClusterをAWS上で稼働させた場合に、同AZで稼働させる場合と、DRの観点から異なるAZで稼働させた場合の動きをみたくて試してみました。

切り替わり時の挙動確認が目的のため、データサイズやワークロードについては一切考慮しておりませんのでご容赦ください。

環境構築については下記の記事とほぼ同様の設定をしております。
MySQL 8.0.13 で MySQL InnoDB Cluster を構築する
*異なるサブネット(AZ)でClusterを構築する際には別途オプションが必要となりますので、そちらは下部に記載しております。

環境

info
OS CentOS Linux release 7.5.1804 (Core)
MySQL 8.0.13 MySQL Community Server – GPL
EC2 TYPE t2.micro

同じAZ

まずは全て同一のAZ(1a)で実行してみました。

構成

マシン IP
node1 172.26.100.7
node2 172.26.100.95
node3 172.26.100.112
router(shell) 172.26.100.117

テーブル作成

定期的(1秒間隔)にPrimaryへ書き込みを行い、切り替わりまでの時間を見るため、テスト用のテーブルを作成します。

書き込み開始

下記のようなスクリプトを用意して書き込み実施します。

PrimaryのMySQLサーバーをダウンさせて擬似的に障害状態に

node1のmysqldを停止

書き込み結果

5秒で書き込みが再開出来ました。

異なるAZ

上記の図からRouterと同じAZに所属しているNode1(Primary)を停止させます。

構成

マシン IP
node1 172.26.100.154
node2 172.26.101.102
node3 172.26.104.254
router(shell) 172.26.100.210

追加手順

構築手順はほとんど同じですが、clusterを作成する際と、clusterにインスタンスを追加する際にWhitelistの追加が必要です。

PrimaryのMySQLサーバーをダウンさせて擬似的に障害状態に

node1のmysqldを停止

書き込み結果

node3がPrimaryに昇格しました。
そして、データ書き込み再開は

同じAZと変わりなく使用できています!

注意

公式ドキュメントのよくある質問に下記のWarningが記載されています。

グループメンバー間のレイテンシーには十分注意してください。
ちなみに今回AZを跨いでrouterからそれぞれのnodeに対してPingで確認した結果は下記でした。

まとめ

可用性を考え、異なるAZで起動させれるのは嬉しいですね。
また書き込み開始もAZを跨いでも遜色ないところはすごいです。

MySQL

 

Return Top