序文
DBAとして、仕事はしばしばいくつかの問題のMySQLマスタースレーブ同期遅延、スローシンクロ、これらの問題に遭遇する主な問題は、ネットワーク帯域幅の問題が生じたためか、リードからのネットワークであってもよいので、実際には、その理由は、非常に多くあります大規模なトランザクションが原因である可能性が原因となる遅延は、シングルスレッドの複製によって引き起こされるので、それであってもよいです。
今日は問題、MySQLの永続的なエラーが発生し、マスター・スレーブ同期遅延が大きすぎるかエラーの数です。そこで、この記事では、同期メカニズムの主要な原則からの調査と問題点のアイデアを共有することができます。
失敗のパフォーマンス
：次のように最も直感的
|
1
2
3
4
5
6
7
|
mysql> show slave status\G;
// 状态一
Seconds_Behind_Master:
NULL
// 状态二
Seconds_Behind_Master: 0
// 状态三
Seconds_Behind_Master: 79
|
連続問合せ、属性値= 0、79時間のほとんど、または偶発がnullのレイテンシ値のように表示されます。マスタアラーム同期遅延時間監視から観察しました。
障害の原因と解決策
ホストを引き起こす複数のサーバIDと同じマシン、同じ時間の準備は、準備段階を接続することができないので、適切に同期させることができません。
サーバーIDを変更した後、データベースの回復を再起動します。
マスター・スレーブ同期メカニズム
、コピー（複製）と呼ばれるのMySQLマスタースレーブの同期は、内蔵の高可用性クラスタ・ソリューション、高性能で、主な特徴は以下のとおりです。
- データ分布：同期が大規模な帯域幅、マルチデータセンターの複製データを必要としません。
- DNSのポーリングによって、サーバークラスタを、GSLBのようなLinuxのLVS（グローバル負荷分散）モード、読み取りメインサーバの圧力を下げる：負荷分散をお読みください。
- データベースのバックアップ：コピーは、バックアップのための代替バックアップの一部ではなく。また、我々は、高速カメラと組み合わせることする必要があります。
- 高可用性およびフェイルオーバー：あなたはすぐにダウンタイムおよび障害回復時間を短縮、サーバーからマスターサーバーに切り替えることができます。
マスタースレーブ同期は3つの段階に分かれています。
- バイナリデータのプライマリサーバ（マスタ）は、ログ（バイナリログ）を変更します。
- マスター自身のバイナリログログリレー（リレーログ）へのサーバ（スレーブ）からコピーされました。
- データの一貫性を達成するために、自分でデータベースへの変更、サーバーのリレーログからログをやり直し。
マスタ - スレーブ同期、非同期リアルタイム同期、リアルタイム伝送が、実行中に遅延がある、優れたマスタ圧場合、遅延はそれに応じて拡大されます。
上記のチャートを通じて、次の3つのスレッドの合計をする必要が見ることができます：
- プライマリサーバのスレッドを出荷ログ：バックアップマシンにバイナリログを転送するためのインクリメンタル責任
- I / Oスレッドサーバから：マスタのバイナリログを読み取るための責任、およびリレーログとして保存
- リレーログの実装を担当SQL Serverのスレッドから、
MySQLのスレッドを見ます
私たちは、使用できるshow full processlist;のMySQLのステータスを表示するコマンドを：
状態をホスト：
ステートマシンの準備：
あなたは、1つのホスト、バックアップ・マシンの4セットの私のクラスタアーキテクチャを見ることができるので、4つの同時スレッドがviewコマンド・スレッドは（（のbinlogがbinlogのログ更新を待って、バックアップ・マシンにすべてのデータを送信した）、ホストであります）フルPROCESSLISTを示しています。バックアップ・マシン、I / Oスレッド（データ同期イベントを送信するホストを待つ）、SQLスレッドを（すべてのリレーログが読み込まれている、それを更新するためのI / Oスレッドを待っている）を表示するためにスレッドがあります。
同期のステータスを表示
マスタースレーブの同期は遅延が発生しますケースである非同期リアルタイムなので、私たちは奴隷の状態を表示することができ、スタンバイ・マシン上の同期遅延を表示します：
いくつかのプロパティのマスター・スレーブ同期では、我々は、我々は赤いマークする必要が集中する必要があります。
- 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：背後にあるプライマリサーバた場合、サーバからのデータよりも長い期間を表し、
同じことは、マスターのステータスを表示することができ、マスタサーバの動作状態を表示するためのコマンド：
通常の操作からプライマリ同期状態：
Slave_IO_Running：YES
Slave_SQL_Running：YES
Seconds_Behind_Master：0
トラブルシューティング
同期するための主要なメカニズムから、問題の理解では、バックアップ・マシンの状態を見て、今日遭遇見て、私たちは三つの状態のいくつかのキー属性値を守ってください。
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
|
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マスタースレーブレプリケーションのスレッド状態、私たちは三つの状態の異なる意味を見ることができます：
|
1
2
3
4
5
6
7
8
9
10
|
# 状态一
# 线程正尝试重新连接主服务器，当连接重新建立后，状态变为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で問題を発見し、*：
190214午前11時33分20秒【注意】スレーブ：サーバからエンドパケットを受信し、見かけ上のマスター・シャットダウン：
190214午前11時33分20秒【注意】スレーブI / Oスレッド：再試行する再接続、ログイベントを読み込む失敗しました、「mysqlのビンを記録postion 13628070で0.005682'
キーワードスレーブを取得：サーバーから受け取った最後のパケット、見かけ上のマスター・シャットダウン：グーグルの検索、記事のMySQLのレプリケーションエラーメッセージを混乱繰り返し2台のバックアップマシンサーバ-idの理由を見ることができます。
ある日、それは私に起こる、そしてそれを見つけるために私にはほとんど時間がかかりました。
私はいつも、私は他のサーバにコピーして、まず最初に、サーバIDを高めることであるにベースのmy.cnfを使用フォワード移動。
MySQLは、単に数値のサーバー名inteadを使用してもらえますか？
バグ修正
問題を見つけて、私たちは次の繰り返しかどうかを確認し、2は、バックアップ・マシンのフィールドが同じことをしていることが見つかりました：
|
1
2
3
4
5
6
7
|
vim my.cnf
#replication
log-bin=mysql-bin
# 这个随机数字相同导致的
server-
id
=177230069
sync_binlog=1
|
更改一个其他不同的数字，保存，重启MySQL进程，报警恢复。
总结
最终来看，这个问题的解决非常简单，但从刚开始的迷茫到最后的思路清晰，都是我们排查问题所常见的，这篇文章的主要收获是让你明白主从同步的机制和追查问题的思路，希望下次我们都能很快的解决主从同步带给我们的问题。
好了，以上就是这篇文章的全部内容了，希望本文的内容对大家的学习或者工作具有一定的参考学习价值，如果有疑问大家可以留言交流，谢谢大家对脚本之家的支持。