この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
はじめに
Aurora は本家 MySQL とはことなり binlog によらないレプリケーションを採用しており、プレビューの当初は binlog を有効にできませんでした。いつからか Aurora が binlog 対応したようなので、この機能をつかって Amazon Aurora から Amazon MySQL にレプリケートしてみたいと思います。
全体の流れ
同じ VPC 内に
- RDS for Aurora
- RDS for MySQL
を起動します。
その後、Aurora の binlog パラメーターを有効にし、この binlog をもとに MySQL にレプリケートさせます。
レプリケート方法は次のドキュメントと同等の手順をとります。
Amazon RDS の外部で実行される MySQL インスタンスとのレプリケーション
RDS インスタンスの起動
RDS for Aurora の起動
主役となる Aurora インスタンスです。
まだ東京リージョンにはやってきていません。以下のリージョンでご利用ください。
- US East (N. Virginia)
- US West (Oregon)
- EU (Ireland)
RDS for MySQL の起動
将来的に Aurora のリードレプリカとなる MySQL インスタンスです。 画面をポチポチしながら MySQL 5.6 を起動します。
注意点としては、バックアップが有効になっていないと、リードレプリカになれません。
維持費を削ろうと "Backup Retention Period : 0 days" で作成すると、リードレプリカ化しても、以下の様な警告メッセージが表示され、レプリケーションが有効になりません。
Read replica creation requires backups to be enabled. Use the modify wizard to enable backups for supported engine versions.
テーブルにテストデータを投入
Aurora インスタンスにテストデータを投入します。
mysql> CREATE TABLE characters(
-> id Integer NOT NULL AUTO_INCREMENT,
-> name varchar(255) NOT NULL,
-> PRIMARY KEY (id)
-> );
Query OK, 0 rows affected (0.22 sec)
mysql> INSERT INTO characters(name) VALUES
-> ('Max Rockatansky'),
-> ('Imperator Furiosa'),
-> ('Nux');
Query OK, 3 rows affected (0.23 sec)
Records: 3 Duplicates: 0 Warnings: 0
mysql> select * from characters;
+----+-------------------+
| id | name |
+----+-------------------+
| 1 | Max Rockatansky |
| 2 | Imperator Furiosa |
| 3 | Nux |
+----+-------------------+
3 rows in set (0.25 sec)
Aurora の binlog を有効にする
MySQL 本来のレプリケーション情報を確認してみる
mysql> show variables like 'binlog_format';
+---------------+-----------+
| Variable_name | Value |
+---------------+-----------+
| binlog_format | STATEMENT |
+---------------+-----------+
1 row in set (0.27 sec)
mysql> show binary logs;
ERROR 1381 (HY000): You are not using binary logging
mysql> call mysql.rds_show_configuration;
+------------------------+-------+------------------------------------------------------------------------------------------------------+
| name | value | description |
+------------------------+-------+------------------------------------------------------------------------------------------------------+
| binlog retention hours | NULL | binlog retention hours specifies the duration in hours before binary logs are automatically deleted. |
+------------------------+-------+------------------------------------------------------------------------------------------------------+
1 row in set (0.22 sec)
Query OK, 0 rows affected (0.22 sec)
mysql> show master status;
Empty set (0.25 sec)
mysql> show global variables like 'server_id';
+---------------+------------+
| Variable_name | Value |
+---------------+------------+
| server_id | 1475017092 |
+---------------+------------+
1 row in set (0.19 sec)
Parameter Groups の変更
Aurora には
- DB インスタンスを制御する DB Parameter Group
- クラスターに関連する DB Cluster Parameter Group
の2種類の Parameter Group が存在します。
binlong は後者の DB Cluster Parameter Group の binlog_format
で管理します。
まず Parameter Group(DB Cluster Parameter Group) を新規作成
binlog_format
が OFF
になっているので MIXED
(や STATEMENT
) にします。
Parameter Group の変更
Aurora インスタンスの Modify から Parameter Group を先ほど作成した binlog を有効したものに変更します。
Apply Immediately をチェックすれば、すぐに反映されることを期待したのですが Configuration Details の "DB Cluster Parameter Group" を確認すると DB Cluster Parameter GroupDatabase parameter group to associate with this DB instance. aurora-binlog-enabled ( pending-reboot ) というメッセージが表示されていたため、手動でリブートをかけました。
新しい Parameter Groups を確認
reboot 後のパラメーターを確認しましょう。
binlog_format が MIXED となっており binlog が生成されているのが確認できます。
mysql> SHOW VARIABLES LIKE 'binlog_format';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| binlog_format | MIXED |
+---------------+-------+
1 row in set (0.20 sec)
mysql> show binary logs;
+----------------------------+-----------+
| Log_name | File_size |
+----------------------------+-----------+
| mysql-bin-changelog.000001 | 7712 |
+----------------------------+-----------+
1 row in set (0.13 sec)
mysql> show master status;
+----------------------------+----------+--------------+------------------+-------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+----------------------------+----------+--------------+------------------+-------------------+
| mysql-bin-changelog.000001 | 12384 | | | |
+----------------------------+----------+--------------+------------------+-------------------+
1 row in set (0.15 sec)
以下のコマンドを叩くと、binlog ファイルをローカル環境にコピー出来ます。
$ mysqlbinlog --read-from-remote-server -h HOSTNAME -u USERNAME -p mysql-bin-changelog.000001 --result-file=mysql-bin-changelog.000001
MySQL をリードレプリカ化する
最後にこの binlog をもとに MySQL インスタンスを Aurora のリードレプリカ化します。
aurora でレプリケーションユーザーを作成
aurora サーバでレプリケーションユーザー(repl_user)を作成します。 レプリカからはこのユーザーでマスターに接続します。
CREATE USER 'repl_user'@'%' IDENTIFIED BY '<PASSWORD>';
GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'%' IDENTIFIED BY '<PASSWORD>';
Aurora のデータをダンプする
DBダンプ前に binlog の位置を控えておきます。
mysql> show master status;
+----------------------------+----------+--------------+------------------+-------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+----------------------------+----------+--------------+------------------+-------------------+
| mysql-bin-changelog.000020 | 123280 | | | |
+----------------------------+----------+--------------+------------------+-------------------+
1 row in set (0.20 sec)
以下のコマンドでDBダンプします。
$ mysqldump -u USERNAME -p -h Aurora_HOSTNAME --databases DBNAME --single-transaction --order-by-primary -r backup.sql
本当は --master-data
オプションをつけてダンプ時の binlog の位置を把握したいのですが、RDS でこのプションを有効にすると
"mysqldump: Couldn't execute 'FLUSH TABLES WITH READ LOCK': Access denied for user ..." というエラーが発生するようです。(回避策をご存知のかたは教えて下さい)
MySQL にダンプデータを取り込む
以下のコマンドで MySQL にデータを取り込みます。
$ mysql -h MySQL_HOSTNAME -u USERNAME -p DBNAME < backup.sql
MySQL にデータが取り込めていることを確認します。
mysql> select * from characters;
+----+-------------------+
| id | name |
+----+-------------------+
| 1 | Max Rockatansky |
| 2 | Imperator Furiosa |
| 3 | Nux |
+----+-------------------+
3 rows in set (0.17 sec)
MySQL でスレーブ設定を行う
MySQL 側で
- マスター(Aurora)サーバ
- レプリケーション用ユーザ
- binlog の位置
の情報とともに、レプリケーション設定を行います。
mysql> CALL mysql.rds_set_external_master ('Aurora_HOSTNAME', 3306,
-> 'repl_user', '<PASSWORD>', 'mysql-bin-changelog.000020', 123280, 0);
Query OK, 0 rows affected (0.31 sec)
mysql> CALL mysql.rds_start_replication;
+-------------------------+
| Message |
+-------------------------+
| Slave running normally. |
+-------------------------+
1 row in set (1.29 sec)
Query OK, 0 rows affected (1.29 sec)
データがレプリケートされることを確認
Master にレコードを追加
Aurora(maser) 側でデータを挿入してみましょう。
mysql> insert into characters(name) values('Immortan Joe');
Slave(Replica) で追加レコードを確認
MySQL(slave/Replica) 側でデータを確認してみましょう。
mysql> select * from characters;
+----+-------------------+
| id | name |
+----+-------------------+
| 1 | Max Rockatansky |
| 2 | Imperator Furiosa |
| 3 | Nux |
| 4 | Immortan Joe |
+----+-------------------+
4 rows in set (0.18 sec)
mysql> call mysql.rds_skip_repl_error();
+---------------------------------------------------------+
| Message |
+---------------------------------------------------------+
| Slave is running normally. No errors detected to skip. |
+---------------------------------------------------------+
1 row in set (0.18 sec)
Query OK, 0 rows affected (0.18 sec)
mysql> show slave status \G
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: Aurora_HOSTNAME
Master_User: repl_user
Master_Port: 3306
Connect_Retry: 60
...
Slave_SQL_Running_State: Slave has read all relay log; waiting for the slave I/O thread to update it
Master_Retry_Count: 86400
Master_Bind:
Last_IO_Error_Timestamp:
Last_SQL_Error_Timestamp:
Master_SSL_Crl:
Master_SSL_Crlpath:
Retrieved_Gtid_Set:
Executed_Gtid_Set:
Auto_Position: 0
1 row in set (0.20 sec)
追加レコードがレプリケートされていることが確認出来ました。
まとめ
今回は Aurora に binlog を出力させて Amazon RDS にレプリケーションしてみました。
一旦 Aurora のデータを binlog に出してしまえば、この binlog インターフェースを通してAurora のいろいろな活用が思い浮かびますね。