1. MySQL 社内講習
リプリケーション編
CROOZ Team Venus

2. 目次
• リプリケーションとは
• マスターとスレーブ
• スレーブ遅延とは
• スレーブ遅延の原因は
• スレーブ遅延の確認方法は
• スレーブ遅延の影響
• まとめ
• 参考資料

3. 『リプリケーションとは』

4. リプリケーションとは
データベースを拡張する
仕組みのことです

5. 具体的には
元になるデータベース（以下ＤＢ）
をコピーして複製（リプリカ）の
ＤＢを作ることでＤＢを拡張します

6. マスターとスレーブ
この元のＤＢを『マスター』
複製されたＤＢを『スレーブ』
といいます。

7. 使用している
リプリケーション方式は

8. 非同期型シングルマスター/
マルチスレーブ方式
一般的に多く使われているリプリ
ケーションの方式で、１つのマスター
ＤＢで更新を処理し、その更新内容が
ネットワークを通じ非同期にスレーブ
ＤＢに伝播される方式です

9. リプリケーション構成図
スレーブ
スレーブ
スレーブ
マスター
更新系のSQLのみ伝播
DELETE/UPDATE/INSERT
DML(ALTER TABLE等)

10. ■
メリット
・システムの構成がシンプル
■
デメリット
・システムの構成上、更新はマスター１台
のみとなる。つまり参照しか拡張できない。
・マスター／スレーブ間で同期していない
為、タイミングによってはマスター／ス
レーブ間でデータの不一致が発生する可能
性がある
メリット/デメリット

11. 参照と更新
スレーブ
スレーブ
スレーブ
マスター
参照(SELECT)
更新(INSERT/UPDATE/DELETE/
ALTER TABLE)

12. 『スレーブ遅延とは』

13. マスターからスレーブへの伝播
に遅れが生じること

14. 『スレーブ遅延の原因は』

15. スレーブ遅延の原因は
• マスターDBとスレーブDB間のネットワーク上をデータ転送に
時間が掛かっている場合
• スレーブＤＢで更新が完了するのに時間が掛かっている場合
多くの場合は後者

16. マスターからスレーブへの
データ転送図
スレーブ
マスター
×
×binlog relaylog
更新クエリ(INSERT/
UPDATE/DELETE/
ALTER TABLE)
データの転送
に遅延が発生
スレーブの更新処
理に遅延が発生
更新が完了したものか
らbinlogに書き出し

17. スレーブの更新処理
遅延の原因は
• UPDATE/DELETE/INSERTなど更新系のクエリで1
つのクエリの実行時間が非常に長い場合に発生する。
• インデックスが効いておらず、対象件数が多い場合に
よく発生する。

18. スレーブ更新処理遅延
ALTER TABLE
master
commit
commit
slave
SQLの実行時
間がそのままス
レーブ遅延の
時間になる
ALTER TABLE
UPDATE
UPDATE
DELETE
DELETE
クエリを分割
すれば、ほと
んど遅延は
発生しない

19. 注意事項
• リプリケーションの仕組み上、スレーブへの更新がシング
ルスレッド(1つづつ順番に)処理される為、サービスで全
く参照されていない(イベント期間外でサービスで使われ
ていない)テーブルであっても、カラム追加やインデック
スの追加など更新に時間が掛かる場合にはスレーブ遅延が
発生する。
• スレーブ遅延は、実行時間が掛かる更新クエリが完了した
後に発生する。更新に数分掛かっても終わらない場合は、
途中で処理を中断することで、スレーブ遅延を回避できる。
尚、途中で更新をキャンセルしても、更新処理が途中の状
態になる訳ではなく、クエリ発行前の状態に戻るので、気
が付いたら早めにキャンセルを行う。

20. スレーブ更新処理で
遅延させない為には

