Replicação multimestre - Multi-master replication

A replicação multimestre é um método de replicação de banco de dados que permite que os dados sejam armazenados por um grupo de computadores e atualizados por qualquer membro do grupo. Todos os membros respondem às consultas de dados do cliente. O sistema de replicação multimestre é responsável por propagar as modificações de dados feitas por cada membro para o resto do grupo e resolver quaisquer conflitos que possam surgir entre mudanças simultâneas feitas por diferentes membros.

A replicação multimestre pode ser contrastada com a replicação de réplica primária , na qual um único membro do grupo é designado como "mestre" para uma determinada parte dos dados e é o único nó com permissão para modificar esse item de dados. Outros membros que desejam modificar o item de dados devem primeiro contatar o nó mestre. Permitir apenas um único mestre torna mais fácil obter consistência entre os membros do grupo, mas é menos flexível do que a replicação multimestre.

A replicação multimestre também pode ser comparada ao cluster de failover, em que servidores de réplica passivos estão replicando os dados principais para se preparar para o controle caso o mestre pare de funcionar. O mestre é o único servidor ativo para interação com o cliente.

Freqüentemente, a comunicação e a replicação em sistemas multimestre são tratadas por meio de um tipo de algoritmo de consenso , mas também podem ser implementadas por meio de algoritmos personalizados ou proprietários específicos para o software.

Os objetivos principais da replicação multimestre são maior disponibilidade e tempo de resposta mais rápido do servidor.

Vantagens

  • Acessibilidade : Se um mestre falhar, outros mestres continuam a atualizar o banco de dados .
  • Acesso distribuído: os mestres podem estar localizados em vários sites físicos, ou seja, distribuídos pela rede.

Desvantagens

  • Consistência : a maioria dos sistemas de replicação multimestre são apenas vagamente consistentes, ou seja, preguiçosos e assíncronos, violando as propriedades ACID .
  • Desempenho : os sistemas de replicação mais ágeis são complexos e aumentam a latência de comunicação .
  • Integridade : problemas como resolução de conflitos podem se tornar intratáveis ​​à medida que o número de nós envolvidos aumenta e a latência aumenta.

Implementações

Serviços de diretório

Muitos servidores de diretório são baseados no protocolo LDAP ( Lightweight Directory Access Protocol ) e implementam replicação multimestre.

Active Directory

Uma das implementações de replicação multimestre mais prevalentes em servidores de diretório é o Active Directory da Microsoft . No Active Directory, os objetos atualizados em um controlador de domínio são replicados para outros controladores de domínio por meio da replicação multimestre. Não é necessário que todos os controladores de domínio se repliquem uns com os outros, pois isso poderia causar tráfego de rede excessivo em grandes implantações do Active Directory. Em vez disso, os controladores de domínio têm um padrão de atualização complexo que garante que todos os servidores sejam atualizados em tempo hábil, sem tráfego de replicação excessivo. No entanto, algumas necessidades do Active Directory são mais bem atendidas pela operação flexível de mestre único .

CA Directory

O CA Directory oferece suporte à replicação multimestre.

OpenDS / OpenDJ

OpenDS (e seu produto sucessor OpenDJ ) implementado multi-master desde a versão 1.0. A replicação de vários mestres OpenDS / OpenDJ é assíncrona, ela usa um log com um mecanismo de publicação-assinatura que permite o dimensionamento para um grande número de nós. A replicação OpenDS / OpenDJ resolve conflitos no nível de entrada e de atributo. A replicação OpenDS / OpenDJ pode ser usada em uma rede de longa distância .

OpenLDAP

OpenLDAP , o servidor LDAP de código aberto amplamente usado , implementa a replicação multimestre desde a versão 2.4 (outubro de 2007) [1] .

Sistemas de Gerenciamento de Banco de Dados

Amazon Aurora

O Amazon Aurora é composto de nós de gravador, que replicam registros de redo, e 6 nós de armazenamento. O nó gravador envia a mudança para cada nó de armazenamento, cada um dos quais verifica se há conflitos e relata a confirmação ou rejeição da mudança.

Apache CouchDB

O Apache CouchDB usa um sistema de replicação multimestre simples, baseado em HTTP, construído a partir do uso de um armazenamento de dados somente para anexos e do uso de Controle de Simultaneidade Multiversion (MVCC) .

Cada documento contém um ID de revisão, de modo que cada registro armazena a linha do tempo evolutiva de todos os IDs de revisão anteriores levando a si mesmo - que fornece a base do sistema MVCC do CouchDB . Além disso, mantém um índice por sequência para todo o banco de dados. "O processo de replicação copia apenas a última revisão de um documento, portanto, todas as revisões anteriores que estavam apenas no banco de dados de origem não são copiadas para o banco de dados de destino."

O replicador CouchDB atua como um cliente HTTP simples agindo em um banco de dados de origem e de destino . Ele compara os IDs de sequência atuais do banco de dados, calcula as diferenças de revisão e faz as alterações necessárias no destino com base no que foi encontrado no histórico do banco de dados de origem . A replicação bidirecional é o resultado de meramente fazer outra replicação com os valores de origem e destino trocados.

ArangoDB

ArangoDB é um sistema de banco de dados multi-modelo nativo que usa replicação multi-master. Os clusters em ArangoDB usam o modelo mestre / mestre CP sem um único ponto de falha. Quando um cluster encontra uma partição de rede, ArangoDB prefere manter sua consistência interna ao invés de disponibilidade. Os clientes têm a mesma visão do banco de dados, independentemente do nó ao qual se conectam. E o cluster continua atendendo às solicitações mesmo quando uma máquina falha.

Cloudant

