RDSにはPromote Read Replicaという機能があり、リードレプリカで動いてるサーバをマスターに昇格させることができる機能がある。
しかしその際に起こる挙動はしっかり把握しておかなければトラブルの元になるので機能としてではなく、アーキテクチャとしてしっかり把握しておく必要がある。
今回はRDSのMySQLのサポートが切れるということだったので、その際に検証したことを記録として残します。
https://aws.amazon.com/jp/blogs/news/amazon-rds-mysql-56x-minor-version-announce/
サポート切れとかの対応方法は運用前に計画しておくことが望ましいので、Promote Read Replicaの挙動を知っていただけたらと思います。
想定シナリオ
MySQL 5.6.19aでマスターサーバ1台で動いているサービスがある(MultiAZの有無は問わない)
MySQL 5.6.19aをMySQL 5.7.16 にアップグレードしたい
作業内容
- 現在動いている MySQL 5.6.19a のレプリカを作成する
- レプリカを 5.7.16 にアップデートする
- レプリカを昇格させる
- アプリケーションのソースコードを修正し、昇格した方にDBを向ける
挙動
スレーブを昇格させる時の挙動について
まずスレーブを昇格させるにあたって5分ぐらいスレーブにダウンタイムが発生する
これはサーバの再起動になる
マスタースレーブの関係性
マスタースレーブの関係性だが、マスターとスレーブが入れ替わるのではなく、スレーブが独立する形になる。
そのため昇格コマンドを実行したタイミングからスレーブへのデータ反映は一切されず、その時点のデータを持った状態で新しいインスタンスが立ち上がるということになる。
データのズレが発生するとすればその5分間の書き込み + アプリケーションのDBの向き先を変更するまでの時間になる
発生する問題点
-
データが破損する？
- しない(但し、MySQLの外側、例えばS3とかとデータが連動している場合は発生するかも)
-
Endpointの修正が必要か
- 必要、新しいインスタンスが立ち上がってくるわけなので、新しいインスタンスに向ける必要がある
-
昇格時にエラーが発生しないか
- しない
- しないがデータは新しいDBに反映されない
まとめ
INSERTが任意のタイミングでしか発生しないサービスであればダウンタイム0でMySQLのバージョンアップは可能であると思われる。