21. ・1つのSQLでまとめて更新処理(update/insert/
delete) しない。なるべく分割する。
・クエリを実行する前にEXPLAINを実行し、インデック
スが使われているかどうか確認する。
・インデックスの追加/カラムの追加などで時間が掛か
る処理で、どうしてもスレーブ遅延が発生する場合は、
メンテナンス時に作業を行う。
スレーブ更新処理で
遅延させない為には

22. 事例に基づいて
考えて見ましょう

23. 前回の事例で
スレーブ遅延を確認します

24. demo
• インデックスが効いていないUPDATE文を実
行
• ALTER TABLEでインデックスを追加

25. mysql>
UPDATE
prize_history
SET
del_flg
=
1
WHERE
prize_id
=
14
AND
ctime
BETWEEN
'2013-05-18
00:00:00'
AND
'2013-05-24
00:00:00';
インデックスが
効いていないUPDATE文

26. (1)
【master】インデックスが効いていないUPDATE文を実行
UPDATE
prize_history
SET
del_flg
=
1
WHERE
prize_id
=
14
AND
ctime
BETWEEN
'2013-05-18
00:00:00'
AND
'2013-05-24
00:00:00';
(2)
【slave】スレーブ遅延状況を確認(クエリ実行中/スレーブ遅延発生中/スレーブ遅延解消後)
SHOW
SLAVE
STATUSG;
(3)
【master/slave】贈り物テーブルの特定のIDのレコードを確認する
SELECT
*
FROM
prize_history
WHERE
prize_history_id
=
2100000G;
(4)
【master】インデックスが効いていないUPDATE文をもう一度実行
UPDATE
prize_history
SET
del_flg
=
1
WHERE
prize_id
=
14
AND
ctime
BETWEEN
'2013-05-18
00:00:00'
AND
'2013-05-24
00:00:00';
(5)
【master】UPDATE文(4)を実行完了後スレーブ遅延発生時に、確認した贈り物テーブルの特定の
IDのレコードに受け取りフラグを設定する
UPDATE
prize_history
SET
receive_flg=1
WHERE
prize_history_id
=
2100000;
(6)
【master/slave】贈り物テーブルの特定のIDのレコードを確認する(スレーブ遅延発生中/スレー
ブ遅延発生後)
SELECT
*
FROM
prize_history
WHERE
prize_history_id
=
2100000G;
インデックスが
効いていないUPDATE文

27. mysql>
ALTER
TABLE
prize_history
ADD
KEY
prize_id
(prize_id,ctime);
インデックスを追加
(ALTER TABLE)

28. (1)
【master/slave】テストデータを確認する
SELECT
*
FROM
test
WHERE
id=32776G;
(2)
【master】インデックスを追加する
ALTER
TABLE
prize_history
ADD
KEY
prize_id
(prize_id,ctime);
(3)
【master/slave】マスターのインデックス実行完了後スレーブ遅
延発生時に、確認した特定のIDのレコードを更新する
UPDATE
test
SET
c=500
WHERE
id=32776G;
(4)
【master/slave】贈り物テーブルの特定のIDのレコードを確認す
る(スレーブ遅延発生中/スレーブ遅延発生後)
SELECT
*
FROM
test
WHERE
id=32776G;
インデックスを追加
(ALTER TABLE)

29. 『スレーブ遅延の確認方法は』

30. SHOW SLAVE STATUS
Seconds_Behind_Master
の項目を確認する

31. 『スレーブ遅延の影響』

32. 何が問題なの？

33. マスターとスレーブの間に
差分が発生！！

34. 具体的な事例
アイテム増殖

35. まとめ
• 実行時間が掛かる更新系SQL(INSERT/UPDATE/
DELETE)、データベース操作DDL(ALTER
TABLE)はク
エリは実行しない。
• 更新系クエリはなるべく分割する。
• 大きな更新が必要な場合はメンテナンス時に行う
• 数分掛かっても更新が終わらないクエリはスレー
ブ遅延が発生する前に早めにキャンセルする。

36. 『参考資料』
・MySQLにおけるレプリケーション遅延の傾向と対策
・MySQLレプリケーションを安全に利用するための10のテクニック