Я использую кластер Master-Master из 4 серверов MySql. (2 сервера версии 5.1 и 2 версии 5.5)
Проверяя статус ведомого, я вижу, что значение seconds_behind_master равно 0, и через полсекунды после того, как я вижу, он перескакивает на 2000, и так далее.
Что это могло быть? Как мне отладить это?
Топология репликации: 1 -> 2 -> 3 -> 4 -> 1
ОБНОВИТЬ
Кажется, что сервер 3 имеет SBM на 0, в то время как другие серверы прыгают вверх и вниз. Это помогает?
ОБНОВЛЕНИЕ 2 Похоже, проблема связана с сервером 1. При создании тестовой таблицы на сервере 4 проверка журнала реле на сервере 1 показывает, что оператор create был мгновенно скопирован в журнал реле на сервере 1, но таблица не создается. Похоже, что сервер чем-то занят, и существует огромная задержка между тем, когда сервер получает оператор, и когда он его выполняет.
ОБНОВЛЕНИЕ 3 То же самое происходит на сервере 4.
ОБНОВЛЕНИЕ 4 Хорошо, я нашел проблему. На серверах 1, 2 и 4 в потоке репликации застревали «недействительные записи кэша запросов (таблица)». После отключения кеша сервер 4 в порядке, но 1 и 2 по-прежнему имеют эту проблему.
Похоже на частую ошибку: http://bugs.mysql.com/bug.php?id=60696
Если кто знает как исправить, буду рад услышать
У значения seconds_behind_master в mysql есть один недостаток: оно учитывает только позицию относительно одного восходящего перехода. Проще всего продемонстрировать с немного более простой топологией репликации:
сервер1 -> сервер2 -> сервер3
Если server2 отстает и обрабатывает некоторые длительные запросы, произойдет следующее, если в качестве начальной точки будет приниматься 00:00:
00:00: Все в порядке
00:01: server1 записывает два 10-минутных запроса в binlog, нигде нет задержки репликации
00:02: server2 начинает обработку первого запроса. Задержка репликации для server2 начинает расти, задержка репликации для server3 остается нулевой
10:02: server2 завершает выполнение первого запроса, начинает обработку второго запроса. Задержка репликации server2 все еще растет. внезапная задержка репликации server3 прыгает до 10 минут.
20:02: server2 выполнен с запросом 2, задержка репликации снова равна нулю. Server3 будет выполнен с запросом 3, задержка репликации вернется к нулю, а затем вернется к 10 по мере обработки следующего запроса.
Таким образом, скачкообразное поведение вызвано не использованием глобальной временной метки для задержки репликации, а просто задержкой после последнего «прыжка» в цепочке репликации. Мы нашли это сильно раздражающим и теперь используем планировщик событий MySQL для обновления таблицы таймера на каждом главном сервере каждую секунду, поэтому мы можем фактически видеть фактическую задержку от глобального мастера (в топологии без кольца) или задержку от любого однорангового узла в кольце.
Проблема действительно заключалась в invalidating query cache entries (table) на старых серверах, отличных от Percona, что приводило к остановке репликации до тех пор, пока кеш не стал недействительным (что заняло много времени).
Как указано здесь: http://bugs.mysql.com/bug.php?id=60696
Мы решили проблему, полностью перейдя на сервер Percona MySQL v5.5, который может полностью отключать кэш запросов.