Sincronização distribuída do mysql

Question

Estou executando um servidor que está conectado a um host SQL. Eu tenho um outro servidor e decidi executá-lo como um backup do SQL. Então eu tenho 3 deles. Srv A é o host SQL, srv B é o backup.

Eu sei que há replicação do mysql, mas simplesmente não é para o que eu gosto (me corrija se eu estiver errado). Eu gostaria de algo distribuído, por isso, se o srv A voltar, ele não irá sobrescrever o banco de dados construído durante o tempo de inatividade no srv B. Eu só tenho 3 servidores, portanto, configurar um cluster não é uma opção.

Eu ficaria feliz se alguém pudesse me ajudar com isso.

    

Answer 1

Usar uma configuração mestre-escravo e tirar backups do escravo é uma estratégia bastante padrão com o banco de dados MySQL. O processo de proteger os dados de sobrescrever é abordado durante a fase de recuperação do failover e do failback.

Normalmente, você usaria o servidor escravo B para fazer um backup completo ou incremental do banco de dados ( mysqldump -h serverB --all-databases --lock-tables --other-options ), de maneira consistente, sem afetar o banco de dados mestre com bloqueios durante os despejos. Isso é útil porque o escravo é uma réplica idêntica do mestre.

Primeiro o mestre A é configurado com a diretiva mysql bin-log para tornar a replicação disponível para os escravos B .. e potencialmente C, D etc.

Mas também o slave B está configurado para manter um bin-log de transações. (que normalmente estaria vazio, já que não deveria registrar atualizações de replicação, a menos que você esteja encadeando escravos)

Depois que o serverA falhou, a função de mestre é movida para serverB, e B agora começa a registrar em seu próprio arquivo bin-log. Neste ponto da operação de failover, você desativaria manualmente a replicação de A para B, ( mysql -h serverB -e 'stop slave' ) porque, como mencionou, você deseja proteger B do servidor com falha A .

O que quero dizer com "a função de mestre é movida do servidor A para o servidor B" é que você alteraria seu aplicativo para gravar operações CRUD (criar, substituir, atualizar, excluir) no endereço B do servidor. por exemplo. %código%. Em uma configuração de 2 nós, você também migraria as consultas SELECT, porque não há uma função de somente leitura em cluster distinta da função principal.

Agora é a tarefa sys-admin para trazer A de volta online como um escravo de B.

Se foi uma falha limpa, A é agora algum número de eventos por trás de B, mas o log binário em B contém um registro desses eventos. Assim, você pode reproduzir o log binário masterB no slaveA (ele contém instruções SQL básicas)

Se o servidor A foi completamente destruído, você pode optar por restaurar o mysql para A usando um backup completo tirado de B usando um dump recente ou usando uma ferramenta como o script de innobackex percona do xtrabackup package .

Agora você deve configurar a replicação na direção oposta, para permitir que o slaveA se replique a partir do masterB.

Agora A e B devem ser idênticos. Se você tiver um bom motivo, como o slaveA é uma máquina de especificação muito maior, então você pode alternar a direção de replicação para restaurar a configuração masterA-slaveB.

Outras estratégias para lidar com esse cenário (de failover e failback) incluem MMM , replicação multimestre ou percona replication manager ferramenta (que eu não tentei em produção)

    

Answer 2

I only have 3 servers, so setting up a cluster is not an option.

Se você está transmitindo dados entre eles, eles são, por definição, um cluster. E um cluster é exatamente o que você descreve como seu objetivo. No MyQL speak existe um tipo muito específico de configuração chamado de cluster do NDB - esta provavelmente não é a solução certa para você.

so if the srv A comes back, it won't overwrite the database built during the downtime on srv B

Ele só fará isso se você estiver usando colunas de autoincremento ou outros valores gerados a partir de uma sequência - e o mysql tiver funcionalidades específicas para evitar isso.

I'm running a server which is connected to an SQL host. I have an another server and I decided to run it as an SQL backup. So, I have 3 of them. Srv A is the SQL host, srv B is the backup.

Eu não sigo - você tem três servidores de banco de dados? Ou 2?

Independentemente disso, você precisa configurá-los como um par master-master com replicação assíncrona (NOT master slave). Se você quiser adicionar um terceiro nó, adicione-o somente como escravo. Isso evita que se preocupe em promover escravos no caso de uma falha - você só precisa rotear o tráfego para o outro nó (também é útil para backups e atualizações de esquema). Há muitas maneiras de conseguir isso - mas as abordagens mais sensatas são as de esgrima no cliente ou o uso de um endereço virtual.

Não vou descrever o processo aqui, porque o espaço é limitado e você precisa entender exatamente o que está fazendo. Há também muitos guias na internet - mas você pode querer comprar um bom livro (só notei que O 'Reilly tem trouxe para fora este que é ainda mais apropriado). e siga os métodos descritos lá.