Da última vez, falamos sobre o suporte do conector Kafka do Couchbase para compressão e IPv6. Desde então, aprimoramos o conector de coletor com suporte para definir valores de tempo de vida para documentos recebidos e adicionamos a capacidade de atribuir IDs de documentos compostos de vários campos do documento.
Recentemente, temos nos concentrado em garantir que o conector Kafka seja o mais tolerante possível a falhas. Hoje, gostaria de apresentar a versão beta 3.4 do conector Kafka e falar sobre uma grande melhoria na forma como as reversões são tratadas após um failover. Nosso objetivo ao lançar uma versão beta é colocar esse recurso em suas mãos o mais rápido possível para que possamos incorporar seu feedback à versão final.
Um pessimista é um realista que mantém um sistema distribuído
O hardware falha o tempo todo. Neste exato momento, em algum lugar do mundo, um controlador de E/S queimado está enviando sinais de fumaça. Os nós do Couchbase podem falhar e de fato falham, mas um dos melhores motivos para criar seu aplicativo no Couchbase é que, quando ocorre a inevitável falha de hardware, a recuperação é muito fácil.
Cada bucket do Couchbase é particionado em vários "buckets virtuais", e cada partição é replicada entre os nós do cluster. Em um determinado momento, uma das cópias está "ativa", ou seja, é com ela que os clientes se comunicam. (Um cliente também pode ler de uma réplica, mas você precisa se esforçar para fazer isso). Você pode pensar em uma réplica como um backup em tempo real de uma instância ativa.
Então, o que acontece quando esse sinal de fumaça vem de um nó em um cluster do Couchbase? Em algum momento, você desejará fazer o fail over do nó com falha (removendo-o do cluster) e reequilibrar (reatribuindo as tarefas do nó com falha aos nós restantes). Para cada partição que estava ativa no nó com falha, uma das réplicas é promovida ao status "ativo". Os nós restantes também assumem a folga e começam a hospedar réplicas adicionais para substituir as que estavam no nó com falha.
Dependendo das necessidades de sua implementação, todo o processo de failover e rebalanceamento pode ser iniciado por uma pessoa que aperta um botão ou por um algoritmo de detecção automática de falhas. Muito legal, não é?
Agora que o cenário está pronto, vamos considerar uma questão importante: o que acontece quando uma réplica não está completamente atualizada quando a instância ativa falha?
A resposta (que espero que não surpreenda ninguém) é que todas as alterações que ainda não foram salvas na réplica são perdidas. Em termos de ficção científica, essas alterações estavam em uma linha do tempo alternativa que deixou de existir. Elas foram "revertidas".
Não estou tentando causar uma grande sensação / Só estou falando sobre a mitigação da reversão
O que tudo isso tem a ver com o conector Kafka? O conector usa o protocolo de alteração de banco de dados (DCP) para receber notificações de alteração. A implementação do protocolo DCP foi criada para ser rápida e anuncia as alterações antes mesmo de serem gravadas no disco. Para compensar esse otimismo, o protocolo também inclui um mecanismo de reversão que efetivamente diz: "Desculpe, falei cedo demais. Sabe aquelas últimas alterações de que falei? Bem, elas não aconteceram de fato". Isso funciona muito bem no Couchbase Server, onde estamos cientes desses detalhes de particionamento e podemos nos adaptar às novas realidades à medida que elas acontecem. É exatamente o que fazemos com a replicação, atualizações de texto completo, atualizações de índice etc.
As versões anteriores do conector Kafka publicavam eventos no tópico do Kafka imediatamente. Assim que o servidor DCP anunciava uma alteração, essa alteração era publicada no tópico. Quando ocorria uma reversão, não havia muito o que fazer a respeito; as mensagens do Kafka não podem ser retiradas depois de publicadas, pois os tópicos são apenas anexados. Os consumidores receberiam mensagens irreais daquela linha do tempo alternativa de que falamos.
Dependendo do seu aplicativo, as mensagens de salto de dimensão podem ser inofensivas ou podem causar pânico. Se você preferir que seus tópicos do Kafka contenham apenas alterações reais, persistentes e replicadas no banco de dados, prepare-se para boas notícias.
Detalhes para os desorientados
Já chega de acumulação. Vamos falar sobre o que está na versão beta e como funciona a atenuação da reversão.
Quando a atenuação da reversão estiver ativada (o que ocorre por padrão), o conector verificará automaticamente o Couchbase Server para descobrir quais alterações foram realmente persistidas no disco. O conector armazenará as alterações em buffer até que a persistência seja observada em todas as réplicas. Nesse ponto, é muito improvável que as alterações sejam revertidas (embora isso ainda seja possível em alguns cenários que envolvem várias falhas). Então, e somente então, o conector publica mensagens no tópico do Kafka.
Naturalmente, há alguma latência e um pouco de sobrecarga com esse esquema. Se você quiser voltar ao comportamento antigo de publicar alterações imediatamente, a atenuação da reversão pode ser facilmente desativada; consulte a documentação para obter detalhes.
Siga o fluxo
O controle de fluxo é uma técnica para evitar que os produtores ultrapassem os consumidores. No nosso caso, o conector Kafka envia mensagens de confirmação ao servidor DCP para informar a quantidade de dados que foi processada. O servidor pausa o fluxo quando a quantidade de dados não reconhecidos excede um limite chamado de "tamanho do buffer de controle de fluxo".
Como a atenuação da reversão envolve o armazenamento em buffer de um número potencialmente grande de mensagens, é importante que o tamanho do buffer de controle de fluxo seja ajustável.
As versões anteriores do conector usavam um tamanho de buffer codificado de 20 megabytes. O novo padrão é 128 megabytes, o que permite um armazenamento em buffer mais agressivo. Sinta-se à vontade para ajustar esse valor para ver o que funciona melhor para sua carga de trabalho. Se quiser aumentar muito o tamanho, você pode alocar mais memória para o conector usando a opção KAFKA_HEAP_OPTS variável de ambiente.
Todos os fluxos bons devem chegar a um EOF
Esperamos que você experimente a versão beta 3.4 com mitigação de reversão. Faça o download no link na parte superior da seção Guia de início rápido. Por favor, poste suas impressões no Fórum do Couchbase e faremos o possível para incorporar seus comentários na versão final. Obrigado e até a próxima!
