MySQLマスター同期メカニズムと同期遅延問題の追跡

5710 ワード

今日、Mysqlでエラーが発生し続け、プライマリスレーブの同期遅延数が大きすぎたり、エラーが発生したりしました.だからこの文章はみんなに主従同期のメカニズムの原理と問題の調査の構想を分かち合います.
こしょうひょうげん
最も直感的な表現は:

mysql> show slave status\G;
    //    
    Seconds_Behind_Master: NULL
    //    
    Seconds_Behind_Master: 0
    //    
    Seconds_Behind_Master: 79

連続クエリでは、ほとんどの時間、この属性値は=0であり、偶発的にNullまたは79などの遅延値が現れる.主従同期遅延を観察するモニタリング継続アラームを引き起こす.
故障原因と解決策
複数のスペアのserver-idが一致しているため、ホストがあるスペアと長時間接続できず、正常に同期できない.server-idを変更した後、データベース・リカバリを再起動します.
マスタスレーブ同期メカニズムMySQLのプライマリ・スレーブ同期は、レプリケーション(replication)とも呼ばれ、高可用性の高性能クラスタ・ソリューションを内蔵しています.主な機能は、次のとおりです.

:同期に大きな帯域幅を必要とせず、マルチデータセンターレプリケーションデータを実現できます.

:サーバクラスタを介して、DNSポーリング、Linux LVSなどのGSLB(グローバル負荷等化)方式により、プライマリサーバの読み取り圧力を低減することができる.

:レプリケーションはバックアップの一部ですが、バックアップの代わりにはなりません.高速写真と組み合わせる必要があります.

:サーバからプライマリ・サーバに迅速に切り替え、障害のダウンタイムとリカバリ時間を短縮します.

プライマリ・スレーブの同期は、次の3つのステップに分けられます.

プライマリサーバ(master)は、データ変更をバイナリログ(binlog)に記録する.

は、サーバ(slave)からプライマリサーバのバイナリログを自分の中継ログ(relay log)にコピーする.

サーバから中継ログのログをやり直し、変更を自分のデータベースに適用し、データの一貫性を達成します.

プライマリ・スレーブ・同期は非同期リアルタイムの同期であり、リアルタイムで伝送されますが、実行上の遅延があり、プライマリ・サーバの圧力が大きい場合、遅延もそれに応じて拡大します.
上の図では、合計3つのスレッドが必要です.

プライマリサーバのログ転送スレッド:バイナリログ増分をバックアップ

に転送する責任を負う.

サーバからのI/Oスレッド:プライマリサーバのバイナリログを読み出し、中継ログ

として保存する.

サーバのSQLスレッドから、中継ログ

の実行を担当する.MySQLスレッドの表示show full processlist;コマンドを使用して、MySQLのステータスを表示できます.
ホストのステータス:
スペアのステータス:
私のクラスタアーキテクチャは1台のホスト、4台のバックアップであるため、ホストには4つの同期スレッド(すべてのbinlogデータがバックアップに送信され、binlogログの更新を待っている)、1つの表示コマンドスレッド(show full processlist)があることがわかります.スタンバイには1つの表示コマンドスレッド、1つのI/Oスレッド(ホストが同期データイベントを送信するのを待つ)、1つのSQLスレッド(すべての中継ログが読み込まれ、I/Oスレッドが更新するのを待つ).
同期ステータスの表示
プライマリスレーブ同期は非同期リアルタイムであり、つまり遅延があるため、show slave status;を使用して、スタンバイ上の同期遅延を表示できます.
プライマリ・スレーブの同期で注目すべきいくつかのプロパティは、すでに赤く表示されています.

Slave_IO_State:現在のI/Oスレッドの状態

Master_Log_File:現在同期しているプライマリサーバのバイナリファイル

Read_Master_Log_Pos:現在同期されているプライマリサーバのバイナリファイルのオフセット量、単位はバイト、例えば図中に12.9M(13630580/1024/1024)が同期されたコンテンツ

