Protocolo de alteração de banco de dados: O supercondutor que liga a replicação do Couchbase Server 3.0

O Database Change Protocol (DCP) é o protocolo de replicação principal da versão 3.0 e é usado para conectar nós e clusters em centros de dados distribuídos geograficamente. Nesta postagem, vamos nos aprofundar em seu funcionamento e em como ele permite maior disponibilidade, desempenho e escala com o Couchbase Server 3.0.  

Vamos começar explicando por que a replicação é uma parte tão importante de qualquer banco de dados: Aqui está o "porquê": 

• Proteção de dados: A replicação é usada para proteger contra falhas, mantendo os feeds de réplica locais e entre data centers. A velocidade com que um banco de dados pode replicar os dados para as réplicas determina a janela de perda de dados. Quanto menos eficiente for um banco de dados na replicação, maior será a janela de perda de dados!
• Fornecimento de índices mais recentes: A replicação também é o meio de atualizar as exibições no Couchbase. O índice de mapa/redução incremental usado para responder às consultas precisa de um feed rápido para se manter atualizado. Especialmente as consultas que precisam de uma visualização consistente dos dados não poderão ser respondidas se o feed de replicação não for incrivelmente rápido e eficiente!

Então, o que torna o DCP especial e diferente dos protocolos de replicação concorrentes? Há quatro propriedades principais: 

• Pedido: O DCP solicita mutações. Isso é importante para poder registrar onde as coisas foram deixadas. 
• Pode ser reiniciado: O DCP otimiza as reinicializações após falhas de curta ou longa duração. 
• Consistente: O DCP é capaz de produzir com eficiência um instantâneo consistente.
• Alto desempenho: O DCP é baseado em memória. Ele transmite as alterações ansiosamente, desde que os clientes consigam acompanhá-las.

Arquitetura

Há três partes que compõem a maior parte da mágica do DCP: UUID do vbucket, números de sequência e registro de failover. Presumo que você já conheça alguns conceitos como vbuckets. (Você pode encontrar mais informações aqui sobre vbuckets). Vamos dar uma olhada no que eles são:

Um UUID de vbucket e um número de sequência de mutação identificam exclusivamente cada mutação no Couchbase Server. Vamos explicar esses conceitos: os vbuckets representam shards no Couchbase Server. Cada O vbucket tem um UUID exclusivo atribuído a ele. Cada mutação recebe um número de sequência. O número de sequência é um número monotonicamente crescente e tem o escopo de cada vbucket. A mágica da consistência e da capacidade de retomada granular é obtida por meio do registro de failover. Cada vbucket também mantém um registro de failover. O log de failover registra vários pares de UUID de vbucket e número de sequência. A primeira entrada marca o início do tempo e cada nova entrada marca um failover. Os vbuckets mestre e de réplica no sistema mantêm o mesmo registro de failover. Quando ocorre uma falha - digamos que o vbucket mestre falhe, por exemplo - um vbucket de réplica é atualizado para um vbucket mestre. A nova entrada do registro de failover do vbucket mestre registra o UUID do vbucket e o último número de sequência do novo vbucket mestre e o replica para os vbuckets de réplica para marcar a ocasião. Essa mecânica básica permite um monte de mágica. Na próxima seção, vamos dar uma olhada em algumas das principais operações aprimoradas na versão 3.0 com o DCP e explicar como esses mecanismos fazem isso acontecer.

Backups incrementais

3.0 pode lhe proporcionar uma eficiência 100 vezes maior no armazenamento de backups. Veja como: Com a versão 3.0, os backups completos podem ser complementados com backups incrementais para maior eficiência de armazenamento. Os backups incrementais simplesmente fazem backup apenas dos dados que foram alterados desde o último backup completo, cumulativo ou incremental. É possível tirar um instantâneo completo e criar uma cadeia de backups incrementais ou cumulativos, em vez de tirar instantâneos completos todas as vezes. O UUID do Vbucket, o número de sequência e o registro de failover fornecem os metadados necessários para manter a consistência entre a cadeia de backups.

Visualizações e processamento de mapa/reprodução incremental

