既にサービスで稼働している MySQL on EC2 を Aurora に移行するために,以下のようなレプリケーション環境を検証用に構築して試した.Percona Xtrabackup でリストアをすると高速にできるらしいけど,今回は環境の制約もあって mysqldump 経由でリストアをする設計を選んだ.
レプリケーション環境を構築する手順は以下のドキュメントに詳しくまとまっていた.
バイナリログを出力する
今回は dbs on EC2 → Aurora Writer にレプリケーションをするため,スレーブ環境でもバイナリログを出力しておく必要があった.詳細は割愛するが /etc/my.cnf
に log-bin
を追記して対応した.
mysqldump に --master-data=2
オプションを追加した
mysqldump で取得したバックアップをベースラインとしてレプリケーションをする場合に CHANGE MASTER TO
で合わせるポジションを把握する必要がある.そのためには mysqldump に --master-data
オプションが必要で,今回は CHANGE MASTER TO
をコメント状態で出力するために --master-data=2
とした.--master-data
のまま出力してしまうとリストア時に CHANGE MASTER TO
も流れてしまうため --master-data=2
にしておくと良い.
-- Position to start replication or point-in-time recovery from -- -- CHANGE MASTER TO MASTER_LOG_FILE='bin.000001', MASTER_LOG_POS=12345;
Aurora Writer でレプリケーションを開始するときに CHANGE MASTER TO
は使えない
出力したバックアップを Aurora にリストアしたら,次はポジションを合わせてレプリケーションを開始する.ただし RDS では CHANGE MASTER TO
と START SLAVE
が実行できないようになっていて,実行しようとすると,権限のエラーが出る.
mysql> CHANGE MASTER TO MASTER_HOST='xxx', -> MASTER_USER='replication', -> MASTER_PASSWORD='password', -> MASTER_LOG_FILE='bin.000001', -> MASTER_LOG_POS=12345; ERROR 1227 (42000): Access denied; you need (at least one of) the SUPER privilege(s) for this operation mysql> START SLAVE; ERROR 1045 (28000): Access denied for user 'xxx'@'%' (using password: YES)
どうするかと言うと,RDS 側に登録されているストアドプロシージャを使う必要がある.
mysql.rds_set_external_master
mysql.rds_start_replication
実際に発行するコマンドとしては以下のようになる.ストアドプロシージャに与える値は CHANGE MASTER TO
と同じなので,特に困ることは無いかと思う.ただ1点,ホスト名に Private IP を指定する必要があった.今の構成だと EC2 に hosts を配ってるため,ホスト名で参照できていたが,Aurora から見ると参照できなかった.
mysql> CALL mysql.rds_set_external_master ('1.2.3.4', 3306, 'replication', 'password', 'bin.000001', 12345, 0); mysql> CALL mysql.rds_start_replication; mysql> SHOW SLAVE STATUS\G
あとは Read_Master_Log_Pos
あたりの値を見ながらモニタリングすれば大丈夫かと.ちなみに,レプリケーションを停止するときは,以下のストアドプロシージャを実行する.
mysql.rds_stop_replication
Aurora Writer の Seconds_Behind_Master
は CloudWatch で見れなかった
dbs on EC2 → Aurora Writer のレプリ遅延をモニタリングしたかったけど,CloudWatch では難しそうだった.Aurora では「Aurora バイナリログレプリカの遅延 : AuroraBinlogReplicaLag」メトリクスがあるけど,これは Aurora Writer → Aurora Reader のレプリ遅延のことで,Aurora Writer のメトリクスではなかった.よって,取り急ぎ Aurora Writer で SHOW SLAVE STATUS;
を実行して,Seconds_Behind_Master
の値を確認するようにしている.
CloudWatch で取得してるメトリクスに関しては,以下のドキュメントに詳しく載っている.
まとめ
稼働中の MySQL on EC2 を Aurora にレプリケーションする構成を簡単に構築できた.レプリケーションの階層は多いけど,特に気になるレプリ遅延は無かった.引き続き検証を続けていく!