Один из моих подчиненных MySQL в один момент будет сообщать о 57 секундах позади главного, а следующий покажет 0. Я также отслеживаю с помощью mk-heartbeat, который показывает в среднем менее 1 секунды. MySQL и системные даты верны. Как именно MySQL вычисляет задержку ведомого устройства и что может быть причиной этой ошибки отчета?
Чтобы было ясно, бегу show slave status сообщит 57 секунд и работает show slave status снова (в течение 1 секунды) покажет 0. Это продолжается бесконечно, пока подчиненный поток не будет перезапущен. Обычно серверу требуется не менее 10 секунд для восстановления после задержки в одну минуту.
Это не ошибка отчета, это просто принцип работы репликации MySQL. Он передает журнал запросов, а затем выполняет запросы. Если выполнение одного из запросов занимает много времени, то все остальные запросы забиваются до тех пор, пока он не завершится. Вот почему вы видите шипы. Тот факт, что mk-heartbeat показывает низкое среднее значение, просто означает, что это не общая проблема с перегрузкой, а всего несколько больших запросов (или, что менее вероятно, случайный резкий скачок нагрузки на ведомом устройстве).
Мгновенные «секунды позади хозяина» - довольно бесполезная цифра (кроме случаев, когда вы прямо сейчас хотите знать, насколько далеко вы отстали). Статистика mk-heartbeat намного лучше для понимания того, насколько перегружена ваша репликация - что-то выше примерно 2-3 секунд в среднем за дюжину или около того пингов, и вы сбиты с толку.