である.

Relay_Master_Log_File:現在の中継ログ同期バイナリファイル

Slave_IO_Running:サーバからのI/Oスレッドの動作状態、YESが正常な

である.

Slave_SQL_Running:サーバからのSQLスレッドの動作状態、YESが正常な

である.

Exec_Master_Log_Pos:同期完了を示すプライマリサーバのバイナリログオフセット

Seconds_Behind_Master:サーバデータからプライマリサーバより遅れている持続時間を示す

.
同様に、show master status;コマンドを使用して、プライマリ・サーバの稼働状態を表示できます.
正常に動作するマスタースレーブの同期状態:

Slave_IO_Running: YES
Slave_SQL_Running: YES
Seconds_Behind_Master: 0

問題の調査
主従同期のメカニズムを理解した後、今日発生した問題を見てみましょう.スタンバイ状態を表示することで、3つの状態におけるいくつかの重要な属性値を観察します.

mysql> show slave status\G;
#   ：
    Slave_IO_State: Reconnecting after a failed master event read
    Slave_IO_Running: No
    Slave_SQL_Running: Yes
    Seconds_Behind_Master: NULL
#   ：
    Slave_IO_State: Waiting for master to send event
    Slave_IO_Running: Yes
    Slave_SQL_Running: Yes
    Seconds_Behind_Master: 0
#   ：
    Slave_IO_State: Queueing master event to the relay log
    Slave_IO_Running: Yes
    Slave_SQL_Running: Yes
    Seconds_Behind_Master: 636

MySQLマスターがレプリケーションスレッドの状態から移行することで、3つの状態の異なる意味を見ることができます.

#    
#              ，        ，    Waiting for master to send event。
Reconnecting after a failed master event read
#    
#            ，            。         ，        。      slave_read_timeout ，     。  ，                。
Waiting for master to send event

#    
#           ，           SQL     。
Queueing master event to the relay log

ここでは,何らかの理由でサーバからプライマリサーバと絶えず切断し,再接続を試み,再接続に成功した後に再び切断したと推測できる.
ホストの動作を確認します.10.144.63.*と10.144.68.*の2台のマシンで問題が発生したことがわかりました.そのうちの1台のエラーログを確認します.

190214 11:33:20 [Note] Slave: received end packet from server, apparent master shutdown: 
190214 11:33:20 [Note] Slave I/O thread: Failed reading log event, reconnecting to retry, log 'mysql-bin.005682' at postion 13628070

キーワードSlave: received end packet from server, apparent master shutdown: Googleを手に入れて検索すると、コンフィギュレーションMySQL Replication Error Messageでは、2台のスタンバイのserver-idが重複していることがわかります.
One day it happen to me, and took me almost an hour to find that out.
Moving foward I always use a base my.cnf to I copy to any other server and the first thing is to increase the server-id.
Could MySQL just use the servername intead of a numeric value?
問題の修正
問題を特定し、重複しているかどうかを確認します.2台のスペアのこのフィールドは確かに同じです.

vim my.cnf

#replication
log-bin=mysql-bin
#            
server-id=177230069
sync_binlog=1

他の異なる数字を変更し、保存し、MySQLプロセスを再起動し、アラームを回復します.
まとめ
最終的に見ると、この問題の解決は非常に簡単だが、最初の迷いから最後の構想がはっきりしているのは、私たちが問題を調査するのによく見られることだ.この文章の主な収穫は、主従同期のメカニズムと問題を追跡する考え方を理解させることであり、次回は主従同期が私たちに与えた問題を迅速に解決することを望んでいる.
参考資料

《MySQL基礎内幕InnoDBストレージエンジン第2版》P 8.7コピー

MySQLマスターがレプリケーションスレッドの状態から移行:http://www.ywnds.com/?p=3821

Confusing MySQL Replication Error Message: https://www.percona.com/blog/...

Access denied for user ''@'localhost' to database 'mysql'