Início / dba / Perguntas / 20509
Accepted
atxdba
Asked: 2012-07-07 09:01:34 +0800 CST

Replicação estragada ao compartilhar IDs de servidor

  • 772

Então eu tive minha bagunça da semana hoje. Eu estava adicionando outro par de escravos e defini o mesmo ID de servidor no novo escravo como um escravo antigo.

O layout parece

Master
|     |
\/    |
oldS  |
      \/
      newS1
      |
      |
      \/
      newS2

Portanto, para esclarecer, o antigo escravo (oldS) e o primeiro novo escravo (novoS1) compartilham o mesmo ID de servidor.

Não é uma replicação circular, então espero que tudo dê certo. Eu não teria esperado as consequências embora.

Os alarmes começaram a disparar porque o oldS1 começou a ficar cada vez mais para trás. Olhando para o logdir, ele estava fazendo milhares e milhares de logs de retransmissão vazios.

Parei de trabalhar como escravo no newS1 e isso pareceu esclarecer as coisas, pois o oldS1 parou de fazer logs de retransmissão vazios e recuperou.

Ambos os escravos parecem estar em um estado consistente até o ponto em que parei de escravizar em newS1.

  • Consertar tudo será tão simples quanto devolver newS1 com um novo e exclusivo ID ser kosher, especialmente considerando que newS1 é escravo de newS2?
  • Há algo mais para ser cauteloso?
  • Por que isso resultou em oldS gerando log de retransmissão vazio após log de retransmissão vazio? Eu teria pensado que oldS e newS1 não tinham conhecimento da existência dos outros.
  • Achei que a rolagem do registro de retransmissão fosse determinada apenas pelo próprio escravo. O mestre está enviando algum sinal de que deve gerar um novo log de retransmissão?
mysql replication

1 respostas

  1. Best Answer

    Do meu ponto de vista, você pode ter introduzido desvio de dados na replicação.

    O barão Schwartz apresentou isso como um quebra-cabeça em seu blog .

    Você pode ter que recarregar oldSe newS1com dados novos.

    No mínimo, você deve usar pt-table-checksum para ver se

    • os dados no Master diferem do oldS
    • os dados no Master diferem do newS1

    Se as diferenças não forem idênticas, você pode

    Antes de tocar em qualquer coisa, corrija a situação do ID do servidor

    A geração de logs de retransmissão é esperada porque os escravos irmãos se revezam obtendo entradas SQL do mestre. Eles simplesmente não podem compartilhar o mesmo server-id. O mestre de alguma forma alertará os escravos subsequentes que eu já dei uma instrução SQL ao id do servidor. Assim, o thread de E/S nos escravos subseqüentes será desconectado e tentará novamente. Consequentemente, os logs de retransmissão vazios aumentam. ( Confie em mim, eu dei um tiro no pé com isso anos atrás ).

    Essa metodologia do Mestre conversando com os Escravos para obter essas informações permitiu que o MySQL (eh, Oracle) apresentasse a replicação semisincronizada. Isso também interromperia a replicação semi-sincronizada. Embora o MySQL 5.6 em breve introduza um ID de transação global no mix, o server-id ainda será usado em seu método de verificações e balanços no Master. Afinal, se uma águia tivesse dois filhotes, nenhuma águia cuspiria em duas bocas ao mesmo tempo para alimentá-los.

    • 3

relate perguntas