Replicação MySQL / InnoDB: como executar recuperação de falhas?

Question

Como eu executo a recuperação de falhas em uma configuração de replicação assíncrona Master-Slave do MySQL / InnoDB?

Especificamente:

1. Se um escravo falha, como faço para sincronizá-lo com o mestre depois de trazê-lo de volta?

2. Se o mestre falhar, um escravo se tornará o mestre. Como faço o novo mestre se sincronizar com outros escravos? E quando o mestre original é trazido de volta, como faço para sincronizá-lo com o novo mestre?

Como a replicação é assíncrona, uma transação que foi confirmada para o mestre pode não conseguir sair do mestre antes que a falha aconteça. Portanto, pode haver inconsistência entre o mestre original e os escravos, um dos quais se tornará o novo mestre.

Da mesma forma, o escravo que é promovido a se tornar o novo mestre pode não ter as transações mais atualizadas entre todos os escravos. Então o novo mestre poderia estar "atrás" de um de seus escravos.

Como resolvo todas essas possíveis inconsistências?

Todas as ferramentas que ajudam nessas tarefas?

Obrigado.

    

Answer 1

Eu dou uma chance:

1. Se os slaves travarem e você voltar a colocá-lo on-line, deverá sincronizar-se com o mestre automaticamente. Você pode verificar usando o comando mysql "SHOW SLAVE STATUS \ G". Olhe especialmente para estas linhas:

Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Last_Errno: 0
Last_Error: 
Seconds_Behind_Master: 0

Se parece assim, está tudo bem. Se o Seconds_Behind_Master for > 0, a réplica está alcançando. Se o Slave_IO_Running não estiver sendo executado, você tem um problema incomum, verifique os logs de erro. Se Slave_SQL_Running não estiver em execução, tente iniciá-lo com "START SLAVE;". Se isso falhar, verifique se há um erro mencionado na linha "Last_Error".

2. Um escravo se tornando o mestre: se você não tiver uma configuração de cadeia (o que pode não ser uma boa ideia), você precisaria alterar a configuração de replicação do novo mestre e dos escravos.

Para ressincronizar o antigo mestre, apenas adicione-o como escravo e deixe a replicação terminar. Então você pode colocar o sistema offline e voltar ao antigo mestre.

As transações são um problema. Especialmente se você usar um backend agnóstico de transação como o MyISAM. Usando o InnoDB deve funcionar. AFAIK apenas a transação concluída é gravada no log binário e, portanto, nas réplicas. Isso só será aplicado se o banco de dados estiver ciente de suas transações.

Com os comandos dados anteriormente, você pode verificar o estado de todos os seus escravos e promover o escravo mais recente (dica: Log_Pos) para mestre. talvez apenas temporariamente, até que todos os escravos estejam frescos novamente e depois promovam o servidor designado.

Pessoalmente, acho que você precisaria de uma configuração especial (por exemplo, misturar escravos WAN e LAN, grandes consultas de transação) para ter escravos com estados de retransmissão diferentes após o mestre ter falhado.

    

Answer 2

Eu recomendaria evitar MMM como a peste. É um software muito arriscado e causa muito mais tempo de inatividade do que previne. Eu tenho uma vasta experiência com isso e minha empresa tentou corrigir seus problemas, mas é unfixable. Não tenho certeza se é apropriado postar um link para o meu post no blog, onde explico por que isso é verdade. O autor original do MMM concorda, a propósito, que é um desastre.

    

Answer 3

A principal ferramenta que recomendo é mmm . Ele lida com replicação circular, múltiplos escravos, failover e promoção automática para dominar (e re-indicação de slaves), tudo transparente para clientes via IPs flutuantes gerenciados, e funciona lindamente (eu tive um servidor de banco de dados primário desaparecendo na noite passada devido a uma morte switch, e meus clientes nem notaram).

Em conjunto com a mmm, eu recomendaria o xtrabackup , pois ele pode ser usado como um equipamento realmente rápido e elegante maneira de configurar novos escravos (talvez para substituir uma máquina que morreu), muito mais rápido do que o carregamento de um depósito de lixo.

Além disso, se você estiver zipando seus backups, você precisa de pigz - ele irá reduzir em 80% o seu tempo de backup!