Em geral, um cluster bem projetado pode viver por ANOS sem ser tocado. Eu tive clusters que funcionavam há anos sem interrupção. No entanto, aqui estão algumas diretrizes:
O monitoramento é extremamente importante:
1) Monitorar latências. Use o opscenter ou suas ferramentas de métricas favoritas para acompanhar as latências. As latências em ascensão podem ser sinais de problemas, incluindo pausas no GC (mais comuns em cargas de trabalho de leitura do que cargas de trabalho de gravação), problemas estáveis e similares.
2) Monitore contagens estáveis. As contagens de SSTable aumentarão se você exceder a compactação (cada sstable é gravado exatamente uma vez - as exclusões são tratadas combinando sstables antigos em novos sstables por meio da compactação).
3) Monitore as alterações de estado do nó (para cima / para baixo, etc). Se você vir nós batendo, investigue, pois isso não é normal.
4) Acompanhe o uso do seu disco - tradicionalmente, você precisa ficar abaixo de 50% (especialmente se você usar a compactação STCS).
Existem algumas coisas básicas que você deve e não deve fazer regularmente:
1) Não execute explicitamente nodetool compact. Você mencionou que fez isso, não é fatal, mas cria sstables muito grandes, que são menos propensos a participar da compactação no futuro. Você não precisa necessariamente continuar executando, mas às vezes pode ajudar a se livrar dos dados excluídos / substituídos.
2) nodetool repairé normalmente recomendado a cada gc_grace_seconds10 dias, por padrão. Existem cargas de trabalho em que isso é menos importante - a maior razão pela qual você PRECISA reparar é garantir que os marcadores de exclusão ( tombstones) sejam transmitidos antes de expirarem (eles permanecem vivos gc_grace_seconds, se um nó estiver inativo quando a exclusão aconteceu, esses dados poderão voltar à vida útil) sem o reparo!). Se você não emitir exclusões e consultar com nível de consistência suficiente (leituras e gravações no QUORUM, por exemplo), poderá realmente viver uma vida sem reparo.
3) Se você for reparar, considere o uso de reparo incremental e repare pequenos intervalos de cada vez.
4) Estratégias de compactação são importantes - muito. O STCS é ótimo para gravações, o LCS é ótimo para leituras. O DTCS tem algumas peculiaridades.
5) Os modelos de dados são importantes - assim como os ambientes RDBMS / SQL enfrentam problemas quando consultas não indexadas atingem tabelas grandes, o Cassandra pode ser problemático com linhas / partições muito grandes.
6) Instantâneos são baratos. Muito barato. Quase instantaneamente, apenas links físicos, eles custam quase nenhum espaço em disco imediatamente. Use o instantâneo antes de atualizar as versões, especialmente as principais.
7) Tenha cuidado com exclusões. Como sugerido no item 2, delete cria mais dados no disco e não o libera pelo menos gc_grace_seconds.
Quando tudo falha:
Vi artigos que sugerem que o Cassandra in prod requer um chefe dedicado para gerenciar qualquer cluster de tamanho - não sei se é necessariamente verdade, mas se você estiver preocupado, convém contratar um consultor de terceiros (TheLastPickle, Pythian ) ou tenha um contrato de suporte (Datastax) para lhe dar um pouco de tranquilidade.