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

Question

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

Confirmei a replicação como esperado, mas estou pensando 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 consigo bloqueá-lo e criar despejos a partir de mysqldump (nossos bancos de dados são moderadamente grandes e mysqldump pode levar horas depois de alguns meses de uso).
• Mesmo supondo que eu tenha um dump, é crucial que a posição do log binário, conforme mostrado por SHOW MASTER STATUS, corresponda ao dump que está sendo feito após o banco de dados ter sido bloqueado.

A solução simples para o primeiro problema é usar um terceiro banco de dados agindo como um backup, a partir do qual eu posso fazer o mysqldump . Mas então como posso ter certeza de que o mestre recriado pode iniciar a replicação do mestre em execução de uma maneira consistente?

    

Answer 1

Existem duas abordagens básicas para esse problema que eu conheço. Primeiro, se você estiver executando o InnoDB em vez do Myisam, então você pode fazer o backup em uma transação (--single-transaction --lock-tables = FALSE), que combinado com --flush-logs (não obrigatório mas legal) e --master-data lhe dará um backup consistente com informações de posição de replicação. Os logs de limpeza redefinirão os logs antes que o dump seja criado, 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. Claro, você tem que executar isso no mestre para --master-data para trabalhar.

A segunda maneira, que você mencionou, é usar um terceiro host para criar os backups. Nesse caso, você precisa parar a replicação, certifique-se de que o banco de dados seja read_only (embora, na verdade, todas as suas réplicas devem ser lidas somente porque isso não afeta 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, em seguida, 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 pool de réplicas (por exemplo, se tiver separado as leituras de gravações de um aplicativo da 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, já que o fluxo de réplicas é assíncrono e não há garantia de que o seu modo de espera esteja na mesma posição que as outras réplicas ao realizar failover. No entanto, isso não aconteceu comigo ainda ...