Quando um MySQL Slave se conecta ao mestre, ele solicita um fluxo do log binário, e o mestre envia autonomamente eventos binlog com a frequência que ocorrem, sem que seja necessário o reconhecimento do escravo, a menos que você esteja usando replicação semissíncrona. / p>
O escravo não origina nenhum tráfego, além de reconhecimentos de baixo nível manipulados pela pilha TCP. Uma interrupção na conectividade (em várias camadas da pilha, não limitada a um cabo desconectado) pode fazer com que a conexão seja interrompida de várias maneiras, incluindo a pilha TCP do mestre interrompendo a conexão devido a tempos limite ou uma mensagem ICMP inacessível ou um firewall com monitoração de estado entre as máquinas "esquecendo" sobre a sessão TCP e soltando silenciosamente os pacotes subseqüentes, com o escravo sentado silenciosamente e esperando o próximo pacote vir do mestre.
A solução aqui é a variável global slave_net_timeout .
The number of seconds to wait for more data from the master before the slave considers the connection broken, aborts the read, and tries to reconnect.
Isso está configurado no escravo. Quando o escravo se conecta ao mestre, antes de solicitar o fluxo do log de binlog, ele pede ao mestre para enviar eventos heartbeat, que são formatados como eventos binlog e transmitidos como se fossem o próximo evento no log binário do mestre, mas na verdade não incrementam o contadores de posição do log binário. Eles são essencialmente zero sobrecarga em operação normal, porque eles não são enviados a menos que o mestre não tenha gerado novos eventos binlog para metade da configuração de slave_net_timeout do escravo (padrão; ou outro valor que você pode configurar durante CHANGE MASTER TO ), então os eventos de heartbeat só são gerados quando o tráfego é muito leve. Então, não há nenhum dano real, tanto quanto eu posso dizer em definir este valor tão baixo quanto apenas alguns segundos.
Se o escravo ver o tempo limite expirar, ele fechará sua conexão e se reconectará ao mestre.
Na chance remota de o mestre não perceber que o escravo desapareceu, quando o escravo se reconecta, o mestre fechará a conexão original, porque um mestre do MySQL, ao aceitar uma nova conexão escrava, verifica se outro escravo com o mesmo server_id já está conectado e, em caso afirmativo, descarta a conexão original. Esta é, aliás, a razão pela qual dois escravos configurados com o mesmo server_id (uma configuração não suportada) não conseguem ficar conectados com sucesso ao mesmo mestre - assim que um deles se conecta, faz com que o outro seja bloqueado. , e um ciclo segue com cada escravo forçando a conexão do outro a ser descartada.
Configurar esta variável para um valor adequadamente baixo em my.cnf e reiniciar o escravo deve remediar este problema.