Existe uma maneira simples de mesclar uma replicação do MySQL 2-way quebrada

Question

Eu tenho uma configuração de replicação bidirecional, com servidores geograficamente distintos. A replicação quebrou, mas não quero apenas escolher uma como mestre. Existe alguma maneira de restaurar a replicação de tal forma que os dois bancos de dados serão re-mesclados?

    

Answer 1

Leia meu comentário sobre a questão. Se o problema é apenas que a replicação quebrou porque uma instrução foi ruim (os servidores estão executando a mesma versão do MySQL?), Pode ser possível apenas corrigir o problema e reiniciar a replicação.

Se o problema é que os mestres executaram gravações mutuamente incompatíveis, então isso é uma correção mais complicada, e não acho que isso possa ser feito automaticamente. Você provavelmente terá que examinar os logs binários em cada servidor e reconciliar manualmente os conflitos.

No futuro, no entanto, você precisa fazer uma de duas coisas - ou ter apenas um servidor aceitando gravações a qualquer momento ou evitar chaves de auto_incremento. Eu recomendo o primeiro, porque o efeito é que você tem um servidor que pode se tornar o mestre ativo a qualquer momento. Se você realmente precisa que os clientes sempre escrevam para o mestre mais próximo, você precisará criar uma maneira de particionar as chaves para que um mestre possa criar uma linha com uma chave primária que o outro mestre esteja certo de não usar.

    

Answer 2

Antes de você ter que resolver os problemas no escravo ... então você pode reiniciar a replicação. Você também pode tentar as ferramentas do maatkit: mk-slave-restart e mk-table-checksum.

    

Answer 3

Em suma, não. Pelo menos, se você quiser manter a integridade dos dados. Dei à lg +1 para recomendar o maatkit , pois essas ferramentas podem ser úteis para comparar o conjunto de dados depois de restaurado.

Dependendo de como ele está quebrado, você provavelmente precisará ler os binlogs. Você pode usar o utilitário mysqlbinlog para isso. Você desejará encontrar a última consulta bem-sucedida executada no escravo, verificar com consultas selecionadas e comparar com os log bins do mestre para encontrar a posição. É tedioso, mas com a prática pode ser rápido.

Se você quer dizer mestre duplo por "replicação bidirecional", a situação pode variar. Uma configuração típica de dois mestres teria um ativo / passivo. Se a replicação falecer no servidor ativo, você poderá apontar para a última posição (ou definir um contador de saltos global) no log mestre passivo sem arriscar os dados no mestre ativo. Se a replicação master passiva quebrar, você precisará gastar tempo nos log binários.