【Sunrise2nd 復習】レプリケーション
どうも、先日人生初めてのスノーボードに行って全身筋肉痛になりながら東京に行きました。
スノーボードが終わった後には体が動かせなくなる、なんて大袈裟でしょ！
と思って舐めて掛かったら、あんなに辛いスポーツだとは思わなかったです。
一挙手一投足、全ての動作が億劫になり、痛みを伴うようになった。
さて、話を戻して前回はCentOSの導入からしっかりやろうと思ったのですが、現在VOYAGE GROUPインターンシップ「Sunrise」の後日勉強会である「Sunrise2nd」というMySQLの勉強会に参加するため、東京に来ています。
実機もない状態で記事を書くのも疑問に思ったことを手元で動かしながら確認出来ないので、せっかくですから復習ついでに今まで習ったことを今回から数回に分けて記事を書いていこうと思います。
「Sunrise2nd」で使用しているMySQLの参考書
参考書は上記の本を使用している。
あまり内容を書きすぎると色々と問題にもなるので、もっと内容を深く知りたい方は上の広告をわざわざクリックして飛ばなくてもいいので、買って読んでみることをオススメします。
現在まで4回の講義が行われているが、最初の講義には参加出来なかったので二回目から。
レプリケーション
2回目の講義はSunriseでも頻繁に出てきた技術単語、レプリケーションをどのようにオペレーションで準備し、どのような問題があるか、という点を触れていった。
MySQLレプリケーションの概要
そもそもレプリケーションって何？
ここで偉大なるWikipedia, IT用語辞典を見てみよう。
Wikipedia：
レプリケーション - Wikipedia
IT用語時点：
レプリケーションとは 〔 リプリケーション 〕 〔 複製 〕 - 意味/解説/説明/定義 ： IT用語辞典
上記の２つでもある程度分かると思うが、一台の「マスター」に対して変更を加えると、1台、もしくは複数台の「スレーブ」にその変更が反映される。
そういった動作が提供される仕組みだ。
レプリケーションの役割
主に以下の様な効果が期待されている。
- 検索の負荷分散、それに伴う更新性能の向上
- バックアップ・リカバリの手段として利用可能
「マスター」に障害が発生した場合は、「スレーブ」を「マスター」に変更することで平均復旧時間（MTTR）を短くすることが出来る
レプリケーションの基本用語
- 片方向
マスターからスレーブに対して変更は通知されるが、スレーブへの変更はマスターへ通知されない。
そのため、スレーブに対して更新を行うとマスターとスレーブ間での整合性が崩れることになる。 - 双方向（マルチマスター）
片方向に対し、スレーブへの更新もマスターに反映される。MySQLでは、1つのインスタンスがマスターとスレーブを兼用できるので、それを活かして双方向にすることが出来る。 - 非同期レプリケーション
マスターからスレーブへの情報の更新が非同期で行われる。
そのため、常にスレーブの情報が最新であるという保証はない。 - 同期レプリケーション
非同期に対して、更新が即座にスレーブへ反映され、スレーブの更新の途中はロックされるため、常に最新のデータをスレーブに対して取得する事が出来る。
レプリケーションのセットアップ
初期化パラメータファイルの設定
1. 初期化パラメータファイルの設定
[master]
/etc/my.cnfに以下の記述を追記。
server_id=1
[slave]
同様に/etc/my.cnfを
server_id = 2
relay_log= mysql-relay-bin
log-slave-updates
replicate-do-db = test
2. インスタンスの起動
[master & slave]
mysqlを再起動
service restart mysql
3. スレーブからの接続用アカウントの作成
[master]
# IPアドレスはスレーブがあるサーバのIP GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'replicator'@'XXX.XXX.XXX.XXX' IDENTIFIED BY 'replicator';
4.ポジションの確認
[master]
show master status;
以下の様な情報が表示される。
+---------------+----------+--------------+------------------+ | File | Position | Binlog_Do_DB | Binlog_Ignore_DB | +---------------+----------+--------------+------------------+ | mysql-bin.003 | 73 | test | manual,mysql | +---------------+----------+--------------+------------------+
5.レプリケーションの設定
[slave]
show master status で得られた
を設定する。
change master to master_host = 'XXX.XXX.XXX.XXX', master_user='replicator', master_password='replicator', master_port =3306, master_log_file='mysql-bin.XXXXXX', master_log_pos=YYY;
5'. エラーではないことの確認
[master]
show processlist;
2個のsystemuserが存在すること。
[slave]
show processlist;
1個のreplicatorが存在すれば大丈夫。
6. レプリケーション開始
[slave]
start slave
エラーが出なければレプリケーションの設定を再確認。
7. レプリケーションステータス確認
[slave]
show slave status\G
Slave_IO_Runnning,Slave_SQL_RunningがYesとなっていること。
ちなみに以下のように表示される。
*************************** 1. row *************************** Slave_IO_State: Waiting for master to send event Master_Host: localhost Master_User: root Master_Port: 3306 Connect_Retry: 3 Master_Log_File: gbichot-bin.005 Read_Master_Log_Pos: 79 Relay_Log_File: gbichot-relay-bin.005 Relay_Log_Pos: 548 Relay_Master_Log_File: gbichot-bin.005 Slave_IO_Running: Yes Slave_SQL_Running: Yes Replicate_Do_DB: Replicate_Ignore_DB: Last_Errno: 0 Last_Error: Skip_Counter: 0 Exec_Master_Log_Pos: 79 Relay_Log_Space: 552 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: 8
レプリケーションの動作確認
事前に空のtestデータベースが作成されている前提で話を進める。
テーブルの確認
[slave]
use test; show tables;
[master]
use test;
show tables;
|
お互いテーブルがないことを確認。
テーブルの作成
[master]
create table test(id int); select * from test;
[slave]
show tables; select * from test;
マスターとスレーブの結果が一致することを確認。
また、スレーブの中にcreate tableをしてないのにも関わらずtableが作成されていることを確認。
データの挿入
[master]
insert into test values(10); select * from test;
[slave]
select * from test;
マスターに挿入したデータがスレーブに反映されていることを確認。
