O MySQL é um sistema de gerenciamento de banco de dados relacional de código aberto amplamente usado para gerenciar e armazenar dados estruturados. É conhecido por sua simplicidade facilidade de uso e escalabilidade o que o torna uma escolha popular para diversos aplicativos desde sites pequenos até grandes empresas.
Para a sincronização de dados em tempo real, o requisito principal é implementá-la com base em logs, o que permite a sincronização de dados quase em tempo real. Isso não impõe restrições adicionais ao design e implementação do próprio banco de dados. O objetivo da replicação síncrona ativa-ativa do MySQL synchronous replication é garantir disponibilidade contínua e tolerância a falhas. Aqui estão 4 métodos para alcançar a replicação síncrona ativa-ativa do MySQL.
Replicação master-master baseada na função nativa de replicação do banco de dados MySQL
É tipicamente adequada para implantações de pequeno a médio porte.
Nesta arquitetura, dois nós podem adotar um modo simples de duplo mestre e usar uma conexão dedicada. Em caso de falha no nó master_A, as conexões de aplicação podem ser rapidamente transferidas para o nó master_B, e vice-versa.
Para evitar cenários de cérebro dividido, onde ambos os nós gravam dados conflitantes, é importante definir valores diferentes para o auto-increment-increment e auto-increment-offset nos dois nós. Isso ocorre porque, se o nó mestre cair inesperadamente ou ficar indisponível, há a possibilidade de alguns eventos do binlog não serem replicados para o nó escravo. Nesses casos, pode haver conflitos entre o valor auto-incremento gerado no escravo e o valor original no mestre.
No entanto, se houver um mecanismo de tolerância a falhas apropriado para resolver conflitos de ID auto-incremento entre mestre e escravo, é possível evitar o uso desse método. Nas versões atualizadas 5.7+ do MySQL, o uso da replicação multithread pode reduzir significativamente a latência da replicação. Além disso, uma solução alternativa que é particularmente sensível à latência da replicação é a replicação semi-sincronizada, que oferece praticamente nenhuma atraso. No entanto, isso pode resultar em uma diminuição no desempenho de concorrência de transações, especialmente em escritas bidirecionais. É necessário uma avaliação abrangente para tomar uma decisão.
Solução baseada na replicação Galera
Galera é um mecanismo de replicação de sincronização de dados multi-mestre fornecido pela Codership. Ele permite a replicação síncrona de dados e operações de leitura e gravação entre vários nós, garantindo alta disponibilidade e consistência de dados no banco de dados. As principais soluções de alta disponibilidade baseadas em Galera são o MariaDB Galera Cluster e o Percona XtraDB Cluster (PXC).
No momento, o PXC é mais comumente usado e oferece consistência rigorosa de dados, tornando-o particularmente adequado para o comércio eletrônico. No entanto, o PXC também tem suas limitações. Em cenários com altos volumes de transações concorrentes, é recomendado usar uma rede InfiniBand para reduzir a latência da rede. Isso ocorre porque o PXC pode sofrer com amplificação de escrita e o efeito gargalo, resultando em uma perda significativa de eficiência concorrente. Assim como a replicação semi-síncrona, a replicação Galera geralmente é limitada a três nós. Além disso, as variações na rede podem causar problemas de desempenho e estabilidade.
Solução baseada na Replicação de Grupo
MGR (MySQL Group Replication) é uma solução de alta disponibilidade oficialmente introduzida pelo MySQL. Ela fornece garantias de consistência de dados fortes entre os nós em um cluster de banco de dados através do protocolo Paxos. O MGR é baseado em tecnologia de replicação nativa e é oferecido como um plug-in. Permite que todos os nós no cluster sejam graváveis, abordando as limitações de desempenho de um único cluster, resolvendo o problema de divisão cerebral induzido por partições de rede e melhorando a confiabilidade dos dados replicados.
No entanto, a realidade é um pouco dura. Atualmente, não há muitos adotantes iniciais do MGR. Além disso, ele só suporta tabelas InnoDB e exige que cada tabela tenha uma chave primária para detecção de conflitos de conjunto de gravação. O recurso GTID deve estar habilitado e o formato do log binário deve ser definido como ROW para a eleição do líder e o conjunto de gravação.
COMMIT pode potencialmente falhar, de forma semelhante aos cenários de falha no nível de isolamento de instantâneos. Atualmente, um cluster MGR (MySQL Group Replication) suporta um máximo de 9 nós. Não suporta chaves estrangeiras e recursos de pontos de salvamento, impedindo verificações globais de restrições e rollbacks parciais. O log binário não suporta verificação de checksum de eventos binlog.
Solução baseada no Canal
Para sincronização em tempo real de bancos de dados, a Alibaba possui um projeto open-source dedicado chamado Otter, que permite a replicação síncrona de bancos de dados distribuídos. A ideia central do Otter ainda se baseia na captura dos logs de dados incrementais dos bancos de dados para alcançar uma replicação quase em tempo real. O próprio Otter depende de outro projeto open-source chamado Canal, que se concentra na captura de informações de logs de sincronização incremental de bancos de dados.
Atualmente, o Otter se concentra em alcançar a replicação síncrona entre bancos de dados MySQL. Ele utiliza tecnologias semelhantes para alcançar a replicação síncrona bidirecional entre dois bancos de dados MySQL. É importante notar que bidirecional aqui significa que os dados podem ser sincronizados de A para B ou de B para A, mas pode ser unidirecional em um ponto específico no tempo.
O processo de replicação mestre-escravo pode ser dividido em três etapas:
1. O mestre registra as alterações no log binário, que são conhecidas como eventos do log binário. Esses eventos podem ser visualizados usando o comando "show binlog events".
2. O escravo copia os eventos do log binário do mestre para o seu próprio log de retransmissão.
3. O escravo reexecutará sequencialmente os eventos registrados no log de relé para aplicar as alterações do mestre aos seus próprios dados.
Quanto ao princípio do Canal, é relativamente simples:
1. Canal simula o protocolo de interação de um escravo MySQL ao se disfarçar como um escravo MySQL e enviar uma solicitação de dump para o mestre MySQL.
2. Ao receber a solicitação de dump, o mestre MySQL começa a enviar logs binários para o escravo (que é o Canal).
3. O Canal analisa então os objetos do registro binário (originalmente no formato de fluxo de bytes) para extrair as informações relevantes.
Faça backup de bancos de dados MySQL com o Vinchin Backup & Recovery
Para melhor proteger os dados, é recomendado fazer backup dos seus bancos de dados. Vinchin Backup & Recovery oferece funcionalidades poderosas para proteger seus bancos de dados em máquinas virtuais e servidores físicos. Ao se integrar bem com backups de nível de VM, é fornecida uma dupla garantia aos usuários de ambientes virtuais para seus dados e sistemas de informações críticos para o negócio.
O Vinchin Backup & Recovery suporta a proteção do Oracle DB, MySQL, SQL Server, PostgreSQL, Postgres Pro e MariaDB instalados em máquinas físicas e virtuais com recursos poderosos de backup e restauração de banco de dados. Ele também oferece estratégias de backup completo, backup diferencial, backup incremental e backup de log de transações para você definir seu próprio plano de backup conforme necessário.
O Vinchin Backup & Recovery suporta backup quente eficiente sem afetar a operação normal dos bancos de dados e é fácil criar um trabalho de backup personalizado para o banco de dados.
1 Selecione o banco de dados alvo
2 Selecione o armazenamento de backup
3 Selecione as estratégias de backup
4 Enviar o trabalho
Você pode começar a usar este poderoso sistema com uma avaliação gratuita completa de 60 dias. Basta clicar no botão para obter o pacote de instalação. Você pode clicar aqui para saber mais sobre como fazer backup do MySQL com o Vinchin Backup & Recovery.
Conclusão
A replicação ativa-ativa síncrona do MySQL é projetada para fornecer alta disponibilidade e flexibilidade. Ela permite que várias instâncias do MySQL estejam ativas simultaneamente e sincronizem dados entre si, permitindo operações de leitura e gravação bidirecionais. Isso garante a disponibilidade contínua, balanceamento de carga, consistência de dados e flexibilidade. No entanto, a configuração e gerenciamento adequados são cruciais, e a escolha das soluções e ferramentas de implementação depende dos requisitos específicos.
Para proteger eficientemente os dados do banco de dados, você pode escolher o Vinchin Backup & Recovery para fazer backup e recuperar o banco de dados. Não perca o teste gratuito.
