Tarefas de manutenção do Apache Cassandra

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

Manutenção antientropia

Os nós de 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 este comando:

  • Executado em cada nó do Cassandra (em todas as regiões ou data centers).
  • Executa em um nó de cada vez, para garantir a consistência em todos os nós no anel. A execução de jobs de reparo em vários nós ao mesmo tempo pode prejudicar a integridade do Cassandra.

    Para verificar se um job de reparo em um nó foi concluído, procure no arquivo system.log dos nós uma entrada com o UUID da sessão de reparo mais recente e a frase "sessão concluída com êxito". Veja 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
  • Executada durante períodos de carga de trabalho relativamente baixa (a ferramenta impõe uma carga significativa ao sistema).
  • Faça isso pelo menos a cada sete dias para eliminar problemas relacionados às "exclusões esquecidas" do Cassandra.
  • Execute em diferentes nós em dias diferentes ou programe-o para que haja várias horas entre a execução em cada nó.
  • Use a opção -pr (intervalo do particionador) para especificar somente o intervalo do particionamento principal do nó.

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

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

Também é possível executar o seguinte comando para verificar as opções compatíveis do apigee_repair:

apigee-service apigee-cassandra apigee_repair -h

Observação: apigee_repair é um wrapper em torno do reparo do nodetool do Cassandra, que executa verificações adicionais antes do reparo do Cassandra.

Para saber mais, acesse os recursos a seguir:

Manutenção do arquivo de registros

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 20 MB. Quando esse limite for atingido, os registros mais antigos serão excluídos quando os mais novos forem criados.

Se você perceber que os arquivos de registros do Cassandra estão ocupando muito espaço, modifique a quantidade de espaço alocada para os arquivos de registros 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 o uso do disco do Cassandra regularmente para garantir que pelo menos 50% de cada disco esteja livre. Se a utilização do disco subir acima de 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 do token de autenticação quando os tokens expiram. No entanto, pode levar algumas semanas para liberar o espaço em disco que os tokens estavam usando, dependendo da sua configuração. Se a exclusão automática não for adequada para manter espaço em disco suficiente, entre em contato com o suporte para saber mais sobre a exclusão manual de tokens para recuperar espaço.
  • Compactação de dados. Recomendamos alterar a estratégia de compactação em keyspaces para LeveledCompactionStrategy, que oferece melhores estratégias de utilização de disco do que o padrão SizeTieredCompactionStrategy. Consulte Estratégia de compactação em níveis.

Observação:quando o Cassandra executa compactações de dados, ele pode precisar de uma quantidade considerável de ciclos de CPU e de memória. Mas a utilização de recursos deve voltar ao normal quando as compactações forem concluídas. É possível executar 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.