2015-07-12前回、前々回とRDS内でのレプリケーションの仕組み、MySQLでのレプリケーションの仕組みををまとめましたが
それを踏まえて
リージョン間でレプリケーションしたらどうなるかをまとめてみました。
つまり更新系はマスターでないと他のスレーブに配ってくれないので、データは
マスターに行く。参照系は、各リージョンにあるRDSに繋げば、データ量が多いクエリも
マスターを見に行くより早いのは間違いない。
この方法による構築での課題点は
・参照系と更新系でデータベースの接続先が違う。
・MySQLのレプリケーションは非同期レプリケーションなので、タイミングによっては、
整合性がとれていないクエリー結果になってしまう。
上記の図の例で言いますと、海外１と海外２はタイミングによっては、結果がずれる。
東京は、マスターを参照するので、ずれはない。
因みに、リージョン内での参照系レプリケーションであればRDS側のReadReprication機能で対応できます。
具体的な手順を以下に記載します。
１．まず、マスターのＥＣ２を立ち上げます。
２．MySQLをインストールしましょう。
３．マスターのリージョンにＲＤＳインスタンスをmySQLで起動します。
•MySQL5.6.13のRDS
•Publicly AccessibleをON
•Mullti-AZオプションはOFF
•セキュリティグループではお互いの通信を許可
ポートの開放
インバウンド、アウトバウンド両方
４．ＥＣ２からＲＤＳのmySQLに接続
|
1 |
mysql -h m1.cyxgcupsoi5z.ap-southeast-1.rds.amazonaws.com -P 3306 -u root -p test_db |
５．ここでレプリケーション用のユーザーを作成しておく
|
1 |
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%' IDENTIFIED BY 'password'; |
６．テスト用のテーブルを作成する。
|
1 2 3 |
create table test_table (id int, name varchar(128), tel char(10), mail char(100)) character set utf8; insert into test_table values (1, 'tanaka', '090-111-5555','tanama@exsample.com'); insert into test_table values (2, 'sato', '090-222-6666','sato@exsample.com'); |
７．バイナリ―のログにアクセスできるようにストアドプロシージャーを実行する。
|
1 |
call mysql.rds_set_configuration('binlog retention hours', 72); |
８．内容を控えておく
|
1 2 3 4 |
show master status; +----------------------------+----------+--------------+------------------+-------------------+ | File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set | +----------------------------+----------+--------------+------------------+-------------------+ | mysql-bin-changelog.000333 | 954| | | | +----------------------------+----------+--------------+------------------+-------------------+ |
８．次に、スレーブ用のリージョンのＲＤＳのインスタンスを起動します。
同じようにポートを解放してください。
９．スレーブのデータベースに接続します。
|
1 |
mysql -h m1.cyxgcupsoi5z.ap-southeast-1.rds.amazonaws.com -P 3306 -u root -p test_db |
１０．レプリケーション用のユーザーを作成します。
|
1 |
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%' IDENTIFIED BY 'passward'; |
１１．マスターのデータベースをそのままスレーブにコピーします。
最初にマスターをダンプします。
|
1 |
$ mysqldump -h m1.cyxgcupsoi5z.ap-southeast-1.rds.amazonaws.com -u root -p --databases test_db > dumpfile |
次にスレーブ側でダンプファイルをインポートします。
|
1 |
mysql -h m1.cyxgcupsoi5z.ap-southeast-1.rds.amazonaws.com -u root -p test_db < dumpfile |
１２．スレーブ側 mySQLにて以下ストアドプロシージャ―を実行します。
先程の内容をセットします。
|
1 |
call mysql.rds_set_external_master('master.xxxxxxxxxxxx.ap-northeast-1.rds.amazonaws.com',3306,'repl','password','mysql-bin-changelog.000333',954,0); |
１３．スレーブ側でレプリケーションを開始します。
|
1 |
CALL mysql.rds_start_replication; |
１４．状況確認します。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 |
show slave status\G *************************** 1. row *************************** Slave_IO_State: Waiting for master to send event Master_Host: m1.cyxgcupsoi5z.ap-southeast-1.rds.amazonaws.com Master_User: repl Master_Port: 3306 Connect_Retry: 60 Master_Log_File: mysql-bin-changelog.000408 Read_Master_Log_Pos: 422 Relay_Log_File: relaylog.000203 Relay_Log_Pos: 595 Relay_Master_Log_File: mysql-bin-changelog.000408 Slave_IO_Running: Yes Slave_SQL_Running: Yes Replicate_Do_DB: Replicate_Ignore_DB: Replicate_Do_Table: Replicate_Ignore_Table: mysql.plugin,innodb_memcache.cache_policies,mysql .rds_sysinfo,mysql.rds_replication_status,mysql.rds_history,innodb_memcache.conf ig_options Replicate_Wild_Do_Table: Replicate_Wild_Ignore_Table: Last_Errno: 0 Last_Error: Skip_Counter: 0 Exec_Master_Log_Pos: 422 Relay_Log_Space: 818 Until_Condition: None Until_Log_File: Until_Log_Pos: 0 Master_SSL_Allowed: No Master_SSL_CA_File: Master_SSL_CA_Path: Master_SSL_Cert: Master_SSL_Cipher: Master_SSL_Key: Seconds_Behind_Master: 0 Master_SSL_Verify_Server_Cert: No Last_IO_Errno: 0 Last_IO_Error: Last_SQL_Errno: 0 Last_SQL_Error: Replicate_Ignore_Server_Ids: Master_Server_Id: 17714962 Master_UUID: 030d3d6b-26c6-11e5-8a5c-064062dd903b Master_Info_File: mysql.slave_master_info SQL_Delay: 0 SQL_Remaining_Delay: NULL Slave_SQL_Running_State: Slave has read all relay log; waiting for the sla ve 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.22 sec) |
１３．マスター側で
データを登録
|
1 |
insert into test_table values (3, ’takahashi’, '999-999-999', 'takahashi@example.com'); |
１４．スレーブ側でレコードが増えているか確認 レコードが1件増えていれば
同期確認完了。
|
1 2 3 4 5 6 |
select * from test_table ; +------+------+-------+--------------+ | id | name| tel | mail| +------+------+-------+--------------+ | 1 | tanaka| 090-111-5555| tanama@exsample.com| | 2 | sato | 090-222-6666| sato@exsample.com| | 3 | takahashi | 999-999-999| takahashi@example.com| +------+------+-------+--------------+ |
メルマガ登録をお願いします。
素敵な？情報がいつもあなたに届くようになります。（itmnewsの記事が届きます。）お役に立つかどうかわかりませんが頑張りますっ。登録してみてください。