Master－Slave構成でレプリケーションした時のメリット
冗長化
MasterがダウンしたときにSlaveを使用することで、ダウンタイムを少なくすることができる。
負荷分散
重たい処理（SELECT)をSlave側に処理させることで、負荷を分散できる。
＊注意：UPDATEなどの更新処理に関しては、Master側での処理は必須である。
バックアップ
DBのバックアップをSlave側で行うことができる。
取得時には不完全なデータとならないように書き込みをロックして行う必要があるが、
Slave側で行うことでMaster側はロックする必要がなく、ユーザ利用ができる。
＊ダンプの取り方を工夫することで完全なスナップショットがとれる。(別セクションにて解説）
レプリケーションの動作
１．Masterサーバで実行された更新系クエリ（Insert,Update等）はバイナリログに蓄える
２．Slave側が接続してきたら、前回の接続からの変更分をSlave側に送信する
３．Slave側はMasterから受け取ったクエリを一旦リレーログに蓄える
４．Slave側でリレーログを順次クエリを実行してDBを同期
*レプリケーション動作にはBinlogDump、I/O、SQLの3つのスレッドが連携して動作する。
設定手順（Master-Slave構成）
-
Master側の設定の確認
バイナリログの設定とサーバIDを重複しないように設定する。
[mysqld]
log-bin
server-id=11
-
アカウントの作成
Slave側からMaster側へ接続するためのレプリカの専用IDをMaster側に接続する。
REPLICATION SLAVE権限を付与すること。
mysql> GRANT REPLICATION SLAVE ON *.* TO rep@192.168.1.10 IDENTIFIED BY 'password';
-
データベースのバックアップ
Master側のデータをSlave側へコピーを行う。その際にMaster側では更新がされないようにロックをしてから行う。
参考までにコピー対象ファイル；
データベース、ibdata、バイナリログファイル
mysql> FLUSH TABLES WITH READ LOCK;(Master側でデータベースをロックする）
mysql> SHOW MASTER STATUS;（Master側でロックされた状態に確認する）
+-----------------+----------+--------------+------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+-----------------+----------+--------------+------------------+
| 3306-bin.000022 | 312 | | |
+-----------------+----------+--------------+------------------+
1 row in set (0.00 sec)
ロック状態の時に取得したFile名とPosition番号を控えておく。これらは、Slaveを立ち上げる際に使用する。
-
レプリケーションをしたいDBをバックアップする。バックアップ方法はtar等で取得する。
-
ロックを解除する
データベースをバックアップしたら書き込みロックの解除して、通常の運用にもどす。
mysql>UNLOCK TABLES;
-
取得したMaster側のデータベースのバックアップをSlave側へコピーして展開する。
-
Slave側の設定
バイナリログの設定とサーバIDを重複しないように設定する。
[mysqld]
log-bin
server-id=12
#レプリケーションを行わないデータベース名
replicate-ignore-db=mysql
relay-log=./log/slave-relay-bin.log
net_read_timeout=60
-
設定が完了したらSlave側のmysqldを起動する。
-
レプリケーションの開始の設定
mysql> CHANGE MASTER TO
MASTER_HOST='192.168.1.10', <== Masterのホスト名/IPアドレス
MASTER_USER='rep', <== Master接続に使用するユーザー名
MASTER_PASSWORD='rep', <== パスワード
MASTER_LOG_FILE='3306-bin.000022', <==3で確認したFile
MASTER_LOG_POS=312; <==3 で確認したPosition
-
レプリケーションの開始
mysql>START SLAVE;
書き込みロックを解除した以降のMaster側の変更内容がSlave側に反映される。
これ以降は、Master側での変更はSlave側にも反映されるようになる。
動作確認
-
Master側での確認
mysql>show processlist\G;
・・・・・略
*************************** 3. row ***************************
Id: 10
User: rep
Host: host
db: NULL
Command: Binlog Dump・・・・・・・・・・Binlog Dumpが起動しているかどうか
Time: 36
State: Has sent all binlog to slave; waiting for binlog to be updated
Info: NULL
3 rows in set (0.00 sec)
-
Slave側での確認
"Slave_IO_Running"と"Slave_SQL_Running"がともに"Yes"であることを確認する。
mysql>show slave status\G;
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: xxx.xxx.xxx.xxx
Master_User: rep
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: 3306-bin.000022
Read_Master_Log_Pos: 312
Relay_Log_File: xxx001-relay-bin.000001
Relay_Log_Pos: 46
Relay_Master_Log_File: 3306-bin.000022
Slave_IO_Running: Yes・・・・・・・・・・Yesであることを確認
Slave_SQL_Running: Yes・・・・・・・・・・Yesであることを確認
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 312
Relay_Log_Space: 46
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
-
ログの確認
/var/log/mysql.log
081128 14:48:32 [Note] Slave I/O thread: connected to master 'rep@xxx.xxx.xxx.xxx:3306', replication
started in log '3306-bin.000022' at position 312
081128 14:48:32 [Note] Slave SQL thread initialized, starting replication in log '3306-bin.000022'
at position 312, relay log './xxx001-relay-bin.000001' position: 4
参考コマンド
SHOW MASTER STATUS (Master用)・・・・・バイナリログの状態表示
SHOW BINLOG EVENTS (Master用)・・・・・バイナリログの中身の表示
最終更新：2009年01月14日 12:25
