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.
- 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
- 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.