Amazon Auroraのbinlogを有効にしAmazon MySQLにレプリケートしてみる

2015.08.27

この記事は公開されてから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_formatOFF になっているので 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 のいろいろな活用が思い浮かびますね。

参照リンク