Início / dba / Perguntas / 218401
Accepted
IGGt
Asked: 2018-09-25 01:42:56 +0800 CST

A replicação do MySQL para, mas ainda diz que está em execução

  • 772

Eu tenho um problema de replicação estranho. Para referência, estou usando o MySQL 5.5 com replicação baseada em instruções. Temos um Master com Slaves no site A/rede A, e slaves no site B/rede B.

Tudo na rede A está bem. O problema ocorre com os bancos de dados no site B/rede B que estão se conectando ao mestre no site A.

Em algumas ocasiões agora eu vi a replicação parar nos bancos de dados no site B. Se eu olhar para o SLAVE_IO_RUNNINGe SLAVE_SQL_RUNNINGem SHOW SLAVE STATUSambos dizem yes. Para todas as extensões e propósitos, tudo parece bem para mim. No entanto, meu monitoramento está relatando que o evento de pulsação que executamos está ficando para trás. É como se o escravo estivesse conectado ao mestre, mas não recebendo nenhum dado.

Os vários posvalores ( read_master_log_pos, relay_log_pos, exec_master_log_pos) são todos estáticos e não se movem. Eu também verifiquei o log de retransmissão em um, e os dados de entrada param naquele momento.

Se eu olhar para os bancos de dados mestre e escravo, não há consultas de longa duração que causem isso. Tudo parece correr conforme o esperado e, como mencionado, os escravos no site A estão bem e mantêm-se atualizados.

Os bancos de dados em questão estão todos executando consultas diferentes, portanto, não é uma consulta específica perturbando as coisas.

Não há nada nos logs de erro do MySQL.

Simulamos uma pequena falha de rede (embora de nosso monitoramento não possamos ver nenhuma interrupção de rede nesses horários) e os bancos de dados funcionam conforme o esperado. Assim que a rede é reconectada, eles retomam a replicação.

Isso é corrigido executando stop slave; start slave;em que ponto tudo continua como se nada tivesse acontecido.

Alguém mais teve um problema semelhante? ou poderia lançar alguma luz sobre o que pode estar acontecendo. Minha intuição é que há uma interrupção de rede muito breve, muito curta para o monitoramento pegar, mas por que isso perturbaria o MySQL eu não sei.

mysql replication

1 respostas

  1. Best Answer

    O que me chama a atenção é a palavra 'NETWORK'.

    A comunicação entre Mestre e Escravo é implementada como bidirecional.

    De acordo com a documentação do MySQL sobre replicação

    Tópico de despejo de log binário. O mestre cria um encadeamento para enviar o conteúdo do log binário para um escravo quando o escravo se conecta. Este encadeamento pode ser identificado na saída de SHOW PROCESSLIST no mestre como o encadeamento Binlog Dump.

    O encadeamento de dump de log binário adquire um bloqueio no log binário do mestre para ler cada evento que deve ser enviado ao escravo. Assim que o evento for lido, o bloqueio é liberado, antes mesmo do evento ser enviado ao escravo.

    Thread de E/S escravo. Quando uma instrução START SLAVE é emitida em um servidor escravo, o escravo cria uma thread de E/S, que se conecta ao mestre e solicita que ele envie as atualizações registradas em seus logs binários.

    A thread de E/S slave lê as atualizações que a thread Binlog Dump do master envia (veja item anterior) e as copia para os arquivos locais que compõem o relay log do slave.

    O estado desta thread é mostrado como Slave_IO_running na saída de SHOW SLAVE STATUS ou como Slave_running na saída de SHOW STATUS.

    Dada esta descrição do aspecto de E/S da Replicação, o que você poderia procurar ???

    FIREWALL

    A conexão entre Master e Slave requer que o firewall esteja aberto. Infelizmente, já vi ocasiões em que o firewall estava aberto no Master e um Slave se conectava normalmente. O Slave faria com que o thread de E/S aparecesse na lista de processos como se nada estivesse errado. O Mestre faria o mesmo. De repente, 60 segundos depois, a thread de E/S desaparece da lista de processos do Master, mas permanece visível no Slave.

    Dado esse cenário (que testemunhei entre dois servidores Amazon EC2 em duas AZs (zonas de disponibilidade) diferentes), a solução naquela época era verificar os grupos de segurança e abrir a porta 3306 na AZ do escravo.

    TEMPO ESGOTADO

    MySQL tem configurações para tempo limite de conexões de rede

    Dos documentos do MySQL:

    • rpl_semi_sync_master_timeout : Um valor em milissegundos que controla quanto tempo o mestre espera em uma confirmação para confirmação de um escravo antes de expirar e reverter para replicação assíncrona. O valor padrão é 10.000 (10 segundos). Essa variável está disponível apenas se o plug-in de replicação semisíncrona do lado mestre estiver instalado.
    • net_read_timeout : O número de segundos para esperar por mais dados de uma conexão antes de abortar a leitura. Quando o servidor está lendo do cliente, net_read_timeout é o valor de tempo limite que controla quando abortar. Quando o servidor está gravando no cliente, net_write_timeout é o valor de tempo limite que controla quando abortar. Veja também slave_net_timeout .
    • net_write_timeout : O número de segundos para esperar que um bloco seja gravado em uma conexão antes de abortar a gravação. Consulte também net_read_timeout .
    • slave_net_timeout : O número de segundos para esperar por mais dados do mestre antes que o escravo considere a conexão interrompida, aborte a leitura e tente se reconectar. A primeira tentativa ocorre imediatamente após o tempo limite. O intervalo entre as tentativas é controlado pela opção MASTER_CONNECT_RETRY para a instrução CHANGE MASTER TO e o número de tentativas de reconexão é limitado pela opção --master-retry-count. Antes do MySQL 5.7.7, o padrão era 3600 segundos (uma hora). No MySQL 5.7.7 e posterior, o padrão é 60 segundos (um minuto).

    PREOCUPAÇÕES

    Por que falar sobre a rede assim ??? Você pode ser vitimado na forma de desvio de dados. De volta Jun 17, 2014, respondi ao post que recebi a tarefa de replicação Mysql Master-Master? . Mencionei brevemente a rede como um herói desconhecido na deriva de dados:

    • Rede
      • Você deve certificar-se de que o tráfego de rede não está inundado, seus switches estão bem, qualquer cabeamento cruzado para contornar a rede não está com defeito, não há pacotes descartados.
      • Em termos de MySQL, o thread de E/S de replicação depende da rede. Você deve certificar-se de que o mysqld possa pulsar regularmente seu mestre. Talvez a replicação semisíncrona possa ser instalada e configurada para isso.

    SUA PERGUNTA REAL

    Você está executando STOP SLAVE;e START SLAVEnão encontra a causa raiz, mas de fato resolve o problema em questão. Quão ??? Tudo o que isso faz é desconectar os threads de E/S e SQL e, em seguida, reconectar do zero.

    Você também poderia ter feito

    STOP SLAVE IO_THREAD;
