Atualizações do MySQL Replication 'Catchup' mantêm um registro mais recente

Question

Eu tenho dois clusters MySQL que têm a configuração de replicação do Master-Master entre eles.

A maioria das tabelas é baseada em log, com apenas inserções e seleções, para que elas não tenham nenhum problema com a replicação.

No entanto, tenho algumas tabelas que contêm informações atuais de 'estado' para um sistema em tempo real. As entradas nessas tabelas são atualizadas e têm um campo de carimbo de data / hora mostrando sua última atualização.

Quando a replicação é interrompida, os dois clusters podem estar gravando nas mesmas linhas.

É possível ter a replicação mantendo os registros que possuem a coluna atualizada mais recente?

Se não (e minha pesquisa mostra que isso não é possível), quais soluções eu poderia usar em vez disso?

    

Answer 1

Se você estiver procurando por esse tipo de granularidade transacional, talvez seja necessário usar a replicação baseada em linha em vez da replicação baseada em instruções.

• Replicação baseada em instrução (SBR) transmite, por meio dos logs binários de logs / relés, o SQL que precisa ser executado em um escravo.
• Replicação baseada em linha transmite a alteração real no nível da linha por meio dos logs binários de logs / relés. Esses logs geralmente crescem muito mais rápido que o SBR.
• Veja meu Dez 09, 2011 no DBA StackExchange e o comentário de Aaron Brown sobre a capacidade do MySQL de mudar de modo no presença de instruções SQL inseguras

Answer 2

A situação que você descreve é chamada de problema de cérebro dividido para um ambiente Master-Master. É quando dois Mestres não sabem da existência um do outro e trabalham sozinhos enquanto assumem que o outro Mestre está morto. Este é realmente o problema mais desafiador para esse tipo de configuração de alta disponibilidade. Para lidar com esta situação corretamente, o administrador deve configurar uma política que especifique qual Mestre deve ser o Mestre quando os dois Mestres não puderem se comunicar entre si e, em seguida, direcionar todas as conexões do BD para o Mestre. Isso é normalmente implementado por um script que monitora a comunicação e redireciona as conexões do banco de dados quando ocorre um cérebro dividido. Depois, as transações com falha precisarão ser sincronizadas novamente para o banco de dados mestre que estava inativo. Eu vi que reivindicações do Xeround o serviço de banco de dados deles / delas oferece desdobramento de mestre-mestre automático que leva cuidado com a questão do cérebro dividido.