Existem algumas peculiaridades para procurar na Replicação do MySQL
1) Uso de replicate-do-db e replicate-ignore -db ao mesmo tempo
Existe um fluxograma na página para mostrar a ordem de processamento. Pessoalmente, eu não uso replicate-do-db e replicate-ignore-db ao mesmo tempo. Eu uso um ou outro. Se outros escravos não tiverem esse mesmo problema, descarte isso.
2) Fazendo o LOAD DATA INFILE
A maneira como o MySQL Replication lida com isso é chocante. Sempre que um LOAD DATA INFILE é executado em um mestre, todo o arquivo de entrada é depositado nos logs binários do mestre. O escravo reúne no arquivo de entrada em seus registros de relés. O escravo rematerializa o arquivo de dados na pasta / tmp e, em seguida, executa o LOAD DATA INFILE no escravo. Isso não é contado como atraso de replicação durante esse processo. Como um DBA MySQL, eu sei que isso funciona, mas isso é brega!
3) Falha na comunicação de thread do I / O escravo
Às vezes, devido a alterações de firewall, roteamento de rede ou alguma outra anomalia de rede, o thread de E / S escravo pode simplesmente parar de obter entradas para preencher seus logs de retransmissão. Você também pode querer verificar se o segmento de I / O escravo está visível na lista de processos do mestre. Para certificar-se de que o encadeamento IO do seu escravo esteja ativo, simplesmente faça o seguinte em todos os escravos:
SHOW SLAVE STATUS\G
Preste atenção no Relay_Log_Space. Deve estar crescendo. Se parar de crescer, o MySQL pode simplesmente congelar sem um erro por outro motivo maluco, o que leva à sugestão nº 4.
4) O escravo está sem espaço em disco
Eu escrevi um post sobre como o MySQL congela ao executar uma operação MyISAM . O MySQL usa tabelas MyISAM como tabelas temporárias. Verifique seu diretório padrão da tabela tmp (variável tmpdir no MySQL)
Espero que estas sugestões ajudem !!!