マスター/スレーブのセットアップは6か月以上あります。レプリケーションが問題になることはありません。マスターがダウンした場合、スレーブは「保険契約」以外の目的には使用されません。毎朝2時30分にスレーブが停止し、完全バックアップが実行された後、スレーブが再起動されます。バックアップには通常約30分かかり、スレーブは10分以内にバックアップを取り戻します。
スレーブははるかに強力なマシン（24コア対8）であり、今週末にマスターに切り替えてレプリケーションを逆にすることを検討していました。
昨日の午前9時に突然奴隷は遅れ始めました。マスターに大きな負荷はありませんでした。本当に珍しいのは、スレーブの平均負荷が約3で、待機時間が約2％（上に表示）、CPU使用率が約1/10％であるにもかかわらず、スレーブが追いついていないことです。実質的に停止しているようです。1秒のレプリケーションログの処理には約10分かかります（実際の時間から1秒遅れます）。スレーブIOスレッドはマスターのbinログに追いついており、クエリをクロールしているのはSQLスレッドだけです。それでも、クエリは処理されており、スレーブステータスを監視すると、execマスターログの位置が継続的に更新されます。
スレーブioスレッドを停止して、それが役立つかどうかを確認しましたが、影響はありません。突然、すべてのクエリが非常に高額になったようです。
基になるRAIDをディスクチェックしましたが、システムまたはmysqlログにはエラーを示すものは何もありません。mysqlを複数回再起動して再起動し、システムキャッシュをクリアしました...
これは、1週間コードが変更されておらず、このイベントの前に異常な操作上の問題がなかった実動システム上にあります。
ピーク負荷に近い場所にないシステムがマスターに追いついていないように見える理由について、私たちは完全に途方に暮れています。
他に何を調べる必要がありますか？誰かが「間違っている」ものを判断するのに役立つ場合は、ここにシステム統計などを投稿できます。