MySQL同期状態デュアルYesの仮想イメージとseconds_behind_マスターの意味

MySQL同期状態デュアルYesの仮想イメージとseconds_behind_マスターの意味
最近特殊な原因で1台のメインライブラリがダウンタイムして1時間も処理されていないので、これはとても意味のないことですが、このことでかえって奇妙な状況を発見しました.それはメインライブラリがダウンタイムしてから、監視カメラがライブラリIO threadから中断したという警報を出しました.つまり、その1時間以内に、ライブラリからの同期状態は2 Yesです.これはどんなに奇妙な現象なのか、それは何が原因なのか.分析してみましょう.
 
周知のように、MySQLの同期は非同期で完了し、IO threadはメインライブラリdumpのbinlogからライブラリからrelay logを生成するまで受信し、SQL theadはrelay logを解析した後、ライブラリから再生して同期を完了する.この2ステップは完全に非同期であり,そのうちの1つを単独で停止しても,別の正行動作には影響しない.両方のthreadが正常に動作している場合、show slave statusは同期が正常であることを示すダブルYes状態を表示します.
この2つの状態といえばもう1つの非常に重要な状態を言わざるを得ません.それはseconds_です.behind_マスターは、一般的にはスレーブライブラリとマスターライブラリの遅延時間を表し、数値が高いほど遅延が大きいことを意味するが、SBMが0の場合、本当にスレーブライブラリがマスターライブラリに追いついたことを意味するわけではない.みんなが出会ったことがあると信じています.監視図から見ると、SBMはずっと0で、ある時点から急に高くなりました.これは、マスターライブラリ上で非常に大きなイベントが実行されているため、このイベントがマスターライブラリ上で実行されていない場合、スレーブライブラリのSBMは0と表示され、マスターライブラリの実行が完了してスレーブライブラリに転送されて実行が開始されると、SBMが非常に巨大であることが表示されます.公式の文書は以下のように解釈されています.

It is also possible that transient values for Seconds_Behind_Master may not reflect the situation accurately. When the slave SQL thread has caught up on I/O, Seconds_Behind_Master displays 0; but when the slave I/O thread is still queuing up a new event, Seconds_Behind_Master may show a large value until the SQL thread finishes executing the new event. This is especially likely when the events have old timestamps; in such cases, if you execute SHOW SLAVE STATUS several times in a relatively short period, you may see this value change back and forth repeatedly between 0 and a relatively large value.

 
検証したい学生は以下のようにテストを行い、100%再現することができます.
 

1、                
2、           。
3、      
insert into aaa select 1 from aaa where x = 1 or sleep(10);
               
4、      ，    show slave status   SBM    0。（               ）
5、           ，      SBM          。

 
 
ではこのseconds_behind_マスターの値はいったいどうやって計算されたのでしょうか.公式の解釈は以下の通りです.

Seconds_Behind_Master: The number of seconds that the slave SQL thread is behind processing the master binary log

 
つまり、SQL threadがIO thread dumpを実行してくるrelay logの時間差です.relay logにeventが記録するタイムスタンプはマスターライブラリ上のタイムスタンプであり、SQL threadのタイムスタンプはライブラリ上のものであることはよく知られています.つまり、マスターライブラリとスレーブライブラリの時間が一致している場合、このSBMは確かにマスターライブラリから遅延した時間差を表しています.しかし,マスタライブラリとスレーブライブラリの時間が一致しなければ,このSBMの意味はほとんど存在しない.私たちは以下のテストをすることができます.
 

1、        
2、          
date -s“+1 hour”
3、      sleep   
4、               
show slave status
5、    ，    SBM          3600   

             。

 
 
話は終わりだbehind_マスター、IO threadとSQL threadのダブルYes仮想の問題について続けます.
以下の実験を行いました.

1、  shutdown，     no
2、kill mysqld，     no
3、kill -9 mysqld，     Yes
4、reboot    ，     Yes

 
サーバを再起動したとき(つまり、私たちが今日越えたこのシーン)だけ、ライブラリの状態がダブルYesであることがわかります.サーバーの再起動時に、スレーブとしてメインライブラリがダウンしているのか書き込みされていないのか分からないため、ダブルYes状態を維持し、一定時間(1時間見積り)後に再試行するまで待っていたと推測されます.
このプロセスslave-net-timeout,master-connect-retry,master-retry-countを制御する3つの重要なパラメータがある.公式文書によると以下のように解釈される.

slave-net-timeout              slave     ，   3600s
master-connect-retry                   ，    60s
master-retry-count                 ，  86400 

 
この再試行メカニズムは、ライブラリからメインライブラリからより多くの夏休みが得られないことを発見した場合、slave-net-timeout時間を待って、IO threadをno状態にし、接続の再構築を試み始め、失敗するたびにmaster-connect-retry時間を待って、master-retry-count回繰り返し試行します.
 
だから、以上の原因で、私たちが今日出会った双Yes状態の仮象をもたらしました.実は、メインライブラリは長い間ダウンタイムしていました.
解決策は簡単で、slave-net-timeoutを5分や1分に変更すれば、再試行メカニズムに入る待ち時間を短縮し、問題を早期に発見することができます.
 
また、@zolkerご注意ありがとうございます、MySQL 5.5以降relicationのheartbeatメカニズムが追加され、show global status like'Slave_をライブラリから実行できます.received_heartbeats'を参照してください.
メインライブラリに書き込まれていない場合は間隔時間でジャンプし、これに基づいてhealth-checkを一定に行うことができます.
1 2 3 4 5 STOP SLAVE; CHANGE MASTER TO master_heartbeat_period= milliseconds; START SLAVE; SHOW STATUS like 'slave_heartbeat period' SHOW STATUS like 'slave_received_heartbeats'
　　　　
参照ドキュメント:
　　http://dev.mysql.com/doc/refman/5.5/en/replication-options-slave.html#sysvar_slave_net_timeout
　　http://dev.mysql.com/doc/refman/5.5/en/replication-administration-status.html
　　http://dev.mysql.com/doc/refman/5.5/en/slave-io-thread-states.html