こんにちは！SRE を担当している多田です(@tada_infra).
本番稼働中の Aurora のデータを別の Aurora に移行するために DMS を使おうと思いバイナリログを有効化して DMS の準備をしていました.ただ,DMS のトラブルシューティングを確認してみるとオブジェクトの作成ができないものがあり,ソースデータベース とターゲットデータベースが同一の場合オブジェクトはネイティブツールを使うことが記載がありました.今回のデータ移行も同一 Aurora 間なのでネイティブな機能であるバイナリログレプリケーションで行う方法を使うために設定方法を確認したのでその内容をまとめていきます.
外部キーとセカンダリインデックスが見つからない
AWS DMS は、テーブル、プライマリキー、場合によっては一意のインデックスを作成しますが、効率的にソースからデータを移行するために必要ではない他のオブジェクトは作成されません。たとえば、セカンダリインデックス、非プライマリキーの制約、データデフォルトは作成されません。
データベースからセカンダリオブジェクトを移行するには、ソースデータベースと同じデータベースエンジンに移行中の場合、データベースのネイティブツールを使用します。ソースデータベースで使用したものとは異なるデータベースエンジンに移行してセカンダリオブジェクトを移行する場合は、AWS Schema Conversion Tool (AWS SCT) を使用します。
Aurora 間でのバイナリログレプリケーション
Aurora から Aurora へのバイナリログレプリケーションの方法は下記のドキュメントで紹介されてますが,ドキュメントではスナップショットから復元するパターンです.この記事ではクローン機能を使って確認したのでその内容で整理します.
バイナリログレプリケーションのためにやることは大きく3つです.
- クラスターパラメーターグループの
binlog_formatのパラメーターをMIXEDに変更 - レプリケーション元の Aurora でレプリケーション用ユーザーとバイナリログ保存期間を設定
- Aurora をクローンしてクローンしたクラスターでレプリケーションを実行
1.クラスターパラメーターグループのbinlog_formatのパラメーターをMIXEDに変更
Aurora クラスターパラメーターグループのbinlog_formatのパラーメーターをMIXEDに変更します.バイナリログの有効化のために WRITER 側のインスタンスを再起動します.再起動後,バイナリログの記録ファイルが出る状態になっていることを確認します.
mysql> show global variables like 'log_bin'; +---------------+-------+ | Variable_name | Value | +---------------+-------+ | log_bin | ON | +---------------+-------+ 1 row in set (0.01 sec) mysql> show variables like 'binlog_format'; +---------------+-------+ | Variable_name | Value | +---------------+-------+ | binlog_format | MIXED | +---------------+-------+ 1 row in set (0.00 sec) mysql> show binary logs; +----------------------------+-----------+ | Log_name | File_size | +----------------------------+-----------+ | mysql-bin-changelog.000001 | 120 | | mysql-bin-changelog.000002 | 43424 | +----------------------------+-----------+ 2 rows in set (0.00 sec)
2. レプリケーション元の Aurora でレプリケーション用ユーザーとバイナリログ保存期間を設定
次にレプリケーション元の Aurora でレプリケーション用ユーザーとバイナリログ保存期間を設定します.まずレプリケーションユーザーですが,今回ドキュメント記載の repl_user と権限で作っています.
mysql> CREATE USER 'repl_user'@'%' IDENTIFIED BY '<パスワード>'; Query OK, 0 rows affected (0.01 sec) mysql> GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'%' IDENTIFIED BY '<パスワード>' Query OK, 0 rows affected (0.01 sec)
ユーザー作成後,レプリケーションが終わるまでのログの保存期間を設定するため,バイナリログ保存期間を指定します.確認した限りですが,ドキュメント記載の最大値は 2,160 (90 日)はエラーが出て利用者側で指定できるのは168(7日間)までのようなのでこの値で指定します.なお,最大値の期間を指定するためには AWS サポートへの問合せが必要になることが AWS サポートへの問合せで教えていただきました.
mysql> CALL mysql.rds_set_configuration('binlog retention hours', 168); Query OK, 0 rows affected (0.02 sec)
3. Aurora をクローンしてクローンしたクラスターでレプリケーションを実行
準備ができたのでレプリケーション先の Aurora クラスターをクローン機能で複製します.復元したクラスターの WRITER インスタンスのログイベントを確認します.写真のイベントだとログファイル000118の245880の箇所でバイナリログが切れています.レプリケーションを確認したバイナリログの番号と開始位置から開始していきます.
mysql> CALL mysql.rds_set_external_master ('<レプリケーション元の Aurora WRITER エンドポイント>', 3306, 'repl_user', '<パスワード>', 'mysql-bin-changelog.000118', 245880, 0);` Query OK, 0 rows affected (0.19 sec) mysql> CALL mysql.rds_start_replication; +-------------------------+ | Message | +-------------------------+ | Slave running normally. | +-------------------------+ 1 row in set (1.02 sec)
SHOW SLAVE STAUS でチェックしてSeconds_Behind_Masterが0になるまでいきます.自分が検証したエラーとしてレコード重複のメッセージがでてきて無視していいものはCALL mysql.rds_skip_repl_error;でスキップしたり,外部キー制約で同期できなかったレコードはSET FOREIGN_KEY_CHECKS = 0を無効化して同期していきました.
mysql> SHOW SLAVE STATUS\G; *************************** 1. row *************************** Slave_IO_State: Waiting for master to send event Master_Host: xxxx.ap-northeast-1.rds.amazonaws.com Master_User: repl_user Master_Port: 3306 Connect_Retry: 60 Master_Log_File: mysql-bin-changelog.000118 ~中略~ Seconds_Behind_Master: 0 ~中略~ 1 row in set (0.00 sec)
まとめ
Aurora クラスター間のバイナリログレプリケーションを行う方法をクローン機能使った場合で整理してみました.個人的にクローンを初めて使ったのですが,高速に復元できてすぐにレプリケーションを走らせられたのがとても良い体験でした.今後こういったレプリケーションは Aurora のバージョンアップの時にも使っていけるかと思ったのでその時は適宜使っていきます.
関連記事
元記事
元記事はこちらです
最後に
そんなスナックミーではもりもりコードを改善し、開発していきたいバックエンドエンジニア、テックリードを募集中です。 採用の最新情報はこちらにありますので、ご興味ある方はご確認ください！
