レプリケーションの遅延対策としてrepli_clockテーブルを検証した

Mobageを支える技術で紹介されていたrepli_clockテーブルを遅延検出用に導入しようと思い調査してみた。

親-子のレプリケーションならseconds behind masterの値を見るだけでどれぐらいレプリケーションが遅延しているかわかるけどそこに孫スレーブが加わるとseconds behind masterの値では親からどれだけ遅延しているか検出が出来なくなる。

そのために、repli_clockテーブルを導入して親-孫のレプリケーションの遅延秒数を検知する。

以下、簡単に手順を示す。 ＊作業するサーバーはすべて親DB=マスター＊

１. repli_clockテーブルを作成し1レコードインストールする

DROP TABLE IF EXISTS repli_clock;
CREATE TABLE repli_clock (master_time INT(10) UNSIGNED NOT NULL DEFAULT 0) ENGINE=InnoDB;
INSERT INTO repli_clock (master_time) VALUES(UNIX_TIMESTAMP());

２. イベントスケジューラを使ってrepli_clockテーブルのレコードを毎秒更新するイベントを追加

CREATE EVENT camp_repli_update
        ON SCHEDULE EVERY 1 SECOND
        ON COMPLETION PRESERVE
         DO UPDATE repli_clock SET master_time=UNIX_TIMESTAMP();
SHOW EVENTS \G

最初はデーモンで毎秒更新すればいいやと思いましたが意外に処理が面倒くさいのとプロセスの監視も必要だったので MySQLのイベントスケジューラに更新処理をお任せしてます。

イベントスケジューラはMySQL5.1から導入された機能なのですがあまり使われていると聞いたことがありません。

けど、N秒ごとに処理を実行出来るなどcronよりも処理間隔の設定が柔軟なので単純な処理ならイベントスケジューラに任せるのもありです。

３. イベントスケジューラをオン

SET GLOBAL event_scheduler=ON;
SHOW VARIABLE LIKE '%event%';
SHOW STATUS LIKE '%event%';

マスターでの作業はこれで完了。

スレーブでは下のクエリでマスターと比較してどれだけ遅延しているか簡単に検知出来るようになります。

SELECT UNIX_TIMESTAMP() - master_time FROM repli_clock;

ちなみに、毎秒更新したらバイナリログいっぱい増えるんじゃないの？とか思って調べてみましたが1日で10MB程度しか増えなかったので気にしなくても問題ありません。

Mobageを支える技術 ~ソーシャルゲームの舞台裏~ (WEB+DB PRESS plus)