Tarefas de manutenção do Apache Cassandra

Esta seção descreve as tarefas periódicas de manutenção do Cassandra.

Manutenção antientropia

Os nós de anel do Apache Cassandra requerem manutenção periódica para assegurar consistência em todos nós. Para realizar esta manutenção, use o seguinte comando:

apigee-service apigee-cassandra apigee_repair -pr

A Apigee recomenda o seguinte ao executar este comando:

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

    Para verificar se um trabalho de reparo em um nó foi concluído com êxito, procure no arquivo Arquivo system.log de uma entrada com o UUID da sessão de reparo mais recente e a frase "sessão concluída". Este é 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 sobre o sistema.
  • Executar pelo menos a cada sete dias para eliminar problemas relacionados à operação do Cassandra "exclusões esquecidas".
  • Execute em nós diferentes, em dias diferentes, ou programe-o para que haja várias horas entre a execução dele em cada nó.
  • Use a opção -pr (intervalo do particionamento) para especificar o intervalo do particionamento principal. apenas do nó.

Se você ativou a autenticação JMX para o Cassandra, é necessário 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 de apigee_repair:

apigee-service apigee-cassandra apigee_repair -h

Observação:apigee_repair é um wrapper para o reparo de ferramenta de nó do Cassandra. que realiza outras verificações 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 na cada nó. Por padrão, podem ser gerados no máximo 50 arquivos de registro, cada um com tamanho máximo de 20 MB. criado; Quando esse limite é atingido, os registros mais antigos são excluídos junto com a criação de registros mais recentes.

Se você perceber que os arquivos de registro do Cassandra estão ocupando muito espaço, poderá modificar quantidade de espaço alocada para arquivos de registro editando as configurações do log4j.

  1. Editar /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 com o seguinte comando:
    /opt/apigee/apigee-service/bin/apigee-service apigee-cassandra restart

Manutenção de espaço em disco

Monitore o uso do disco do Cassandra regularmente para garantir pelo menos 50% cada disco fica livre. Se a utilização do disco subir acima de 50%, recomendamos que você adicionar mais espaço em disco para reduzir a porcentagem que está em uso.

O Cassandra executa automaticamente as seguintes operações para reduzir a própria utilização de 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 configuração do Terraform. Se a exclusão automática não for adequada espaço em disco suficiente, entre em contato com o suporte para saber como excluir tokens manualmente para recuperá-los espaço.
  • Observação sobre compactação de dados: a partir do Edge para a nuvem privada 4.51.00, as novas instalações do O Apigee Cassandra criará keyspaces com a Estratégia de compactação em nível.

    Instalações de versões mais antigas do Edge para nuvem privada que foram atualizadas para A nuvem privada 4.51.00 vai continuar mantendo a estratégia de compactação anterior. Se o modelo de compactação de classe é sizeTieredCompactionStrategy, recomendamos mudar para LeveledCompactionStrategy, que oferece melhor utilização do disco.

Observação: quando o Cassandra executa compactações de dados, pode ser necessário uma quantidade considerável de ciclos de CPU e memória. No entanto, a utilização dos recursos vai voltar ao normal depois que 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á há compactações pendentes a serem executadas e o tempo estimado para conclusão.