MySQL スレーブライブラリ Seconds_Behind_Master 遅延の概要

1. 遅延分類

レイテンシは次の 2 つのカテゴリに分類できます。

1. 最初のカテゴリ（サーバーの負荷が高い）

このタイプの遅延により、サーバーの負荷が高まり、CPU/IO 負荷が発生する可能性があります。スレーブライブラリは実際にイベントを実行するため、サーバーの負荷が高い場合は、これらの状況を考慮する必要があります。スレッドの負荷を表示する方法については、セクション 29 を参照してください。

大規模なトランザクションによって発生する遅延は 0 から始まるのではなく、メインデータベースの実行時間から直接始まります。たとえば、メインデータベースがこのトランザクションを実行するのに 20 秒かかる場合、遅延は 20 から始まり、注意深く観察すると簡単にわかります。これは、クエリイベントには正確な実行時間がないからです。これは前のセクションの計算式で詳しく説明されています。セクション8と27を参照してください。

クエリイベントは正確な実行時間を記録するため、大規模なテーブル DDL によって発生する遅延は 0 から増加します。これについては、前のセクションの計算式で詳しく説明しました。セクション8と27を参照してください。

テーブルが主キーまたは一意キーを適切に使用していないため、遅延が発生します。この場合、slave_rows_search_algorithms パラメータを INDEX_SCAN、HASH_SCAN に設定することで問題が完全に解決できると考えないでください。理由はセクション 24 で説明します。

これは、sync_relay_log、sync_master_info、sync_relay_log_info などの不合理なパラメータによって発生します。特に、sync_relay_log はスレーブライブラリのパフォーマンスに大きな影響を与えます。理由はセクション 26 で説明しましたが、sync_relay_log を 1 に設定すると、リレーログのディスクフラッシュ操作が大量に発生するためです。

スレーブデータベースでバイナリログ機能が有効になっているかどうか、つまり log_slave_updates パラメータが有効になっているかどうかを確認します。必要ない場合は、無効にすることができます。私は何度もこのような状況に遭遇しました。

2. 2番目のカテゴリ（サーバーに高い負荷をかけません）

このタイプの遅延は通常、サーバーに大きな負荷をかけることはありません。これらは、実際にはイベントを実行しないか、特別な操作によって発生します。

GTID_EVENT と XID_EVENT はコミット時間であり、その他のイベントはコマンド開始時間であるため、長期間コミットされていないトランザクションは、レイテンシの瞬間的な増加を引き起こす可能性があります。これについては、セクション 27 で例を挙げて説明しました。
Innodb 層の行ロックによる遅延は、スレーブデータベースに変更操作があり、SQL スレッドによって変更されたデータと競合がある場合に発生します。上記のセクション 23 で述べたように、SQL スレッドはイベントを実行するときにトランザクションを開始し、行ロックを取得します。以下でテストしてみましょう。
MySQL レイヤーでの MDL LOCK による遅延は、SQL スレッドが特定の DDL 操作を実行しているが、データベース上のテーブルをロックしていることが原因である可能性があります。その理由はセクション 23 で説明されています。以下でテストしてみましょう。
これは、セクション 27 でテストされている MTS の slave_checkpoint_period パラメータの不合理な設定によって発生します。
スレーブ操作中にスレーブサーバーの時間を手動で増加しましたが、これはセクション 27 でもテストされています。

2. 関連テスト

上記の遅延状況の多くについては、すでにテストして説明しているからです。次に、ロックによって発生する遅延をテストします。

1. InnoDBレイヤーでの行ロックによる遅延

これは簡単にテストできます。スレーブデータベースでトランザクションを作成し、SQL スレッドと同じデータを変更するだけです。テストは次のとおりです。

ライブラリから:
 
mysql> 開始します。
クエリは正常、影響を受けた行は 0 行 (0.00 秒)
 
mysql> tmpk から削除します。
クエリは正常、4 行が影響を受けました (0.00 秒)
同じステートメントをメイン データベースに送信しないでください: mysql> delete from tmpk;
クエリは正常、4 行が影響を受けました (0.30 秒)

この時点で、次の遅延が観察されます。

sys.innodb_lock_waits を確認すると、次の結果が表示されます。

もちろん、INNODB_TRX をチェックすれば、トランザクションの存在も確認できます。ここではスクリーンショットは撮りませんので、ご自身で試してみてください。

2. MySQL層でのMDLロックによる遅延

この状況もテストは非常に簡単です。トランザクションを開いて選択するだけで、メインデータベースが同じテーブルに対して DDL を実行し、次の結果が表示されます。

ライブラリから:
mysql> 開始します。
クエリは正常、影響を受けた行は 0 行 (0.00 秒)
 
マイSQL>
マイSQL>
mysql> tkkk 制限 1 から * を選択します。
+------+------+------+
| a | b | c |
+------+------+------+
| 3 | 3 | 100 |
+------+------+------+
セット内の 1 行 (0.00 秒)
 
コミットしないでください。テーブルの MDL LOCK は解放されません。メイン データベースは次のステートメントを実行します。
 
mysql> テーブル tmpk を変更して、testc int を追加します。
クエリは正常、影響を受けた行は 0 行 (1.14 秒)
レコード: 0 重複: 0 警告: 0

この時点で、次の情報が表示されます。

この状態から、これは MDL ロックの取得を待つことによって生じた遅延であることがわかります。MDL ロックの詳細については、次の記事を参照してください。

https://www.jb51.net/article/221412.htm

結論

シリーズ全体を通して、Seconds_Behind_Master の計算方法について明確にしておく必要があります。同時に、遅延がある場合は、まずスレーブライブラリに負荷があるかどうかを確認し、負荷があるかどうかによって異なる扱いをします。ここでの負荷は、io/sql/ワーカースレッドの負荷を表示するにはtop -Hを使用する必要があることに注意してください。レイテンシの問題について何度も尋ねてきた友人に会ったことがあります。負荷について尋ねたところ、負荷は高くなく、全体の負荷は 2 未満だと言われました。ここで注目すべきは、1 つの線程に使用できる CPU コアは 1 つだけであるということです。全体の負荷は 2 未満ですが、io/sql/worker スレッドがいっぱいになっている可能性があります。実際、負荷はすでに非常に高くなっています。次のスクリーンショットを見てみましょう。これは、負荷の高い sql スレッドのスクリーンショットです。

このスクリーンショットから、全体の負荷は 1 をわずかに上回る程度で高くないにもかかわらず、Lwp 番号 20092 のスレッドがすでに完全にロードされていることがわかります。この線程SQL スレッドであり、この時点で遅延が発生する可能性が非常に高くなります。このスクリーンショットは、主キーまたは一意キーの不適切な使用によって遅延が発生したケースのものです。ケースは次のとおりです。

https://www.jb51.net/article/221396.htm

CPU 負荷を確認するには top -H を使用し、IO 負荷を確認するには iotop、iostat などのツールを使用します。 MySQL の負荷を調べるときは、スレッドの観点から調べる必要があることを強調する必要があります。

上記は、MySQLスレーブライブラリSeconds_Behind_Master遅延サマリーの詳細です。スレーブライブラリSeconds_Behind_Master遅延サマリーの詳細については、123WORDPRESS.COMの他の関連記事に注目してください。

以下もご興味があるかもしれません: