Como você sincroniza novamente o banco de dados mestre do MySQL com as alterações do banco de dados escravo se o mestre fica offline?

O MySQL Server 1 está sendo executado como Master.
O MySQL Server 2 está sendo executado como escravo.

Com os dois bancos de dados online, eles estão em "sincronização perfeita". Se o Slave ficar offline, não há problema se o Master ainda estiver online; eles voltarão a sincronizar quando o escravo estiver online novamente.

Além da configuração do servidor, redirecionei a conexão (com código JSP) para o Slave DB se o Master ficar offline (é claro que testei com /etc/init.d/mysqld stop).

Quando o mestre volta a ficar online, existe algum método automático para sincronizar o mestre com as atualizações escravas?

Uma boa maneira de obter algo dessa natureza é configurar a Replicação Mestre-Mestre ou Replicação Circular. Isso não deve ser confundido com a MultiMaster Replciation.

A configuração da Replicação Circular é muito fácil se você tiver configurado a Replicação Mestre-Escrava. Aqui está o que você precisa fazer para configurá-lo.

Neste exemplo, assumiremos que a replicação mestre-escrava está ativa, mas você experimentará um pouco de tempo de inatividade (1-2 minutos):

Etapa 1) Adicione esta linha ao /etc/my.cnf no Master.

atualizações de log-escravo

Etapa 2) Adicione estas linhas ao /etc/my.cnf no Slave:

log-bin = mysql-bin (ou tenha o que o mestre tiver para isso) log-slave-updates

AVISO: Aqui está o breve momento de inatividade !!!

Etapa 3) No Slave, serviço mysql restart

Isso ativará logs binários no escravo

Etapa 4) No Master, service mysql stop

Etapa 5) Use rsync para copiar a pasta / var / lib / mysql do Slave para o mestre.

AVISO: Aqui está o momento mais longo do tempo de inatividade !!!

Etapa 6) No Escravo, serviço mysql stop

Etapa 7) No Escravo, descubra o último log binário

Etapa 8) No Escravo, descubra o tamanho do arquivo do último log binário

Etapa 9) Use rsync para copiar a pasta / var / lib / mysql do Slave para o mestre. Esta deve ser uma cópia mais rápida.

Etapa 10) No mestre, edite a
linha 2 do master.info com o último log binário do escravo.
Linha 3 de master.info com o tamanho do último log binário do escravo.
Linha 4 de master.info com o IP do escravo.
A linha 5 é a identificação de usuário do usuário de replicação (NÃO TOQUE) A
linha 6 é a senha do usuário de replicação (NÃO TOQUE)

Etapa 11) Exclua todos os logs binários e o arquivo de índice de log binário do Master.

Etapa 12) No Escravo, serviço mysql start, aguarde 15 segundos

Etapa 13) No Master, serviço mysql start

Etapa 14) No mestre, execute STOP SLAVE; MOSTRAR ESTADO MESTRE;

Etapa 15) No Escravo, execute CHANGE MASTER TO MASTER_HOST = 'IP of Slave', MASTER_USER = 'userid of replication user from Step10', MASTER_PASSWORD = 'senha do usuário de replicação da Step10', MASTER_LOG_FILE = 'binary log from Step14', MASTER_LOG_POS = LogPos da Etapa 14.

Etapa 16) No Escravo, execute START SLAVE;

Etapa 17) No Master, execute START SLAVE;

Eu executei etapas semelhantes a esta para outra pergunta do StackExchange que respondi .

De uma chance !!!

Não com replicação assíncrona, que é o que o MySQL oferece. Você acabou de descobrir o motivo pelo qual a replicação do MySQL 'pronta para uso' (pré-5.5) não é uma solução de alta disponibilidade por si só. As coisas melhoram um pouco com o 5.5 com replicação semi-síncrona (http://dev.mysql.com/doc/refman/5.5/en/replication-semisync.html), mas com o custo do tempo de transação mais lento enquanto o mestre aguarda o ack de escravo.

Se aceitar a possibilidade de perda de dados quando o mestre for desativado não for uma opção, eu diria que uma configuração mais sofisticada do que o simples mestre / escravo está em ordem.

A replicação Master to Master foi considerada mais problema do que benefício por muitas pessoas famosas do MySQL (até o próprio MySQL AB não a recomenda mais como uma solução de alta disponibilidade). Então, acho que usar a configuração DRBD para manter o mestre ativo e o escravo passivo sincronizados usando cópias no nível de bloco é o que você realmente precisa aqui.

IMHO, Antes de tudo, em uma configuração que não seja multi-mestre (mestre / escravo), seu escravo nunca deve gravar. O escravo my.cnf deve ser configurado e o servidor iniciado com:

# Flag to not take writes from network
read-only

Em seguida, para curar o problema de um mestre fora de sincronia com um escravo gravável que realiza gravações acidentalmente, é necessário diferenciar os dados nos dois hosts. Se não houver uma colisão de chaves, promova seu antigo host escravo para dominar e recriar novamente a imagem do seu antigo mestre como um host escravo replicando a partir do novo mestre. (pode haver / provavelmente há problemas de dados aqui)

Por fim, se esse cenário de indisponibilidade / tempo de inatividade ainda for uma possibilidade , reserve um tempo para configurar os dois hosts como multimestre (caixa de registro, identificação do servidor, compensações, etc.). Isso ajudará você a mitigar interrupções e períodos de inatividade em algum grau.

Se você precisar executar o mestre / escravo , obtenha pelo menos alguns pontos de bônus por separar as conexões de leitura e gravação do usuário na ACL e nos aplicativos.