Tarefas de manutenção do Apache Cassandra

Nesta seção, descrevemos as tarefas de manutenção periódica do Cassandra.

Manutenção antientropia

Os nós do anel do Apache Cassandra exigem manutenção periódica para garantir a consistência em todos os nós. Para realizar essa manutenção, use o seguinte comando:

apigee-service apigee-cassandra apigee_repair -pr

A Apigee recomenda o seguinte ao executar esse comando:

  • Execute em cada nó do Cassandra (em todas as regiões ou data centers).

  • Para verificar se um job de reparo em um nó foi concluído, procure no arquivo system.log do nó uma entrada com o UUID da sessão de reparo mais recente e a frase "sessão concluída". Confira um exemplo de entrada de registro:

    INFO [AntiEntropySessions:1] 2015-03-01 10:02:56,245 RepairSession.java (line 282) [repair #2e7009b0-c03d-11e4-9012-99a64119c9d8] session completed successfully"
Ref: https://support.datastax.com/hc/en-us/articles/204226329-How-to-check-if-a-scheduled-nodetool-repair-ran-successfully
  • Execute durante períodos de carga de trabalho relativamente baixa (a ferramenta impõe uma carga significativa ao sistema).
  • Execute pelo menos a cada sete dias para eliminar problemas relacionados às "exclusões esquecidas" do Cassandra.
  • Execute em nós diferentes em dias diferentes ou programe para que haja várias horas entre a execução em cada nó.
  • Use a opção -pr (intervalo do particionador) para especificar apenas o intervalo do particionador principal do nó.

Se você ativou a autenticação JMX para o Cassandra, inclua o nome de usuário e a senha ao invocar nodetool. Exemplo:

apigee-service apigee-cassandra apigee_repair -u username -pw password -pr

Você também pode executar o seguinte comando para verificar as opções compatíveis de apigee_repair::

apigee-service apigee-cassandra apigee_repair -h

Observação:apigee_repair é um wrapper em torno do reparo do nodetool do Cassandra, que realiza verificações extras antes de executar o reparo do Cassandra.

Para saber mais, acesse os recursos a seguir:

Manutenção de arquivos de registro

Os registros do Cassandra são armazenados no diretório /opt/apigee/var/log/cassandra em cada nó. Por padrão, é possível criar no máximo 50 arquivos de registro, cada um com tamanho máximo de 20 MB. Quando esse limite é atingido, os registros mais antigos são excluídos à medida que novos são criados.

Se você descobrir que os arquivos de registro do Cassandra estão ocupando muito espaço, modifique a quantidade de espaço alocada para eles editando as configurações do log4j.

  1. Edite /opt/apigee/customer/application/cassandra.properties para definir as propriedades a seguir. Se esse arquivo não existir, crie-o: 
    conf_logback_maxfilesize=20MB
# max file size
conf_logback_maxbackupindex=50 # max open files
  2. Reinicie o Cassandra usando o seguinte comando: 
    /opt/apigee/apigee-service/bin/apigee-service apigee-cassandra restart

Manutenção do espaço em disco

Monitore a utilização do disco do Cassandra regularmente para garantir que pelo menos 50% de cada disco esteja livre. Se o uso do disco ultrapassar 50%, recomendamos que você adicione mais espaço em disco para reduzir a porcentagem em uso.

O Cassandra executa automaticamente as seguintes operações para reduzir a própria utilização do disco:

  • Exclusão de tokens de autenticação quando eles expiram. No entanto, pode levar algumas semanas para liberar o espaço em disco que os tokens estavam usando, dependendo da configuração. Se a exclusão automática não for suficiente para manter espaço em disco suficiente, entre em contato com o suporte para Aprenda Mais sobre como excluir tokens manualmente para recuperar espaço.

  • Observação sobre a compactação de dados: a partir do Edge para nuvem privada 4.51.00, as novas instalações da Apigee Cassandra vão criar keyspaces com a estratégia de compactação nivelada.

    As instalações de versões mais antigas do Edge para nuvem privada que foram atualizadas para a nuvem privada 4.51.00 vão continuar mantendo a estratégia de compactação anterior. Se a estratégia de compactação atual for SizeTieredCompactionStrategy, recomendamos mudar para LeveledCompactionStrategy, que oferece melhor utilização do disco.

Observação:quando o Cassandra realiza compactações de dados, ele pode consumir uma quantidade considerável de ciclos de CPU e memória. No entanto, a utilização de recursos deve voltar ao normal quando as compactações forem concluídas. Execute o comando 'Nodetool compactionstats' em cada nó para verificar se a compactação está em execução. A saída de compactionstats informa se há compactações pendentes a serem executadas e o tempo estimado para conclusão.