Consultas de visualização de baixa latência são essenciais para um aplicativo ágil e observamos uma melhoria de 50 vezes na latência das consultas de visualização com a versão 3.0. O Map/Reduce já existe há algum tempo no mundo do Hadoop, mas o Couchbase oferece processamento incremental de map/reduce para permitir o pré-cálculo de suas consultas em uma visualização. É assim que o Couchbase Server proporciona consultas de baixa latência. O mecanismo de processamento incremental é alimentado por um fluxo DCP. À medida que as mutações chegam à memória, elas são transmitidas para processamento nos documentos de design e nas exibições dentro deles. O fluxo melhora o frescor dos índices em mais de 50 vezes em comparação com as versões anteriores. Muitas consultas exigem consistência. O desenvolvedor do Couchbase tem opções sobre a consistência da visualização - é possível consultar o que o índice processou em qualquer ponto (stale=ok) OU solicitar a consulta da visualização que contém todas as mutações até o ponto da consulta (stale=false). O DCP se destaca especialmente para as consultas do último tipo, pois tem a capacidade de transmitir as alterações com uma rapidez incrível para o processador de visualização. 

Recuperação Delta para um reequilíbrio mais rápido

Se você estiver trazendo um nó de volta ao cluster que sofreu uma falha devido a um problema, não precisará mais retroceder horas ou dias e reenviar as alterações para o nó. Com o UUID do vbucket, o número de sequência e o registro de failover, o DCP pode reiniciar com grande granularidade a partir de onde parou. Se o nó de entrada estiver ausente do cluster por alguns minutos, ele poderá se recuperar simplesmente recebendo as mutações ausentes dos últimos minutos com a opção de recuperação de nó delta. Observamos uma melhora de 100s nos tempos de rebalanceamento com a recuperação do nó delta, especialmente quando o tamanho dos dados é enorme por nó.

Garantia de durabilidade com "ReplicateTo" 

O Couchbase Server tem consistência incorporada - você pode "ler sua própria gravação" sem problemas, mesmo quando escreve mutações na memória. No entanto, muitos desenvolvedores precisam de garantias de durabilidade para seus aplicativos, para que eles possam sobreviver a falhas de nós sem perder dados. Alguns dependem da persistência clássica em disco, mas, para melhorar a disponibilidade e a capacidade de recuperação, muitos desenvolvedores do Couchbase escolhem a replicação como garantia de durabilidade dos dados. Isso é feito por meio do método ReplicateTo nos SDKs nativos do Couchbase. O ReplicateTo garante que a confirmação de sua mutação retorne DEPOIS de ter sido replicada para uma ou mais réplicas. Com a replicação de streaming de alto desempenho do DCP, você pode replicar a mutação para uma réplica até 180 vezes mais rápido. Vi latências de 1-2 ms com "ReplicateTo" em meus testes na nuvem. No entanto, esses números absolutos dependem da qualidade da infraestrutura e do HW em que estou executando, portanto, considere-os como um grão de sal. 

Replicação entre data centers

XDCR - replicação entre data centers - também depende do DCP. A replicação de streaming diretamente da memória para outro data center significa que podemos proteger melhor seus dados! Imagine uma replicação bidirecional entre dois clusters. Se o cluster #1 falhar, a quantidade de mutações perdidas será determinada pela maior latência de replicação. A replicação rápida significa que, em um desastre regional como este, a exposição à perda de dados é minimizada! Já vimos Melhoria de 4x na latência de replicação com XDCR no Couchbase Server 3.0. 

O XDCR também é propenso a erros de rede e soluços, e é importante poder se recuperar rapidamente desses problemas e voltar a funcionar! Os metadados do DCP nos permitem retomar rapidamente de onde paramos em caso de falhas de comunicação. 

Esses são apenas alguns exemplos de como o DCP amplia os recursos do Couchbase Server. Há muito mais... Na verdade, há mais 200 recursos no Couchbase Server 3.0, e a maioria deles está presente devido à sólida base fornecida pelo DCP. 

Se quiser se aprofundar mais no tratamento de falhas e na mecânica por trás dos DCPs rápidos presumivelmente, você pode assistir à palestra detalhada sobre o DCP no Couchbase Connectou veja os detalhes da implementação aqui no site do github.

Feliz teste.