У меня есть подчиненное устройство MySQL, которое, когда оно отстает от мастера на 0 секунд, правильно сообщает 0 Seconds_Behind_Master. Однако, если он отстает хотя бы на 1 секунду, он сообщает 14401 Seconds_Behind_Master (что на 4 часа и 1 секунду позади).
Unix date команда выдает одинаковое время как на ведущем, так и на ведомом, и обе машины синхронизируются с ntp.
Выпуск SELECT NOW() на обеих машинах выдает одинаковое время. Кроме того, часовые пояса одинаковы на обоих:
mysql> show variables like '%time_zone%';
+------------------+--------+
| Variable_name | Value |
+------------------+--------+
| system_time_zone | CDT |
| time_zone | SYSTEM |
+------------------+--------+
2 rows in set (0.00 sec)
Для меня это не большая проблема, но из-за этого мои графики nagios выглядят странно и не позволяют мне вести разумный мониторинг на этой машине для отслеживания задержки подчиненного устройства. Кто-нибудь знает, почему раб может подумать, что он на 4 часа больше, чем есть на самом деле?
Разница во времени между ведущим и ведомым вычисляется при запуске потока ввода-вывода и предполагается, что она никогда не меняется во время выполнения. Если у вас был другой часовой пояс на одном из серверов, и он изменился без перезапуска MySQL, тогда ведомое устройство добавляет неверную разницу в отчет. Перезагрузите серверы.
Seconds_Behind_Master считается ненадежным показателем задержки Slave. mk-heartbeat - это предлагаемое решение. Проверять, выписываться этот Сообщение SF (с уважением).
Возможно, есть лучший ответ, но по моему опыту, любое время задержки> 0 - это в значительной степени просто дикая оценка, и к ней следует относиться с подозрением. У меня было время запаздывания от 11 до 15 лет. Кроме того, afaik, задержка подчиненного устройства не имеет ничего общего с информацией о часовом поясе; это функция позиции курсора в двоичном журнале.