Breve descrição

O Amazon Managed Streaming for Apache Kafka (Amazon MSK) usa atualizações contínuas para manter a alta disponibilidade e oferecer suporte à E/S do cluster durante a aplicação de patches. Durante esse processo, os agentes são reinicializados um por um, e o próximo corretor não é reinicializado até que as partições do corretor reinicializado atual sejam totalmente atualizadas (sincronizadas). É normal visualizar erros de desconexão transitórios em seus clientes durante esse processo de atualização.

Para evitar que os clientes passem por períodos de inatividade durante a aplicação de patches de segurança, use as práticas recomendadas a seguir para tornar os clusters altamente disponíveis.

Resolução

Configurar um cluster três AZ

Se uma zona de disponibilidade falhar, um cluster Three-AZ protege contra qualquer tempo de inatividade.

O Amazon MSK define a propriedade do agente broker.rack para obter uma atribuição de replicação com reconhecimento de rack para tolerância a falhas no nível da zona de disponibilidade. Significa que quando você usa um cluster de três AZ com um fator de replicação (RF) de três, cada uma das três réplicas de partição está em uma zona de disponibilidade separada.

Observação: Ter um cluster dois AZ com um RF-3 não permite que cada uma das três réplicas de partição esteja em uma zona de disponibilidade separada. O Amazon MSK não permite que você crie um cluster em uma única zona de disponibilidade.

Verifique se o fator de replicação é a contagem da zona de disponibilidade

Ao reiniciar um agente durante a aplicação de patches de segurança, o líder fica indisponível. Como resultado, uma das réplicas seguidoras é eleita como a nova líder para que o cluster possa continuar atendendo aos clientes.

Um RF-1 pode resultar em partições indisponíveis durante uma atualização contínua porque o cluster não tem nenhuma réplica para promover como novo líder. Um RF-2, com uma réplica sincronizada mínima (miniSR) de um, pode resultar em perda de dados, mesmo quando a confirmação do produtor (acks) está definida como “tudo”. Para que uma redação seja bem-sucedida, um miniSR de um exige que apenas o líder reconheça a redação. Se o corretor da réplica líder cair imediatamente após a confirmação, mas antes que a réplica do seguidor seja atualizada, ocorrerá perda de dados. Para obter mais informações sobre min.insync.replicas, consulte a documentação do Apache Kafka.

Defina o mínimo de miniSR para no máximo RF-1

Ao definir miniSR como o valor de RF pode resultar em falhas do produtor quando um corretor está fora de serviço devido a uma atualização contínua. Se as réplicas não enviarem uma confirmação para o produtor escrever, o produtor criará uma exceção. Por exemplo, se AZ for igual a três e RF igual a três, o produtor aguardará que todas as três réplicas de partição (incluindo a líder) reconheçam as mensagens. Quando um dos agentes estiver fora de serviço, apenas duas das três partições retornam as confirmações, resultando em exceções do produtor.

Esse cenário pressupõe que o pacote do produtor esteja definido como “todos”. Quando você define os pacotes do produtor como “todos”, o registro não é perdido, desde que pelo menos uma réplica sincronizada permaneça ativa. Para obter mais detalhes sobre pacotes de produtores, consulte a documentação do Apache Kafka.

Inclua pelo menos um agente de cada AZ na cadeia de conexão do cliente

O cliente usa o endpoint de um único agente para inicializar uma conexão com o cluster. Durante a conexão inicial com o cliente, o agente envia metadados com informações sobre os agentes que o cliente deve acessar.

Quando um agente fica indisponível, a conexão falha. Por exemplo, há apenas um agente na cadeia de conexão de um cliente. Durante a aplicação de patches, o cliente não consegue estabelecer uma conexão inicial com o cluster quando você reinicia o agente.

Ou há vários agentes em uma string de conexão do cliente. Nesse caso, a string de conexão do cliente permite o failover quando o agente usado para estabelecer a conexão fica offline. Para mais informações sobre como configurar uma cadeia de conexão com vários corretores, consulte Como obter os agentes de inicialização do Amazon MSK.

Permitir novas tentativas

Ao reinicializar um agente, as partições líderes desse corretor ficam indisponíveis. Como resultado, o Apache Kafka promove réplicas de partições em outro agente como novos líderes. O cliente agora solicita uma atualização de metadados para localizar as novas partições líderes. Durante essa mudança, é normal que seu cliente tenha erros transitórios.

Por padrão, os clientes têm novas tentativas incorporadas para lidar com esses tipos de erros transitórios. Confirme se seu cliente está configurado para novas tentativas. Para obter mais informações sobre como configurar novas tentativas, consulte a documentação do Apache Kafka.