START SLAVE IO_THREAD;

    o que também funcionaria bem, especialmente se o thread SQL estiver ocupado e você não quiser interrompê-lo.

    Você precisará verificar a conexão entre o Mestre e o Escravo quanto a pacotes descartados.

    Se seu monitoramento tiver a mesma granularidade de tempo que os valores de tempo limite do MySQL, você não terá nada para alertá-lo quando isso acontecer. Você teria que pesquisar o MySQL com mais frequência. Como alternativa, você provavelmente poderia criar algum tipo de configuração SNMP para monitorar o MySQL, portanto, se as informações do SNMP não forem atualizadas em tempo hábil, você poderá detectar que o MySQL está inativo ou não responde sem nunca se conectar ao MySQL.

    Minha resposta pode não ter definido totalmente a causa raiz, mas tenho duas sugestões:

    SUGESTÃO #1

    Olhe para sua configuração max_allowed_packet . Muitas vezes no DBA StackExchange chamei carinhosamente de MySQL Packetthe Silent Killer of DB Connections . O encadeamento de E/S é tanto quanto o DB Connection como qualquer outro. Eu garantiria que max_allowed_packet estivesse sempre definido como 1073741824 (que é 1G).

    SUGESTÃO #2

    Você pode definir manualmente a pulsação do thread de E/S. Como ?

    De acordo com a documentação do MySQL 5.5 paraCHANGE MASTER TO

    MASTER_HEARTBEAT_PERIOD define o intervalo em segundos entre as pulsações de replicação. Sempre que o log binário do mestre é atualizado com um evento, o período de espera para a próxima pulsação é redefinido. intervalo é um valor decimal com intervalo de 0 a 4294967 segundos e resolução em milissegundos; o menor valor diferente de zero é 0,001. Heartbeats são enviados pelo mestre somente se não houver eventos não enviados no arquivo de log binário por um período maior que o intervalo.

    Definir o intervalo para 0 desativa completamente as pulsações. O valor padrão para intervalo é igual ao valor de slave_net_timeout dividido por 2.

    Definir @@global.slave_net_timeout para um valor menor que o intervalo de pulsação atual resulta na emissão de um aviso. O efeito de emitir RESET SLAVE no intervalo de pulsação é redefini-lo para o valor padrão.

    Com base nesses parágrafos e no valor padrão para slave_net_timeout (60 segundos), parece que o thread de E/S deve pulsar a cada 30 segundos. Você pode alterar o período de pulsação para 10 segundos assim:

    STOP SLAVE;
CHANGE MASTER TO MASTER_HEARTBEAT_PERIOD = 10;
START SLAVE;
    • 2

relate perguntas