Estou executando um cluster master-master de 4 servidores MySql. (2 servidores versão 5.1 e 2 versão 5.5)
Ao verificar o status do escravo, eu vejo o seconds_behind_master em 0, e meio segundo depois que eu vejo que ele salta para 2000, e assim em quarto lugar.
O que poderia ser? Como posso depurar isso?
Topologia de replicação: 1 - > 2 - > 3 - > 4 - > 1
UPDATE
Parece que o servidor 3 tem seu SBM em 0, enquanto os outros servidores estão pulando para cima e para baixo. Isso ajuda?
UPDATE 2 Parece que o problema está no servidor 1. Ao criar uma tabela de teste no servidor 4, a verificação do log de retransmissão no servidor 1 mostra que a instrução create foi copiada para o log de retransmissão no servidor 1 instantaneamente, mas a tabela não é criada. Parece que o servidor está ocupado fazendo algo e há um grande atraso entre o momento em que o servidor obtém a instrução e quando a executa.
ATUALIZAÇÃO 3 A mesma coisa acontece no servidor 4.
ATUALIZAÇÃO 4 Ok eu encontrei o problema. Servidores 1 2 & 4 estavam tendo "invalidando entradas de cache de consulta (tabela)" preso em seu segmento de replicação. Depois de desativar o cache, o servidor 4 está ok, mas o 1 e o 2 ainda estão tendo esse problema.
Parece um erro comum: link
Se alguém souber como consertar isso, eu ficaria feliz em ouvir
O problema era de fato o invalidating query cache entries (table) nos antigos servidores não-Percona que fazia com que a replicação fosse interrompida até que o cache fosse invalidado (o que levou muito tempo).
Como afirmado aqui: link
Nós resolvemos o problema movendo completamente para o Percona MySQL Server v5.5, que tem a capacidade de desabilitar completamente o Query Cache.
Há uma falha no valor seconds_behind_master do mysql: ele leva em conta apenas a posição relativa a um salto de upstream. Mais fácil de demonstrar com uma topologia de replicação um pouco mais simples:
server1 - > server2 - > server3
Se o server2 ficar para trás e estiver processando algumas consultas demoradas, ocorrerá o seguinte, assumindo 00:00 como ponto de início:
00:00: Todos ok
00:01: server1 grava duas consultas de 10 minutos no log binário, sem atraso de replicação em qualquer lugar
00:02: o server2 inicia o processamento da consulta um. Atraso de replicação para o servidor2 começa a crescer, o atraso de replicação para o servidor3 permanece zero
10:02: server2 é feito com a consulta um, inicia o processamento da consulta dois. O atraso de replicação do server2 está a aumentar. delay de replicação de server3 de repente pula para 10 minutos.
20:02: server2 é feito com consulta 2, atraso de replicação zero novamente. O Server3 será feito com a consulta 3, o atraso de replicação volta para zero e, em seguida, volta para 10 à medida que processa a próxima consulta.
Assim, o comportamento de saltos é causado por não usar um registro de data e hora global para o atraso de replicação, mas simplesmente o atraso por trás do último "salto" na cadeia de replicação. Achamos isso extremamente irritante e agora usamos o agendador de eventos do MySQL para atualizar uma tabela temporizada em cada mestre a cada segundo, para que possamos ver o atraso real do mestre global (em uma topologia sem anel) ou o atraso de qualquer ponto em um anel.