web-dev-qa-db-ja.com

`Seconds_Behind_Master`はマスターからの正確なスレーブラグを表示しますか?

しますSeconds_Behind_Masterスレーブがマスターの背後にある正しい秒数を常に表示しますか?

また、mk-heartbeatレプリケーションモニタリングを実装しました。

Seconds_Behind_Masterと比較して他の結果を示していました。

どちらがより正確ですか?

4
Abdul Manaf

Seconds_Behind_Masterは、UNIX_TIMESTAMP()と、マスターのバイナリログまたはスレーブのリレーログ内のクエリに対して記録されたタイムスタンプの違いに基づいています。 Seconds_Behind_Masterは、レプリケーションが長時間実行されている一連のクエリを処理する場合、実際にはリアルタイムのコンテキストで失われます。すべてのリレーログエントリが処理されてからSeconds_Behind_Masterが突然ゼロになるまで、ラグは天文学的に増大する可能性があります。リアルタイムの観点からは、ラグがゼロになるまで最終的に消散する時期を知るまたは予測する方法はありません。

Mysqlを厳密に使用すると、次の方法でレプリケーションラグをリアルタイムで監視できます。

  • SHOW SLAVE STATUS\Gから、2つの値を取得します
    • Relay_Master_Log_Fileは、スレーブで実行されたマスターで最後に正常に実行されたSQLステートメントを含むログファイルを表します。
    • Exec_Master_Log_Posは、スレーブで実行されたマスターで最後に正常に実行されたSQLステートメントのRelay_Master_Log_File内の位置を表します。

このバイナリログに対してこれを実行できます。

TMSTMP=`mysqlbinlog ---start-position=EMLP RMFL | head -50 | grep "^SET TIMESTAMP=" | head -1 | sed 's/=/ /g' | sed 's/\// /g' | awk '{print $3}'`
RIGHTNOW=`date +%s`
(( REPLAG = RIGHTNOW - TMSTMP ))

ここで、EMLPはExec_Master_Log_Pos RMFLで、Relay_Master_Log_Fileです。

これは現実的には、ログファイルと配置のみを使用してレプリケーションラグを取得する正しい方法ですが、

  • スレーブと通信して必要なログファイルと位置を取得する
  • binlogのダンプを取得するためにマスターと通信する
  • チェックするたびにbinlogをダンプします(mysqlbinlogが現在開いているログではない場合でも安全に機能します。これには、マスターログファイルをダンプする前にマスターでFLUSH LOGSを実行する必要がある場合があります)。

バイナリログからレプリケーションラグを取得するには、さらに多くの作業が必要です。

mk-heartbeat ハートビートテーブルとレコードのみをチェックします。マスターでライブテーブルを使用し、スレーブのハートビートテーブルのコピーをスレーブのUNIX_TIMESTAMP()と比較すると、はるかに簡潔なリアルタイムラグ測定になります。

Mk-heartbeatを使用する必要があります。

4
RolandoMySQLDBA