Vimos em um post anterior É fácil configurar uma replicação entre data centers (Cross Data Center Replication)?XDCR), hoje vamos nos aprofundar um pouco mais para entender o que torna o XDCR um recurso tão bom.
Em primeiro lugar, o XDCR permite que você replique dados entre clusters de tamanhos diferentes, o que o torna uma excelente opção para desastre e recuperação plano. Além disso, é uma maneira simples, mas poderosa, de aproximar os dados dos seus usuários.
A replicação é feita de memória para memória. Assim, todas as gravações são salvas primeiro na memória e, em seguida, colocadas em uma fila de replicação, que as envia pela rede por meio de vários threads. Portanto, todo o desempenho é limitado apenas pela velocidade de sua rede.
Ele também é sensível à topologia e, portanto, sempre que você adicionar ou remover nós do cluster de origem, nenhuma ação precisará ser executada no cluster de destino. Ele restabelecerá a conexão e cuidará de tudo automaticamente.
Além disso, ele também oferece reconhecimento de zona de rack, o que ajuda a proteger contra eventos de falha de vários nós, separando os dados ativos e suas réplicas em "grupos" que podem ser mapeados de forma que ocupem racks, zonas ou hosts de VM diferentes.
As replicações são feitas no nível do bucket (entre buckets de dois ou mais clusters) e podem ser configuradas da seguinte forma.
- Unidirecional: Somente os dados gravados em um dos clusters são replicados; ele é usado quando você deseja configurar um cluster em espera, por exemplo.
- Bidirecional: (também conhecida como implementação ativa para ativa), em que ambos os clusters podem gravar dados e todas as alterações são sincronizadas entre eles. Em resumo, um mapeamento bidirecional é apenas duas replicações unidirecionais apontando uma para a outra.
- Híbrido: Uma combinação das topologias Bidirecional e Unidirecional.
Graças ao DCP, você também pode pausar a replicação a qualquer momento e, depois de retomá-la, a recuperação começa no ponto de verificação mais recente.
Protocolo de alteração de banco de dados
O Database Change Protocol (DCP) é um protocolo de streaming de alto desempenho que usamos internamente para comunicar o estado dos dados usando um changelog ordenado. Ele é robusto e resiliente diante de erros transitórios, por exemplo, se a comunicação for interrompida, o DCP é capaz de retomar a partir do ponto exato da última atualização bem-sucedida assim que a conectividade for restabelecida.
Ele também é otimizado para enviar somente os dados necessários. Por exemplo, se houver várias alterações em um documento, apenas a versão mais recente será marcada para ser replicada.
O XDCR depende do DCP para propagar as alterações. Dessa forma, ele garante que o mesmo documento será replicado entre todos os clusters, independentemente de problemas de conectividade.
Vamos destacar também outros dois recursos interessantes do XDCR: resolução de conflitos e filtragem de dados:
Resolução de conflitos
Um conflito ocorre quando o mesmo documento é modificado em dois locais diferentes antes de ser sincronizado entre os locais. Para manter a consistência, uma versão deve ser escolhida como a versão "correta". A resolução de conflitos fornece um método para selecionar de forma consistente e determinística qual versão do documento deve ser usada.
A resolução de conflitos do Couchbase é definida durante a criação do bucket e não pode ser alterada posteriormente. Atualmente, há suporte para dois tipos de resolução de conflitos: Registro de data e hora e Número de sequência.
Número de sequência
Após cada mutação em um documento, aumentamos um contador chamado número de revisãoportanto, sempre que houver um conflito entre dois documentos, o que tiver o número de revisão mais alto terá precedência em ambos os clusters.
Carimbo de data/hora
O TCR (Timestamp-based Conflict Resolution) é o mecanismo de resolução de conflitos mais comumente suportado em bancos de dados. O TCR resolve conflitos selecionando o documento com o carimbo de data/hora mais recente. Para que isso possa ser feito com eficácia, é essencial que os registros de data e hora criados por cada servidor estejam bem alinhados.
No entanto, o TCR pode aumentar a perda de dados, pois ignora quantas vezes um documento foi atualizado e, se um dos relógios do servidor estiver rápido/lento, você acabará com uma resolução de conflitos confusa. É por isso que a opção padrão no Couchbase é "Número de sequência".
Filtragem de dados
Por padrão, todos os documentos em um bucket de destino serão replicados, mas desde o Couchbase 6.5 você pode usar Expressões de filtragem para filtrar os dados que você deseja replicar.
A filtragem avançada oferece suporte a várias construções de linguagem para criar filtros, como regex, operadores aritméticos, lógicos e relacionais, palavras-chave, expressões, funções numéricas, funções de data, lookahead negativo etc. Você pode aplicar esses recursos nas chaves, valores, metadados e CAS do documento. Assim como o predicado das consultas N1QL, as expressões podem ser construídas usando as construções de linguagem compatíveis.
No Filtros de exclusão sessão, você também pode optar por não replicar operações de exclusão, expirações de documentos ou remover TTL e armazená-lo para fins de arquivamento.
Os filtros também podem ser editados em tempo real e a replicação continuará sem nenhuma pausa/retomada.
O XDCR, por padrão, não descarregará nenhum compartimento quando os filtros forem modificados. Essa etapa deve ser executada manualmente pelo administrador, se necessário.
Conclusão
Se você precisa de um plano de desastre e recuperação ou apenas gostaria de aproximar seus dados do usuário, o Cross Data Center Replication (XDCR) é um recurso que você deve considerar usar. Ele é simples de configurar, quase não requer manutenção e foi amplamente testado em vários casos de uso de alta carga, como Amadeus, eBay e Viber.
Para obter mais informações sobre o XDCR com o Couchbase, consulte o Portal do desenvolvedor do Couchbase ou me envie um tweet para @deniswsrosa
Atualizado em 08/08/19 - Adição de novos recursos XDCR para o Couchbase 6.5
