読者です 読者をやめる 読者になる 読者になる

MySQL on EC2 → Aurora にレプリケーションをしてみた

既にサービスで稼働している MySQL on EC2 を Aurora に移行するために,以下のようなレプリケーション環境を検証用に構築して試した.Percona Xtrabackup でリストアをすると高速にできるらしいけど,今回は環境の制約もあって mysqldump 経由でリストアをする設計を選んだ.

f:id:kakku22:20170203185237j:plain

レプリケーション環境を構築する手順は以下のドキュメントに詳しくまとまっていた.

バイナリログを出力する

今回は dbs on EC2 → Aurora Writer にレプリケーションをするため,スレーブ環境でもバイナリログを出力しておく必要があった.詳細は割愛するが /etc/my.cnflog-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 TOSTART 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 側に登録されているストアドプロシージャを使う必要がある.

実際に発行するコマンドとしては以下のようになる.ストアドプロシージャに与える値は 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 あたりの値を見ながらモニタリングすれば大丈夫かと.ちなみに,レプリケーションを停止するときは,以下のストアドプロシージャを実行する.

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 で取得してるメトリクスに関しては,以下のドキュメントに詳しく載っている.

docs.aws.amazon.com

まとめ

稼働中の MySQL on EC2 を Aurora にレプリケーションする構成を簡単に構築できた.レプリケーションの階層は多いけど,特に気になるレプリ遅延は無かった.引き続き検証を続けていく!