Я предполагаю, что какой-то другой процесс выполняется на том же хосте, что и медленная ведомая база данных, и перебирает ресурсы.
Попробуйте запустить "top" (или использовать Nagios, Cactus или что-то в этом роде), чтобы отслеживать производительность системы на трех подчиненных хостах базы данных и посмотреть, наблюдаются ли какие-либо тенденции. Использование ЦП, привязанное к другому процессу, кроме mysqld, или ввод-вывод, постоянно насыщенный, такого рода вещи.
обновление: Прочитайте следующие две статьи эксперта по производительности MySQL Петра Зайцева:
Автор указывает, что ведомое устройство репликации является однопоточным, и ведомое устройство выполняет запросы последовательно, а не параллельно, как они выполнялись на ведущем устройстве. Поэтому, если у вас есть несколько реплицированных запросов, которые очень долго выполняются, они могут «удерживать очередь».
Он предлагает решить эту проблему - упростить длительные запросы SQL, чтобы они выполнялись быстрее. Например:
Если у вас есть ОБНОВЛЕНИЕ, которое влияет на миллионы строк, разбейте его на несколько ОБНОВЛЕНИЙ, которые действуют на подмножество строк.
Если у вас есть сложные операторы SELECT, включенные в ваши запросы UPDATE или INSERT, разделите SELECT на его собственный оператор, сгенерируйте набор литеральных значений в коде приложения, а затем запустите для них ваш UPDATE или INSERT. Конечно, SELECT не будет реплицирован, ведомый будет видеть только UPDATE / INSERT с буквальными значениями.
Если у вас запущено длительное пакетное задание, оно может блокировать выполнение других обновлений на ведомом устройстве. Вы можете поместить некоторые спящие в пакетное задание или даже написать пакетное задание, чтобы периодически проверять задержку репликации и при необходимости переходить в спящий режим.