Estratégia de recuperação para replicação Master-Master

Eu implementei uma solução HA para mysql com base na replicação master-master. Existe um mecanismo na parte frontal que garante que apenas um banco de dados seja lido / gravado em um determinado momento (ou seja, usamos apenas replicação para HA).

Confirmei que a replicação funciona conforme o esperado, mas estou me perguntando sobre o cenário de falha e a recuperação. Em particular, me preocupo com o que acontece quando um mestre falha em um estado irrecuperável e precisa ser recriado do outro mestre:

• Como o outro mestre está ativo e provavelmente usado, não posso bloqueá-lo e criar despejos mysqldump(nossos bancos de dados são moderadamente grandes e mysqldumppodem levar horas após alguns meses de uso).
• Mesmo assumindo que eu tenho um despejo, é crucial que a posição do binlog, conforme mostrado por SHOW MASTER STATUS, corresponda ao despejo que está sendo feito após o bloqueio do banco de dados.

A solução simples para o primeiro problema é usar um terceiro banco de dados que funcione como um backup, do qual eu posso fazer o mysqldump. Mas como garantir que o mestre recriado possa iniciar a replicação do mestre em execução de maneira consistente?

Existem duas abordagens básicas para esse problema que eu conheço. Primeiro, se você estiver executando o InnoDB em vez do Myisam, poderá fazer o backup em uma transação (- única transação - lock-tables = FALSE), combinada com - flush-logs (não obrigatório, mas agradável) e --master-data fornecerá um backup consistente com informações de posição de replicação. Os logs de liberação redefinirão os logs antes da criação do dump, o que significa que a posição sempre será 106 e --master-data colocará o nome e a posição do arquivo de log no arquivo de dump. Obviamente, você deve executar isso no mestre para que o --master-data funcione.

A segunda maneira, que você mencionou, é usar um terceiro host para criar os backups. Nesse caso, você precisa interromper a replicação, verifique se o banco de dados é apenas leitura (embora, na verdade, todas as suas réplicas devam ser lidas somente, pois isso não afeta as gravações da replicação) e crie seu backup E registre a posição de replicação. Você não pode usar --master-data neste caso. Em vez disso, você pode fazer algo assim:

echo 'stop slave' | mysql {options)
mysqldump {your options} > DB.sql
echo 'show slave status\G' > DB.replication
echo 'start slave' | mysql {options)

Se você precisar restaurar a partir desse backup, execute a restauração e configure a replicação em que os dois parâmetros master_log_file e master_log_pos vêm do arquivo DB.replication:

master_log_file = value of Master_Log_File
master_log_pos = value of Exec_Master_Log_Pos

Nota: você pode E DEVE testar isso de outra réplica.

Nota adicional: se você tiver um conjunto de réplicas (por exemplo, se você separou as leituras das gravações de um aplicativo Web), é possível que as réplicas estejam fora de sincronia com o novo mestre; isso pode acontecer se o failover ocorrer durante um período de E / S de gravação pesada, pois as réplicas são transmitidas de forma assíncrona e não há garantia de que seu modo de espera esteja na mesma posição que as outras réplicas quando você realizar o failover. No entanto, isso ainda não aconteceu comigo ...