Tarefas de manutenção do Apache Cassandra

Esta seção descreve as tarefas de manutenção periódica 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 esse comando:

  • Execute em todos os nós do Cassandra (em todas as regiões ou data centers).
  • Execute em um nó por 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". 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.
  • Executar em nós diferentes em dias diferentes ou programar para que haja várias horas entre as execuções 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 comando a seguir para verificar as opções compatíveis de apigee_repair:.

apigee-service apigee-cassandra apigee_repair -h

Observação:apigee_repair é um wrapper do reparo de nodetool do Cassandra, que realiza verificações adicionais 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/apigee-cassandra em cada nó. Por padrão, é possível criar até 50 arquivos de registro, cada um com um tamanho máximo de 20 MB. Quando esse limite é atingido, os registros mais antigos são excluídos quando novos são criados.

Se você perceber que os arquivos de registro do Cassandra estão ocupando espaço excessivo, modifique a quantidade de espaço alocado para arquivos de registro editando as configurações do Log4j.

  1. Edite /opt/apigee/customer/application/cassandra.properties para definir as seguintes propriedades. 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 a utilização do disco aumentar 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 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 adequada para manter espaço suficiente em disco, entre em contato com o suporte para saber como excluir tokens manualmente para recuperar espaço.
  • Observação sobre compactação de dados: a partir do Edge for Private Cloud 4.51.00, novas instalações do Apigee Cassandra vão criar espaços de chave com a estratégia de compactação em níveis.

    Instalações de versões mais antigas do Edge para nuvem privada que foram atualizadas para 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 usar uma quantidade considerável de ciclos de CPU e memória. No entanto, a utilização de recursos volta ao normal quando as compactações são 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 a conclusão.