Cloudant , um sistema de banco de dados distribuído, usa basicamente a mesma API HTTP do Apache CouchDB e expõe a mesma capacidade de replicação usando o Controle de simultaneidade multiversão (MVCC) . Os bancos de dados Cloudant podem se replicar entre si, mas internamente, os nós dentro dos clusters Cloudant usam replicação multimestre para ficar em sincronia uns com os outros e fornecer alta disponibilidade aos consumidores de API.

Cluster eXtremeDB

O eXtremeDB Cluster é o subsistema de armazenamento em cluster para a família de produtos de banco de dados integrado eXtremeDB da McObject . Ele mantém a consistência do banco de dados em vários nós de hardware, replicando as transações de maneira síncrona (confirmação de duas fases). Uma característica importante do Cluster eXtremeDB é a replicação da transação , em contraste com o baseado em arquivo de log, baseado em instrução SQL ou outros esquemas de replicação que podem ou não garantir o sucesso ou falha de transações inteiras. Consequentemente, o eXtremeDB Cluster é um sistema compatível com ACID (não BASE ou consistência eventual ); uma consulta executada em qualquer nó do cluster retornará o mesmo resultado como se executada em qualquer outro nó do cluster.

Oráculo

Os clusters de banco de dados implementam a replicação multimestre usando um de dois métodos. A replicação multimestre assíncrona confirma as alterações de dados em uma fila de transações adiadas que é processada periodicamente em todos os bancos de dados no cluster. A replicação multimestre síncrona usa a funcionalidade two-phase commit do Oracle para garantir que todos os bancos de dados com o cluster tenham um conjunto de dados consistente .

Microsoft SQL

O Microsoft SQL fornece replicação multimestre por meio da replicação ponto a ponto. Ele fornece uma solução de escalabilidade horizontal e alta disponibilidade, mantendo cópias de dados em vários nós. Construída com base na replicação transacional, a replicação ponto a ponto propaga alterações transacionais consistentes quase em tempo real.

MySQL / MariaDB

Em um nível básico, é possível obter um esquema de replicação multimestre começando com o MySQL versão 3.23 com replicação circular. Partindo disso, MariaDB e MySQL vêm com algum suporte de replicação, cada um deles com nuances diferentes.

Em termos de suporte direto, temos:

MariaDB: suporta nativamente a replicação multimestre desde a versão 10.0, mas a resolução de conflitos não é suportada, então cada mestre deve conter bancos de dados diferentes. No MySQL, ele é denominado como fonte múltipla disponível desde a versão 5.7.6 .

MySQL: MySQL Group Replication, um plugin para multi-master síncrono virtual com tratamento de conflitos e recuperação distribuída foi lançado com 5.7.17 .

Projetos de cluster:

O cluster MySQL oferece suporte para detecção e resolução de conflitos entre múltiplos mestres desde a versão 6.3 para um verdadeiro recurso multimestre para o servidor MySQL.

Há também um projeto externo, Galera Cluster criado por codership , que fornece capacidade multimestre verdadeira, com base em um fork do mecanismo de armazenamento InnoDB e plug-ins de replicação customizados. A replicação é síncrona, portanto, nenhum conflito é possível.

O Percona XtraDB Cluster também é uma combinação da biblioteca de replicação Galera e do MySQL com suporte a multi-master.

PostgreSQL

Existem várias opções para replicação multimestre síncrona. Postgres-XL que está disponível sob a Licença Pública Mozilla, e PostgresXC (agora conhecido como Postgres-X2 ) que está disponível sob a mesma licença que o próprio PostgreSQL são exemplos. Observe que o projeto PgCluster ( Arquivado em 05-07-2017 na Máquina Wayback ) foi abandonado em 2007.

A documentação de replicação para PostgreSQL categoriza os diferentes tipos de replicação disponíveis. Existem várias opções para multimestre distribuído, incluindo Bucardo , rubyrep e replicação bidirecional BDR .

PostgreSQL BDR

O BDR visa a eventual inclusão no núcleo do PostgreSQL e foi avaliado como uma demonstração de desempenho significativamente aprimorado em relação às opções anteriores. O BDR inclui replicação de gravações de dados (DML), bem como alterações na definição de dados (DDL) e sequências globais. Os nós BDR podem ser atualizados online a partir da versão 0.9. 2ndQuadrant tem desenvolvido BDR continuamente desde 2012, com o sistema usado em produção desde 2014. A versão mais recente do BDR 3.6 fornece detecção de conflito em nível de coluna, CRDTs, replicação rápida, consistência de consulta de vários nós e muitos outros recursos.

Ingres

No Ingres Replicator, os objetos atualizados em um servidor Ingres podem ser replicados para outros servidores, sejam locais ou remotos, por meio da replicação multimestre. Se um servidor falhar, as conexões do cliente podem ser redirecionadas para outro servidor. Não é necessário que todos os servidores Ingres em um ambiente se repliquem uns com os outros, pois isso poderia causar tráfego de rede excessivo em grandes implementações. Em vez disso, o Ingres Replicator permite que os dados apropriados sejam replicados para os servidores apropriados sem tráfego de replicação excessivo. Isso significa que alguns servidores no ambiente podem servir como candidatos a failover, enquanto outros servidores podem atender a outros requisitos, como o gerenciamento de um subconjunto de colunas ou tabelas para uma solução departamental, um subconjunto de linhas para uma região geográfica ou replicação unilateral para um relatório servidor. No caso de falha de origem, destino ou rede, a integridade dos dados é imposta por meio desse protocolo de confirmação de duas fases , garantindo que toda a transação seja replicada ou nenhuma delas seja. Além disso, o Ingres Replicator pode operar sobre RDBMSs de vários fornecedores para conectá-los.

Veja também

Referências

links externos