Eu tenho um escravo do MySQL que quando está 0 segundo atrás do master, ele reporta corretamente 0 Seconds_Behind_Master. No entanto, se ficar ainda 1 segundo atras, ele reporta 14401 Seconds_Behind_Master (que é de 4 horas e 1 segundo para trás).
O comando unix date produz o mesmo tempo no mestre e no escravo, e ambas as máquinas são sincronizadas com ntp .
Emitir um SELECT NOW() em ambas as máquinas produz o mesmo tempo. Além disso, os fusos horários são os mesmos em ambos:
mysql> show variables like '%time_zone%';
+------------------+--------+
| Variable_name | Value |
+------------------+--------+
| system_time_zone | CDT |
| time_zone | SYSTEM |
+------------------+--------+
2 rows in set (0.00 sec)
Este não é um grande problema para mim, mas faz com que meus gráficos nagios pareçam estranhos, e me impede de ter um monitoramento sensato naquela máquina para monitorar o atraso de escravo. Alguém sabe por que o escravo pensaria que é mais 4 horas atrás do que realmente é?
A diferença de tempo entre o mestre e o escravo é calculada quando o encadeamento de E / S é iniciado e é assumido que nunca muda enquanto é executado. Se você tivesse um fuso horário diferente em um dos servidores e ele fosse alterado sem reiniciar o MySQL, o slave estaria adicionando a diferença incorreta ao relatório. Reinicie servidores.
Seconds_Behind_Master é considerado uma medida não confiável de atraso do escravo. O mk-heartbeat é a solução sugerida. Confira este post de SF (por você mesmo).
Pode haver uma resposta melhor, mas na minha experiência, qualquer tempo de atraso > 0 é praticamente uma estimativa maluca e deve ser tratada com desconfiança. Eu tive um atraso de 11 a 15 anos. Além disso, afaik, o atraso de escravo não tem nada a ver com informações de fuso horário; é uma função da posição do cursor no log binário.