aws-recipe-user こんにちは！中の人です。
先日AWSの新機能として『【AWS発表】 オンプレミスのMySQLデータをAmazon RDSへ移行する(その逆も) 』が発表されました。
この機能により、オンプレミス⇔AWS間でリプリケーションが出来るようになり、オンプレミス⇔AWS間のMySQLの移行が容易となりました。
実際にこの機能を使ってオンプレミス環境からRDSに対してMySQLのデータベースを移行してみます。
RDS側
RDSのデータベースインスタンスを立ちあげます。
唯一気をつける点は、MySQL 5.5 (バージョン 5.5.33 およびそれ以降)と 5.6 (バージョン 5.6.13 およびそれ以降)にする必要があるので、バージョンを間違えないように注意して起動させます。
オンプレミス側
my.cnfを編集し、通常のMySQLのリプリケーションと同じく、サーバIDの設定とバイナリログの取得の設定をします。
|
1 2 3 4 |
$ sudo vi /etc/my.cnf [mysqld] log-bin ←バイナリログを取得 server-id=1 ←サーバID（AWS側と重複しなければOK） |
※server-idはリプリケーション元・先が異なる必要がありますが、AWS側は
server_id {ServerId}
となっているため、任意のサーバIDで問題ないようです。
1. MySQLに対してリプリケーション用アカウントを作成します。
|
1 2 |
mysql> CREATE USER 'repl'@'***.ap-northeast-1.rds.amazonaws.com' IDENTIFIED BY '[repl用パスワード]'; mysql> GRANT REPLICATION SLAVE ON *.* TO 'repl'@'***.ap-northeast-1.rds.amazonaws.com'; |
◯1行目：リプリケーション用アカウントの作成
| 項目名 | 説明 |
|---|---|
| repl | リプリケーション用のユーザー名 任意の名称でOKです。 |
| ***.ap-northeast-1.rds.amazonaws.com | 新しく起動したRDSの料金となる。 |
| repl用パスワード | リプリケーション用ユーザーのパスワード |
◯2行目：1行目で作成したユーザーに対して、リプリケーションのスレーブユーザーとしての権限を付与
2. マスターサーバの情報を取得し、テーブルをロックします。
※dumpが完了するまでの間、停止が発生します。
|
1 2 |
mysql> FLUSH TABLES WITH READ LOCK; ←テーブルをロック mysql> SHOW MASTER STATUS; ←masterのステータスを取得 |
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |
| mysql-bin.000003 | 9453 |
の様に表示されるので、FileとPositionの内容を控えます。
3. データベースをdumpします。
※ 一旦mysqlからでます。
|
1 |
$ sudo mysqldump -u [DBユーザー名] –p --all-databases > to-rds.dump |
4. dumpが終了したらテーブルのロックを解除します。
|
1 |
mysql> UNLOCK TABLES; |
RDS側
※操作対象はRDSですが、RDSには直接入れないので、サーバから操作を行う。
上記サーバからであれば、dumpデータの移行が無いので楽です。
1. dumpデータのインポートをします。
|
1 |
$ sudo mysql -u [DBユーザー名] -p -h ***.ap-northeast-1.rds.amazonaws.com < to-rds.dump |
2. RDSにログインします。
|
1 2 3 4 5 6 7 8 9 10 11 |
# mysql -u [DBユーザー名] -p -h ***.ap-northeast-1.rds.amazonaws.com mysql> CALL mysql.rds_set_external_master ( mysql> 'オンプレミス側サーバホスト名' mysql> , 3306 ←オンプレミス側のMySQLのポート番号 mysql> , 'repl' ←前項目で作成したアカウント名 mysql> , '[slave用パスワード]' mysql> , 'mysql-bin.000003' ←master側のバイナリログのファイル名 mysql> , 9453 ←master側のバイナリログのポジション mysql> , 1 ←SSLを使わない場合は0 mysql> ); |
|
1 |
mysql> show slave status; |
でslave設定ができたことを確認。
3. RDS側でリプリケーションの開始
|
1 |
mysql> CALL mysql.rds_start_replication; |
4. RDS側でリプリケーションの開始
|
1 |
mysql> show slave status; |
でslave設定ができたことを確認。
| 項目名 | ステイタス |
|---|---|
| Slave_IO_State | Waiting for master to send event |
| Slave_IO_ | Running Yes |
| Slave_SQL_ | Running Yes |
オンプレミス側のMySQLに対して何らかの更新を行うと、RDS側にも反映されていることが確認できます。
RDSをマスター化する場合
リプリケーション中はManagement Console上のRDSのステイタスは以下のようになっております。
|
1 2 |
mysql> CALL mysql.rds_stop_replication; mysql> CALL mysql.rds_reset_external_master; |
で同期を終了させると、2-3分程度でmanagement consoleの「Replication State」も”-“に戻り、通常のRDSとなります。
次回はRDSからオンプレミスへの移行について紹介したいと思います。お楽しみに！
——————————————————————————————————
ナレコムクラウドのFacebookに『いいね！』をクリックして頂くと
最新のお役立ちレシピが配信されます★
┏━━━━━━━━━━━━━┓
┃ナレコムクラウド Facebook┃
┗━━━━━━━━━━━━━┛
——————————————————————————————————
