LoginSignup
3
1

More than 5 years have passed since last update.

別クラスタ間でのレプリケーションDB作成手順(Aurora-Aurora)

Last updated at Posted at 2017-08-16

別クラスタでAurora(MySQL)を作成し、レプリケーション可能なDBを作成する手順

なんかAWSの公式で手順が公開されてたけど簡易化したらずいぶんと単純だったからまとめる。

これができれば本番に影響を与えずに本番と常にSyncしたデータで色々テストできる。

参考文献
http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/Aurora.Overview.Replication.MySQLReplication.html

別クラスタ間でのレプリケーションDB作成手順

別クラスタでAurora(MySQL)を作成し、レプリケーション可能なDBを作成する手順

前提条件

コピー元DB(以下マスタDB)がAurora(MySQL)
作成するコピー先DB(以下スレイブDB)はAurora(MySQL)
メンテナンス時間(Aurora再起動時間)が確保できること

このメンテナンス時間はクラスタパラメータ(binlog_format)適用時に必要となる時間であり、
既に適用されている場合はダウンタイムゼロで本作業は実施可能である。

マスタDBのバイナリログ記録の有効化

下記のクラスタパラメータをMIXEDに変更

binlog_format = MIXED

メンテナンスに入っていることを確認
パラメータ変更後、マスタDBを再起動
この時点でメンテナンス解除は可能

スレイブDBの作成

スナップショット作成

-マスタDBのスナップショット作成

スレイブDB作成

-作成されたスナップショットからスレイブDBを復元
-DBパラメータ、クラスタパラメータをdefaultからマスタDBと同じパラメータに再設定
-スレイブDBを再起動
-スレイブDBのアラームと最近のイベントより下記Eventが出力されていることを確認しメモしておく。

Binlog position from crash recovery is mysql-bin-changelog.0000xx XXX

-スレイブDBのreaderを作成
-スレイブDB(reader)のインスタンスパラメータを変更
-スレイブDB(reader)の再起動

レプリケーション開始

スレイブDBにて以下を実行(マスタDBの情報登録)

CALL mysql.rds_set_external_master ('<end-point>', 3306, '<user>', '<password>', '<binaryfile-name>', <binaryfile-place>, 0);
CALL mysql.rds_start_replication;

end-point:マスタDBのクラスタエンドポイント
user:マスタDBのユーザ
binaryfile-name:前述でメモしたmysql-bin-changelog.0000xxの箇所
binaryfile-place:前述でメモしたXXXの箇所

俺が実際ハマったこと

全部終わった後にスレイブ側でslaveの状態を確認してたんだけど

mysql> show slave status \G
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event

~中略~

      Slave_SQL_Running_State: errorっぽいのは吐かれてなかった※なんで出てたかは忘れた。

なんで「あ、うまくいってんじゃん!」とか思ってたら、いつまで経ってもスレイブ側に最新のデータがレプリされない…。

んでよくよく見てたら

mysql> show slave status \G
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: ********.rds.amazonaws.com
                  Master_User: admin
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: mysql-bin-changelog.****
          Read_Master_Log_Pos: 125608761

こいつ→Read_Master_Log_Pos: 125608761
レプリ開始してから全然変わってねぇ。

SGの設定間違えてた…。
マスタ側のインバウンドにスレイブを入れるの忘れてた。

確認する時は以下を見た方が良さげ

Read_Master_Log_Pos: 125608761 ⇦更新されていること
Slave_SQL_Running_State: Slave has read all relay log; waiting for the slave I/O thread to update it ⇦このメッセージが出力されていること

まぁそこまで調べたわけじゃないけど実機でやった結果、こんな感じでした。

2017年8月23日

3
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
3
1