目次
はじめに
こんにちは、omkです。
この間までクリスマスだったのにもう年末ですね。
今回は特定のデータベースだけレプリケーションしたかったのでAurora MySQLのクラスター同士でレプリケーションの設定を導入してみます。
やってみた
基本的な流れは公式ドキュメントの以下に記載がありますがちょっと難しいので以下にまとめていきます。
https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.html
データの同期についてはAuroraのリードレプリカから昇格して切り離す方法もありますが、
今回はmysqldumpでのダンプ・リストアで実現します。
利用するAuroraバージョンはAurora MySQLの3系を想定しています。
Aurora特有のストアドプロシージャで操作するところもいくつかあるのでこちらも参照します。
https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Reference.StoredProcs.html
ソース側でバイナリログの出力を設定
まずはレプリケーション元(ソース)でバイナリログの出力設定を導入します。
ソースとなるクラスターのパラメータグループに以下を設定してバイナリログを出力します。
binlog_format: MIXED
こちらのパラメータはStaticなので反映にはソースクラスターの再起動が必要となります。
バイナリログの出力対象のDBを制御することも可能です。しなくても良いです。
binlog-do-db: DB名
binlog-ignore-db: DB名
レプリカ側でレプリケーション対象を設定
レプリケーション先(レプリカ)でレプリケーションが必要なデータベース・テーブルの設定を行います。
レプリカクラスターのパラメータグループにレプリケーションの対象・除外対象を設定します。
(まるっとレプリケーションする場合はこちらの設定は不要ですが、その場合は代わりにAuroraのリードレプリカを使うことが多いと思います)
このあたりのパラメータを使って表現します。
replicate-do-db: レプリケーション対象のDB名
replicate-do-table: レプリケーション対象のテーブル名
replicate-ignore-db: レプリケーション除外対象のDB名
replicate-ignore-table: レプリケーション除外対象のテーブル名
replicate-wild-do-table: レプリケーション対象のテーブル名(ワイルドカードが使える)
replicate-wild-ignore-table: レプリケーション除外対象のテーブル名(ワイルドカードが使える)
リスト形式なので複数の対象を設定できます。
ちなみにテーブルを指定するときは、
のフォーマットで指定します。 DB名.テーブル名
ソース側でバイナリログの保持期間を設定
Auroraにmysqlクライアントでログインして以下を設定します。
(公式より6日間(144時間)保持の例)
CALL mysql.rds_set_configuration('binlog retention hours', 144);
バイナリログの出力状態については以下のコマンドで確認が出来ます。
SHOW BINARY LOGS;
ソースのダンプを取得する
レプリカにバイナリログでの同期を導入にするにあたってダンプ・リストアで同じ状態にしておきます。
まずはソースでダンプを取得します。
MySQLクライアントで取得する場合は以下のようにして取得できます。
mysqldump -h {ソースクラスターのエンドポイント} --databases {対象DB} --single-transaction --set-gtid-purged=OFF -r replicate.sql -u {ユーザー} -p
余談ですが、Auroraでダンプを取得する際にMySQLのバージョンによっては権限エラーで
が利用できないことがあります。 --single-transaction
困りますね。
レプリカにリストアする
ソースで取得したダンプをレプリカにリストアします。
MySQLクライアントで以下のようにリストアできます。
mysql -h {レプリカクラスターのエンドポイント} -u {ユーザー} -p < backup.sql
ソースサーバにレプリケーション用のユーザーを作成する
ソースサーバでレプリケーションに利用するユーザーを作成します。
CREATE USER 'repl_user'@'<domain_name>' IDENTIFIED BY '<password>';
レプリケーションに必要な権限をユーザーに付与します。
GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'<domain_name>';
レプリケーションの設定を導入するのにバイナリログを確認しておきます。
SHOW BINARY LOGS;
+----------------------------+-----------+-----------+
| Log_name | File_size | Encrypted |
+----------------------------+-----------+-----------+
| mysql-bin-changelog.000001 | 156 | No |
| mysql-bin-changelog.000002 | 1388 | No |
+----------------------------+-----------+-----------+
↑こんな感じで出ます。
もしくはこっち。
> SHOW MASTER STATUS;
+----------------------------+----------+--------------+------------------+-------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+----------------------------+----------+--------------+------------------+-------------------+
| mysql-bin-changelog.000002 | 1388 | | | |
+----------------------------+----------+--------------+------------------+-------------------+
レプリカサーバにレプリケーション設定を導入する
レプリカサーバでレプリケーションの設定を導入します。
ログインして以下を実行します。
CALL mysql.rds_set_external_source ('{ソースクラスターのエンドポイント}', 3306, 'repl_user', '{パスワード}', '{↑のLog_name}', {↑のFile_size}, 0);
GTIDモードが有効の場合はこっちでも可です。
CALL mysql.rds_set_external_source_with_auto_position ('{ソースクラスターのエンドポイント}' , 3306, 'repl_user', '{パスワード}', 0);
これでソースの指定が出来ましたのでレプリケーションを開始します。
CALL mysql.rds_start_replication;
レプリケーションできたことを確認します。
SHOW REPLICA STATUS
Replica_SQL_Running_Stateあたりを見ると状態がわかります。
これでAuroraクラスター間でレプリケーションが設定できました。
その他備忘
レプリケーションを止める場合
CALL mysql.rds_stop_replication;
ソース設定を消す場合
CALL mysql.rds_reset_external_source;
終わりに
ストアドプロシージャを使わないと権限的に操作できない部分が多かったので若干焦る部分もありましたが、ちゃんと必要なものは用意されているみたいでなんとか出来ました。
あまりAuroraクラスター間でレプリケーションすることは多くはないかもしれませんが、実現できるよーという記事も少なかったので誰かの役に立つことを祈ります。
以上、良いお年を。
アーキテクト課のomkです。
AWSについて雑多に取り組んだ内容を発信しています!!