aoyama

2012.05.16

MySQLのレプリケーション遅延

どーも。青山です。

受託のシステム開発やMovableTypeの構築などしつつ、MONIPLAの開発、運用も担当しています。
MONIPLAは2008年2月からサービスを開始して、4年以上が経ちました。

この記事を書いている時点で、出展いただいている企業様が開催したイベント総数も累計で2万を超えてます。
また、そのイベントに参加して下さった会員の方々の投稿は413万を超えています。

上記のように、MONIPLAでは日々データが蓄積されていっているわけですが、当然、最初からこうなることを想定していた訳ではないので、データ蓄積による影響も当然出てきます。

そこで、最近起こったMySQLの遅延についての話になります。

■遅延発生

2台あるSlaveの内1台の遅延が、解消されない！
今までも、遅延が発生することはありましたが、原因の調査中に遅延が解消していて原因を特定できていませんでした。

■原因

・複数のTEMPORARY TABLEをJOINした結果を元に数十～数千レコードを更新　×　数百　を行うバッチ処理が原因
・1セットごとの更新処理の遅延が重なった上に、通常のSQLも処理していて、遅延が解消できない状態になっていた

ちなみに、遅延が起きなかったサーバーとの違いは物理メモリの容量の差でした。

■解消方法

・遅延しているSlaveは同期処理のみをさせて、遅延の解消に専念させた。
・数十～数千レコードを更新を一度に更新していた箇所を1レコードずつ更新するように変更。
・しかし、処理時間が試算段階で3～4倍になることが分かったので、バッチ処理の実行タイミングを検討し、開始時間を変更

といった感じで、一応運用に支障はなく対応できたのが不幸中の幸いでした。
極端な遅延が起こったことで、原因の箇所もすぐに特定できたのですが、
2台あるSlaveのスペックが同じで、2台とも遅延が発生していたらと思うとゾッとします。

■原因調査で参考にさせていただいたサイト

「MySQLにおけるレプリケーション遅延の傾向と対策」

上記のサイトを参考にさせていただきました、非常に助かりました。その中の記述で

とあったのを今回は身をもって体験することとなってしまいました。

■まとめ

MONIPLAもサービス開始当初は目標とする規模がどの程度なのか、想定が非常に難しく、
スピード重視で開発を行ってきました。
今回のような問題も、サービスの成長をある意味深く味わえたという意味では、サービスづくり（運用）の
醍醐味とも言えるかもしれません。

アライドアーキテクツではそんなサービス開発・運用の醍醐味を分かち合う仲間を募集しています！

興味をもたれた方は、こちらからどうぞ。