MySQL 5.6 でのレプリケーション遅延は危険 : DSAS開発者の部屋

MySQL 5.6 の検証中に MySQL 5.5 とは違うタイプのレプリケーション遅延を見つけたので紹介します。 MySQL のレプリケーションのおさらい MySQL のレプリケーションは次のような仕組みで動作しています。 マスターの更新トランザクションが binlog を書く スレーブの I/O スレッドがマスターに接続し、 binlog を取得し、 relaylog を書く. マスター側はスレーブからの接続を受け付けると(dump スレッド)、指定された場所から最新までの binlog を転送する binlog が追記されるのを待ってさらにスレーブに送る スレーブのSQLスレッドが relaylog を再生する MySQL 5.5 でよくあったレプリケーション遅延 マスターは並列してトランザクションを処理して、最終的にコミットした順で反映されれば問題ないようになっています。 一方、ス

[kasumani]

MySQL 5.6 でのレプリケーション遅延は危険 MySQL 5.6 の検証中に MySQL 5. Tags: from Pocket July 29, 2014 at 07:42PM via IFTTT

[yass]

" MySQL 5.6 をスキップして、 5.7 が GA になるまで 5.5 を使い続ける "

[tmatsuu]

なるほど.

[t-murachi]

humm...

[yassan0627]

参考になる。

[you21979]

「MySQL 5.6 をスキップして、 5.7 が GA になるまで 5.5 を使い続ける」「MySQL 5.6 へ移行する代わりに、グループコミットやレプリケーションが別方式になった MariaDB に移行する。」

[pcmaster]

“この問題は SHOW SLAVE STATUS では監視できないので、 SHOW MASTER STATUS の File, Position と SHOW SLAVE STATUS の Master_Log_File, Read_Master_Log_Pos を比較する必要があるでしょう。 ”

[hoisjp]

なんと

[stumsky]

なるほど。 MySQL 5.6 でのレプリケーション遅延は危険 : DSAS開発者の部屋

[larker]

MySQL 5.6 でグループコミットが導入の副作用

[ktakemoto]

複雑ねぇ

[mirakui]

5.6.17のLOCK_logの話

[masa_matya]

5.6のレプリケーション問題。回避したければ5.7GAを待つのも一手

[nurai]

なんやて

[dekokun]

MySQL5.6のレプリケーションにおいて、binlog自体が送られないためのスレーブ遅延が起きやすくなっておりマスターが死んだ場合のスレーブからの復旧の際に厳しい感じになったというお話。

[lesamoureuses]

“この問題は MySQL 5.7.2 で、 dump スレッドが LOCK_log を取得しなくてもどこまで転送していいか分かるようになって改善されるそうです”