Основное ведущее устройство сервера MySql seconds_behind_master переходы
Попробуйте его трассировкой на. Это проследит Ваш запрос с корневых серверов вниз к Вашему NS.
выройте +trace NS google.com
Во-вторых, можете Вы whois Ваш домен и проверка, на какие серверы имен он указывает? Затем можно попробовать
выройте $NS_FROM_WHOIS NS example.com
проверить.
Проблема действительно заключалась в аннулировании записей кэша запросов (таблица) на старых серверах, отличных от Percona, что приводило к остановке репликации до тех пор, пока кеш не стал недействительным (что потребовало много времени).
Как указано здесь: http://bugs.mysql.com/bug.php?id=60696
Мы решили проблему, полностью перейдя на сервер Percona MySQL v5.5, который имеет возможность полностью отключить кэш запросов. .
Есть один недостаток со значением seconds_behind_master в mysql: оно учитывает только позицию относительно одного восходящего перехода. Проще всего продемонстрировать с немного более простой топологией репликации:
server1 -> server2 -> server3
Если 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, задержка репликации снова равна нулю. Сервер 3 будет выполнен с запросом 3, задержка репликации возвращается к нулю, а затем возвращается к 10 по мере обработки следующего запроса.
Таким образом, скачкообразное поведение вызвано не использованием глобальной метки времени для задержки репликации, а просто задержка после последнего «прыжка» в цепочке репликации. Мы нашли это сильно раздражающим, и теперь используем планировщик событий MySQL для обновления таблицы таймера на каждом главном сервере каждую секунду, поэтому мы можем фактически видеть фактическую задержку от глобального мастера (в топологии без кольца) или задержку от любого однорангового узла в кольце.