Entendendo como funcionam as transações em replicações entre múltiplos data centers (XDCR)

O Couchbase oferece um conjunto impressionante de ferramentas e recursos poderosos dentro de seus serviços de plataforma. Notavelmente, Replicação entre Centros de Dados garante a replicação contínua de dados em várias geografias, enquanto as transações ACID suportam de forma robusta cargas de trabalho transacionais, aumentando tanto a confiabilidade quanto a eficiência.

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

O que é o 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 diferentes bancos de dados dentro do mesmo cluster.

Projetado para clusters de bancos de dados geograficamente distribuídos, o XDCR protege contra falhas em centros de dados e oferece suporte a alta disponibilidade com configurações de cluster ativo-ativo. O protocolo subjacente usado pelo XDCR é o Protocolo de Alteração de Dados (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 bidimensionais e suporta replicação ativa-ativa 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 de forma alguma. As transações do Couchbase permitem ÁCIDO ações (atômicas, consistentes, isoladas e duráveis) no banco de dados. O Couchbase oferece suporte a transações ACID distribuídas, multi-documento e multi-nó em escala, sem sacrificar o desempenho e a alta disponibilidade.

O que é um Registro de Transação Ativa?

No Couchbase, os dados dentro de um banco de dados ou bucket são divididos entre containers lógicos chamados vbucket, cada um residindo em um único nó. Cada bucket de servidor Couchbase possui 1024 vbuckets (64 no MacOS). 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 ATR servem como chaves para marcar transações como confirmadas. Os ATRs são criados e mantidos pelo Couchbase automaticamente e podem ser facilmente identificados pelo seu prefixo _txn:atr-. Estes registros podem ser visualizados, mas não devem ser alterados por usuários ou aplicativos.

Como o XDCR Replica Documentos de Transação?

No Couchbase, as transações têm escopo limitado a um único cluster principal e as transações não são suportadas para 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 bucket do primeiro documento mutado, a menos que especificado o contrário. Cada coleção usada para ATRs conterá eventualmente 1.024 documentos ATR. Durante a fase de preparação, as mutações dentro de uma transação são preparadas no documento de um atributos estendidos propriedade (XATTRs), permanecendo invisíveis para o cluster do Couchbase até a fase de confirmação. A intenção de gravação em uma transação é especificada em XATTRs de documentos e atua como um bloqueio de gravação, impedindo que outros clientes modifiquem o mesmo documento até que a transação seja confirmada ou anulada. Essas intenções de gravação funcionam como bloqueios exclusivamente para o cluster primário.

O XDCR replica dados do cluster de origem para o de destino de forma assíncrona, suportando consistência eventual para atualizações transacionais. É por isso que um commit no cluster de origem não garante que a transação tenha sido replicada via XDCR. Assim que uma transação é confirmada (commit) 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 confirmação imediata 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 realizar o failover para o cluster secundário.

Etapas de Replicação de Transações

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

1. Iniciação de Tentativa de TransaçãoCada tentativa de transação pela aplicação (SDK) cria uma entrada no ATR, funcionando como um bloqueio virtual. Feito em ambos os nós, mas mostrado em um na imagem abaixo por simplicidade. 
2. Preparando alteraçõesAs alterações transacionais são armazenadas nos XATTRs dos documentos de destino, não afetando os corpos dos documentos. Isso pode ocorrer em vários nós e documentos. Essas alterações em estágio funcionam como um bloqueio contra quaisquer outras transações nesses documentos. 
3. ComprometimentoUma vez que a lógica da transação é executada completamente, a tentativa de transação é efetivada (committed), atualizando a entrada da tentativa no ATR (feito em ambos os nós, mas mostrado em apenas um na imagem abaixo por simplicidade) e a lista de IDs de documentos envolvidos na transação é atualizada. Atores transacionais podem ler as informações atualizadas a partir dos XATTRs, se necessário.
4. Finalizando alteraçõesAs alterações transacionais são movidas dos XATTRs do documento para os corpos dos documentos (feito pelo SDK, mas mostrado diretamente na imagem abaixo por simplicidade)
5. Conclusão e LimpezaA tentativa de transação é marcada como ‘Concluída’ e removida do ATR.
6. ReplicaçãoAs alterações do documento recém-atualizadas são replicadas uma a uma para o cluster de destino usando o XDCR.

Conclusão

XDCR é uma ferramenta poderosa para replicação entre diferentes data centers e geografias, suportando replicação unidirecional e bidirecional com consistência eventual para alterações transacionais. Por design, alterações não confirmadas em uma transação e metadados para registro de transações nunca são enviados para os clusters de destino, garantindo a integridade e a consistência dos dados em ambientes replicados.

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