erro de replicação de réplica de leitura mysql rds

O que causaria isso?

Vamos aos fatos, depois teremos que entrar na especulação:

Table phppoint_koreannoona.phppos_items doesn't exist on query

Você executou uma ALTER TABLEconsulta em uma tabela que não existia. Sua tabela existia no mestre no momento em que a alteração foi executada (caso contrário, ela não teria passado pelo log binário e tentado ser executada na réplica), mas não existia na réplica. Isso faz com que a replicação seja interrompida porque não pode continuar de maneira consistente.

O que pode fazer uma tabela existir no mestre e não na réplica? Várias opções:

• A mesa nunca esteve lá. Para criar uma réplica, o RDS faz um instantâneo do mestre e o transfere. Dependendo de quando ou como isso é feito, a réplica pode não ser consistente (por exemplo, eu ficaria cético em relação a um instantâneo feito ao mesmo tempo que uma alteração de esquema em execução). Talvez fosse uma tabela apenas de memória e não foi transferida corretamente para o disco? Talvez tenha sido em um mecanismo específico que tenha problemas com a transacionalidade (MyISAM).
• A tabela estava lá, mas foi excluída de alguma forma.

• Outra coisa aconteceu que fez com que as réplicas ficassem fora de sincronia. A razão exata dependerá muito do ambiente, configuração e aplicação. Alguns exemplos incluem:

  • Uma falha da réplica em uma configuração não segura contra falhas

  • As coordenadas de replicação foram alteradas inadequadamente ou outra manutenção introduziu um erro na replicação

  • Instruções de gravação ou configuração não seguras são usadas, o que leva a inconsistências

  • A filtragem é usada, levando a inconsistências de dados

  • As consultas foram executadas no mestre com a replicação/binlog desabilitada

Como consertar isso?

A maneira mais segura de corrigir inconsistências em uma réplica é recriá-la do zero. Você pode copiar uma única tabela e sincronizá-la com relativa facilidade se ela tiver uma quantidade baixa de gravações, mas isso não impedirá que outros dados se desloquem em outras tabelas.

Como evitar que isso aconteça novamente?

A parte mais importante é fazer verificações nos locais para detectar problemas antecipadamente. Ferramentas como pt-table-checksum ou dumps e comparações simples podem permitir que você detecte diferenças mais cedo. É impossível, com as informações fornecidas, dizer exatamente o que causou isso, pois a configuração do mysql será segura ou não, dependendo da configuração específica. Alguns conselhos gerais:

• Tente usar a replicação baseada em ROW, geralmente é mais resiliente contra configurações/consultas ruins
• Verifique se há avisos de "informações não seguras para log binário" nos logs
• Verifique os logs para alterações de replicação devido a manutenção inadequada
• Certifique-se de que as réplicas sejam realmente somente leitura e não possam ser gravadas ou manipuladas fora da banda
• Use innodb em todas as suas tabelas, bem como configuração resiliente a falhas para suas réplicas