mysql勉強会 リプリケーション編.2013 08-09
TRANSCRIPT
MySQL 社内講習リプリケーション編
CROOZ Team Venus
目次
• リプリケーションとは • マスターとスレーブ • スレーブ遅延とは • スレーブ遅延の原因は • スレーブ遅延の確認方法は • スレーブ遅延の影響 • まとめ • 参考資料
『リプリケーションとは』
リプリケーションとは データベースを拡張する
仕組みのことです
具体的には
元になるデータベース（以下ＤＢ） をコピーして複製（リプリカ）の ＤＢを作ることでＤＢを拡張します
マスターとスレーブ
この元のＤＢを『マスター』複製されたＤＢを『スレーブ』 といいます。
使用している リプリケーション方式は
非同期型シングルマスター/マルチスレーブ方式
一般的に多く使われているリプリ
ケーションの方式で、１つのマスター
ＤＢで更新を処理し、その更新内容が
ネットワークを通じ非同期にスレーブ
ＤＢに伝播される方式です
リプリケーション構成図
スレーブ スレーブ スレーブ
マスター
更新系のSQLのみ伝播
DELETE/UPDATE/INSERT
DML(ALTER TABLE等)
■ メリット・システムの構成がシンプル■ デメリット・システムの構成上、更新はマスター１台のみとなる。つまり参照しか拡張できない。・マスター／スレーブ間で同期していない為、タイミングによってはマスター／スレーブ間でデータの不一致が発生する可能性がある
メリット/デメリット
参照と更新
スレーブ
スレーブ
スレーブ
マスター
参照(SELECT)
更新(INSERT/UPDATE/DELETE/ ALTER TABLE)
『スレーブ遅延とは』
マスターからスレーブへの伝播に遅れが生じること
『スレーブ遅延の原因は』
スレーブ遅延の原因は
• マスターDBとスレーブDB間のネットワーク上をデータ転送に時間が掛かっている場合
• スレーブＤＢで更新が完了するのに時間が掛かっている場合 多くの場合は後者
マスターからスレーブへの データ転送図
スレーブ マスター
× ×
binlog relaylog
更新クエリ(INSERT/UPDATE/DELETE/ALTER TABLE)
データの転送に遅延が発生
スレーブの更新処理に遅延が発生
更新が完了したものからbinlogに書き出し
スレーブの更新処理 遅延の原因は
• UPDATE/DELETE/INSERTなど更新系のクエリで1つのクエリの実行時間が非常に長い場合に発生する。
• インデックスが効いておらず、対象件数が多い場合によく発生する。
スレーブ更新処理遅延
ALTER TABLE
master
commit
commit
slave
SQLの実行時間がそのままスレーブ遅延の時間になる
ALTER TABLE
UPDATE
UPDATE
DELETE
DELETE
クエリを分割すれば、ほとんど遅延は発生しない
注意事項 • リプリケーションの仕組み上、スレーブへの更新がシング
ルスレッド(1つづつ順番に)処理される為、サービスで全く参照されていない(イベント期間外でサービスで使われていない)テーブルであっても、カラム追加やインデックスの追加など更新に時間が掛かる場合にはスレーブ遅延が発生する。
• スレーブ遅延は、実行時間が掛かる更新クエリが完了した後に発生する。更新に数分掛かっても終わらない場合は、途中で処理を中断することで、スレーブ遅延を回避できる。尚、途中で更新をキャンセルしても、更新処理が途中の状態になる訳ではなく、クエリ発行前の状態に戻るので、気が付いたら早めにキャンセルを行う。
スレーブ更新処理で 遅延させない為には
・1つのSQLでまとめて更新処理(update/insert/delete) しない。なるべく分割する。 ・クエリを実行する前にEXPLAINを実行し、インデックスが使われているかどうか確認する。 ・インデックスの追加/カラムの追加などで時間が掛かる処理で、どうしてもスレーブ遅延が発生する場合は、メンテナンス時に作業を行う。
スレーブ更新処理で 遅延させない為には
事例に基づいて 考えて見ましょう
前回の事例で スレーブ遅延を確認します
demo
• インデックスが効いていないUPDATE文を実行
• ALTER TABLEでインデックスを追加
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文
(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 STATUS\G;(3) 【master/slave】贈り物テーブルの特定のIDのレコードを確認するSELECT * FROM prize_history WHERE prize_history_id = 2100000\G;(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 = 2100000\G;
インデックスが 効いていないUPDATE文
mysql> ALTER TABLE prize_history ADD KEY prize_id (prize_id,ctime);
インデックスを追加 (ALTER TABLE)
(1) 【master/slave】テストデータを確認するSELECT * FROM test WHERE id=32776\G;(2) 【master】インデックスを追加するALTER TABLE prize_history ADD KEY prize_id (prize_id,ctime);(3) 【master/slave】マスターのインデックス実行完了後スレーブ遅延発生時に、確認した特定のIDのレコードを更新するUPDATE test SET c=500 WHERE id=32776\G;(4) 【master/slave】贈り物テーブルの特定のIDのレコードを確認する(スレーブ遅延発生中/スレーブ遅延発生後)SELECT * FROM test WHERE id=32776\G;
インデックスを追加 (ALTER TABLE)
『スレーブ遅延の確認方法は』
SHOW SLAVE STATUS Seconds_Behind_Master
の項目を確認する
『スレーブ遅延の影響』
何が問題なの？
マスターとスレーブの間に 差分が発生！！
具体的な事例
アイテム増殖
まとめ • 実行時間が掛かる更新系SQL(INSERT/UPDATE/
DELETE)、データベース操作DDL(ALTER TABLE)はクエリは実行しない。
• 更新系クエリはなるべく分割する。
• 大きな更新が必要な場合はメンテナンス時に行う
• 数分掛かっても更新が終わらないクエリはスレーブ遅延が発生する前に早めにキャンセルする。
『参考資料』 ・MySQLにおけるレプリケーション遅延の傾向と対策 ・MySQLレプリケーションを安全に利用するための10のテクニック