Amazon-RDS

Aurora MySQLクラスター間でレプリケーションを実行してみた

はじめに

こんにちは、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クラスター間でレプリケーションすることは多くはないかもしれませんが、実現できるよーという記事も少なかったので誰かの役に立つことを祈ります。

以上、良いお年を。

返信を残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です

CAPTCHA