Reversão do DCP do Couchbase e como o controle de qualidade os testa

Introdução

Nesta postagem, descreverei como a equipe de controle de qualidade do Couchbase se esforça para testar os produtos do Couchbase, usando os rollbacks do DCP como exemplo, e primeiro darei informações básicas sobre o que é o DCP e o que é um rollback do DCP.

O que é DCP?

DCP significa Database Change Protocol (Protocolo de alteração de banco de dados) entre nós do Couchbase, como réplicas ou exibições, ou para clientes externos, como XDCR ou FTS. Ele segue um modelo de produtor/consumidor e oferece alta taxa de transferência e baixa latência. Os dados são transmitidos por vbucket. Ele é descrito como aqui.

O número de sequência é de especial interesse. O número de sequência é um número monotonicamente crescente associado a mutações em um vbucket e é usado para manter o produtor e o consumidor em sincronia.

O que é uma reversão?

Não, não são essas reversões

Uma reversão do Couchbase ocorre quando um cliente se conecta a um produtor com um número de sequência maior do que o que o produtor tem ou, em outras palavras, o cliente tem mutações mais recentes, mas como elas não são a "verdade", ele precisa reverter ou desfazer algumas mutações para se alinhar com a nova verdade.

Isso não é comum, mas acontece e, para fins de integridade dos dados, é importante que seja tratado corretamente.

Em um ambiente real, isso pode acontecer nos seguintes cenários:

Failover com mutações em andamento (isso pode ocorrer com um hard failover)

1. O cliente está conectado ao nó ativo A
2. As mutações com número de sequência 100 chegam ao cliente e estão em voo para o nó de réplica B
3. Antes que a mutação com o número de sequência 100 chegue ao nó B, há um failover; o nó B tem apenas o número de sequência 90
4. O cliente, reconhecendo o failover, conecta-se ao novo nó ativo B com o número de sequência 100
5. O nó B, que tem apenas o número de sequência 90, responde ao cliente solicitando uma reversão para a sequência 90
6. O cliente desfaz os efeitos das mutações para os números de sequência 91-100 e solicita uma conexão com o produtor com o número de sequência 90.

Falha com dados não persistentes

1. O cliente está conectado ao nó ativo A
2. As mutações até o número de sequência 90 foram mantidas
3. As mutações até o número de sequência 100 chegam ao cliente e ainda não são mantidas
4. O Memcached falha e reinicia, sem failover
5. O cliente se reconecta ao nó A com o número de sequência 100
6. Semelhante às etapas 5 e 6 acima

Testes para e com reversões de DCP (e como elas são interrompidas)

A organização de controle de qualidade do Couchbase testa as reversões de três maneiras:

Produtor

 O produtor solicita reversões nos casos em que o cliente solicita um número de sequência maior do que o conhecido pelo produtor. Verificamos que o produtor realmente solicita que o cliente faça a reversão e retorna dados consistentes a partir desse ponto.

  Desenvolvemos um cliente DCP personalizado. Ele executa mutações e cria paralelamente conexões DCP e exercita cenários específicos. Ele pode manipular o número de sequência solicitado e acionar outras interações de recursos, como compactação, e monitorar o estado de persistência

Consumidor

Ao receber uma solicitação de reversão, verifique se o cliente desfaz corretamente as mutações posteriores e aplica corretamente as novas mutações.

O cenário a seguir fará com que um cliente receba uma solicitação de reversão de forma determinística:

1. Parar a persistência
2. Eliminar o memcached e reiniciar o memcached
3. As conexões DCP serão revertidas para o número de sequência antes da interrupção da persistência

Os autores de testes usam o cenário acima para acionar a reversão e verificar se o cliente desfaz corretamente as mutações revertidas.

Os problemas típicos encontrados no lado do consumidor dizem respeito ao fato de o consumidor reter informações associadas às mutações revertidas.

Teste do sistema

Faça hard failovers em altas taxas de mutação (o que faz com que os vbuckets ativos fiquem à frente da réplica) durante as visualizações e a 2i. Como resultado, haverá perda de dados ao promover vbuckets de réplica para ativos e reverter números de sequência, mas o cluster deve continuar estável. Os erros típicos encontrados incluem a réplica recém-promovida com dados inconsistentes e clientes que não lidam corretamente com a reversão.