Entendendo como as transações funcionam em réplicas entre data centers (XDCR)

O Couchbase oferece uma impressionante variedade de ferramentas e recursos avançados em seus serviços de plataforma. Entre eles, Replicação entre data centers garante a replicação perfeita de dados em várias regiões geográficas, enquanto as transações ACID suportam de forma robusta as cargas de trabalho de transações, aumentando a confiabilidade e a eficiência.

Muitos clientes frequentemente se deparam com uma pergunta comum: Por que há uma diferença na contagem de documentos entre os clusters de origem e de destino ao usar transações e XDCR (Cross Data Center Replication)? Certos tipos de documentos nunca aparecem no cluster de destino, o que gera confusão sobre se esse problema está relacionado ao XDCR. Antes de nos aprofundarmos nos mecanismos subjacentes, vamos primeiro esclarecer alguns termos importantes.

O que é XDCR?

O XDCR facilita a replicação de dados entre bancos de dados ou baldes que podem residir em diferentes clusters, provedores de nuvem ou data centers. O XDCR também oferece suporte à replicação intra-cluster, permitindo a replicação de dados entre bancos de dados diferentes dentro do mesmo cluster.

Projetado para clusters de bancos de dados distribuídos geograficamente, o XDCR protege contra falhas no data center e oferece suporte à alta disponibilidade com configurações de cluster ativo-ativo. O protocolo subjacente usado pelo XDCR é o Data Change Protocol (DCP), que também é empregado para replicação intra-cluster, garantindo replicação de memória para memória de baixa latência.

O XDCR oferece operações unidirecionais e bidirecionais e oferece suporte à replicação ativo-ativo com resolução automática de conflitos. Ele também permite a replicação filtrada para replicar subconjuntos de documentos com base nas necessidades do cluster de destino.

O que são transações?

Uma transação é uma única unidade lógica de trabalho que consiste em várias operações de banco de dados que são executadas como um todo ou não são executadas. As transações do Couchbase permitem ÁCIDO (atômicas, consistentes, isoladas e duráveis) no banco de dados. O Couchbase oferece suporte a transações ACID distribuídas de vários documentos e vários nós em escala, sem sacrificar o desempenho e a alta disponibilidade.

O que é um registro de transação ativo?

No Couchbase, os dados de um banco de dados ou bucket são divididos entre contêineres lógicos chamados vbucketcada um residindo em um único nó. Cada bucket do servidor Couchbase tem 1024 vbucket (64 no MacOS). Os Active Transaction Records (ATR) são documentos de metadados em cada vbucket que registram cada tentativa de transação ativa, indicando se uma tentativa foi confirmada. As entradas de ATR servem como interruptores para marcar as transações como confirmadas. Os ATRs são criados e mantidos automaticamente pelo Couchbase e podem ser facilmente identificados por seu prefixo _txn:atr-. Esses registros podem ser visualizados, mas não devem ser alterados por usuários ou aplicativos.

Como o XDCR replica os documentos de transação?

No Couchbase, as transações têm como escopo apenas um único cluster primário e não há suporte para transações na configuração ativo-ativo. Uma transação pode envolver várias tentativas, cada uma criando uma entrada em um documento ATR. Essas entradas são cruciais como fontes únicas de verdade para as tentativas. Os ATRs residem na coleção padrão do compartimento do primeiro documento alterado, a menos que especificado de outra forma. Cada coleção usada para ATRs conterá 1.024 documentos ATR. Durante a fase de preparação, as mutações dentro de uma transação são colocadas em um balde de atributos estendidos (XATTRs), permanecendo invisível para o cluster do Couchbase até a fase de confirmação. A intenção de gravação em uma transação é especificada nos XATTRs do documento e atua como um bloqueio de gravação, impedindo que outros clientes modifiquem o mesmo documento até que a transação seja confirmada ou abortada. Essas intenções de gravação funcionam como bloqueios exclusivamente para o cluster primário.

O XDCR replica os dados do cluster de origem para o de destino de forma assíncrona, oferecendo suporte à consistência eventual para atualizações transacionais. Por isso, uma confirmação no cluster de origem não garante que a transação tenha sido replicada pelo XDCR. Depois que uma transação é confirmada no cluster de origem, as atualizações são replicadas para o cluster de destino, uma a uma. Isso significa que uma transação confirmada no cluster de origem não garante o comprometimento imediato no cluster de destino. Em caso de failover, uma transação confirmada pode ser perdida se não for confirmada no destino antes do failover, portanto, os aplicativos devem aguardar a conclusão de todas as solicitações pendentes ou abortar as solicitações antes de fazer o failover para o cluster secundário.

Etapas de replicação da transação

As etapas a seguir descrevem a lógica da transação e a replicação de dados usando o XDCR:

1. 1. Início da tentativa de transação: Cada tentativa de transação pelo aplicativo (SDK) cria uma entrada no ATR, funcionando como um bloqueio virtual. Feito em ambos os nós, mas mostrado em um na figura abaixo para simplificar. 
   2. Alterações na preparação: As alterações transacionais são preparadas nos XATTRs dos documentos de destino, sem afetar os corpos dos documentos. Isso pode ocorrer em vários nós e documentos. Essas alterações de estágio funcionam como um bloqueio contra quaisquer outras transações nesses documentos. 
   3. Compromisso: Depois que a lógica da transação é completamente executada, a tentativa de transação é confirmada, atualizando a entrada de tentativa no ATR (feita em ambos os nós, mas mostrada em um na figura abaixo para simplificar) e a lista de IDs de documentos envolvidos na transação é atualizada. Os atores transacionais podem ler as informações atualizadas dos XATTRs, se necessário.
   4. Finalização de alterações: As alterações transacionais são movidas dos XATTRs do documento para os corpos do documento (feito pelo SDK, mas mostrado diretamente na imagem abaixo para simplificar)
   5. Conclusão e limpeza: A tentativa de transação é marcada como "Concluída" e removida do ATR.
   6. Replicação: As alterações do documento recém-atualizado são replicadas uma a uma para o cluster de destino usando o XDCR.

Conclusão

O XDCR é uma ferramenta avançada para replicação em diferentes data centers e regiões geográficas, oferecendo suporte à replicação unidirecional e bidirecional com consistência eventual para alterações transacionais. Por padrão, as alterações não confirmadas em uma transação e os metadados para registro de transações nunca são enviados aos clusters de destino, garantindo a integridade e a consistência dos dados em ambientes replicados.

A compreensão desses mecanismos pode ajudar a esclarecer por que determinados documentos podem não aparecer imediatamente no cluster de destino, pois eles dependem dos estados transacionais e dos processos de replicação descritos acima.