Minha equipe executa o Cassandra para um aplicativo interno. Esta é a nossa configuração:
- Estamos executando o Cassandra versão 3.11.13.
- Temos vários keyspaces; cada microsserviço tem o seu próprio.
- Temos uma arquitetura ativa em duas regiões da AWS.
- Cada região possui 4 nós: 2 sementes e 2 membros.
- A topologia é um fator de replicação de 4 em cada datacenter/região, portanto, todos os nós possuem 100% dos dados.
- Nossa consistência de leitura é LOCAL_QUORUM e nossa consistência serial é LOCAL_SERIAL, para manter o status ativo-ativo.
Recentemente, tivemos um incidente em que víamos tempos limite de leitura durante consultas do cliente do aplicativo. Eles pareciam estar correlacionados com apenas um keyspace. Depois de muita solução de problemas, descobrimos que nodetool repairo problema foi resolvido. Não tivemos nenhuma exceção nos arquivos de log que nos levasse a entender que havia inconsistência ou corrupção de dados, portanto, só podemos assumir que foi esse o caso porque foi corrigido por um reparo. Também não houve falhas no hardware EC2 ou no sistema operacional que pudessem indicar problemas de disco. Como resultado, não temos uma causa raiz real e não sabemos como evitar que isso aconteça no futuro.
Um sintoma que notamos foi a seguinte mensagem de log que se repetia continuamente para aquele keyspace específico:
INFO [Native-Transport-Requests-1] 2023-07-04 11:53:15,913 MigrationManager.java:286 - Update Keyspace '[REDACTED]' From KeyspaceMetadata ......
Este sintoma desapareceu após o reparo.
Estamos nos perguntando se alguém tem informações sobre o que pode ter ocorrido e, posteriormente, como evitá-lo.
Pode ser interessante notar que não estávamos realizando reparos com frequência suficiente de acordo com as diretrizes. Fazíamos isso aproximadamente a cada três meses, mas a recomendação é igualar o gc_grace_secondsvalor que você está usando, que atualmente é de 10 dias.
Também pode ser importante saber que suspeitamos que havia um maior grau de carga no momento do incidente devido a um trabalho em lote que estávamos executando periodicamente, mas não vimos sinais de estresse nos nós do Cassandra.
O que significa que provavelmente se deve ao padrão de gravação de um aplicativo específico.
Tudo isso depende da consistência necessária. Se os dados não precisarem estar 100% corretos ou atualizados, os reparos provavelmente serão mais problemáticos do que valem a pena. Mas, se forem necessários níveis mais elevados de consistência, executar o reparo uma vez por semana geralmente é uma boa ideia. Isso pode ser configurado para ser facilmente gerenciado por algo como Cassandra Reaper .
Este é um grande indicador para mim. Mesmo que os nós não pareçam estar estressados, há vários motivos pelos quais a replicação pode falhar. A causa comum é o acúmulo de muita contrapressão de gravação, fazendo com que um ou mais nós descartem as gravações recebidas.
A inconsistência da rede também é uma grande causa, então isso também pode ser algo a ser observado.
Clusters multilocatários são problemáticos com Cassandra, porque dificultam encontrar as causas raiz (como você está vendo) e fazer qualquer coisa a respeito sem afetar outros aplicativos. Pode valer a pena separar este aplicativo do restante e fornecer a ele seu próprio cluster. Dessa forma, você poderia dimensionar os recursos para melhor se adequar aos seus padrões de gravação.
Eu também tentaria dar uma olhada no aplicativo ou trabalho em lote em execução no keyspace em questão. Se a taxa de transferência de gravação puder ser reduzida, isso deverá ajudar. Isso pode ser feito limitando os threads de gravação em andamento no código. A outra opção é fazer com que o trabalho em lote aponte para algo como um tópico Pulsar ou Kafka e, em seguida, crie um consumidor para ler o tópico e aplicar as gravações em Cassandra.
Verifique também o IO do disco em cada nó. Se estiver no limite, pode ser aí que está o gargalo. Nesse caso, isso poderia ser corrigido selecionando um tipo de unidade diferente para a instância.