ApsaraDB for MongoDB:Solucionar problemas de alta utilização de disco em uma instância

ins_size = data_size + log_size

db.runCommand({compact: "<collectionName>"})

Journals crescendo sem limite (MongoDB anterior à versão 4,0)

Em versões do MongoDB anteriores à 4,0, se o número de arquivos abertos no host atingir o limite do sistema, as threads de limpeza no servidor de log do MongoDB encerram silenciosamente. Consequentemente, os arquivos de journal crescem sem limite.

Procure entradas semelhantes às seguintes nos logs de tempo de execução da instância:

2019-08-25T09:45:16.867+0800 I NETWORK [thread1] Listener: accept() returns -1 Too many open files in system
2019-08-25T09:45:17.000+0800 I - [ftdc] Assertion: 13538:couldn't open [/proc/55692/stat] Too many open files in system src/mongo/util/processinfo_linux.cpp 74
2019-08-25T09:45:17.002+0800 W FTDC [ftdc] Uncaught exception in 'Location13538: couldn't open [/proc/55692/stat] Too many open files in system' in full-time diagnostic data capture subsystem. Shutting down the full-time diagnostic data capture subsystem.

Resolver

Atualize o MongoDB para a versão 4,0 ou posterior. Como medida temporária, reinicie o processo mongod. Consulte o relatório de bug upstream: WT-4083.

Verificar

Após a atualização ou reinicialização, confirme se os arquivos de journal pararam de crescer verificando Disk Usage (Bytes) em Monitoring Data durante uma janela de 10 a 15 minutos.

Oplog consumindo espaço crescente após atraso de replicação ou backup físico

Dois cenários fazem com que o espaço do oplog expanda e não diminua automaticamente:

• Atraso de replicação: Quando os nós secundários ficam atrasados, o espaço disponível do oplog deixa de ser limitado pelo tamanho fixo da coleção no arquivo de configuração. Ele pode chegar a 20% do espaço em disco provisionado para a instância. Após a resolução do atraso, o espaço físico não é liberado automaticamente.

• Backup físico em um nó oculto: Um grande número de checkpoints é gerado durante o backup, produzindo um volume substancial de dados de log.

Resolver

Execute o compact na coleção oplog:

db.grantRolesToUser("root", [{db: "local", role: "dbAdmin"}])
use local
db.runCommand({ compact: "oplog.rs", force: true })

Verificar

Após a operação, verifique Disk Usage (Bytes) em Monitoring Data para confirmar se o espaço de log diminuiu no nó afetado.

Escolha inadequada de chave de shard: baixa cardinalidade

Se a maioria dos dados concentrar-se em um pequeno número de chunks — enquanto a contagem de chunks entre os shards permanece equilibrada — a causa raiz é uma chave de shard de baixa cardinalidade.

Quando uma chave de shard possui poucos valores distintos, o balanceador consegue dividir e migrar chunks, mas não consegue dividir um chunk cujos documentos compartilham o mesmo valor de chave. O resultado é uma contagem de chunks aparentemente equilibrada, mas com tamanhos de dados altamente desproporcionais.

Procure avisos na saída de sh.status():

2019-08-27T13:31:22.076+0800 W SHARDING [conn12681919] possible low cardinality key detected in superHotItemPool.haodanku_all - key is { batch: "201908260000" }
2019-08-27T13:31:22.076+0800 W SHARDING [conn12681919] possible low cardinality key detected in superHotItemPool.haodanku_all - key is { batch: "201908260200" }
2019-08-27T13:31:22.076+0800 W SHARDING [conn12681919] possible low cardinality key detected in superHotItemPool.haodanku_all - key is { batch: "201908260230" }

Resolver

Redesenhe a chave de shard usando um campo de alta cardinalidade. Considere o sharding com hash, que distribui os dados uniformemente aplicando uma função de hash aos valores da chave de shard. O sharding por intervalo distribui os dados por faixa de valor, o que tende a concentrar as gravações em um único chunk. Consulte conceitos de chave de shard, sharding com hash e sharding por intervalo.

Quando um chunk atinge 64 MB, o MongoDB cria um novo chunk vazio para que a migração possa continuar. Se os chunks estiverem equilibrados, mas os tamanhos dos dados diferirem muito entre os shards, uma chave de shard de baixa cardinalidade é a causa provável.

Bancos de dados não fragmentados criando um shard jumbo

Os dados de um banco de dados não fragmentado residem inteiramente em um único shard. Se esse banco de dados for grande, um shard acabará retendo significativamente mais dados do que os outros. A mesma situação pode ocorrer ao importar dados para uma instância de cluster fragmentado que não estava fragmentada antes da importação.

Resolver

Escolha a ação apropriada conforme a sua situação:

Para mais informações sobre como os chunks são particionados e divididos, consulte Particionamento de dados com chunks e Dividir chunks em um cluster fragmentado.

Fragmentação de disco devido a operações moveChunk

Ao migrar um chunk, o balanceador remove os documentos de origem após gravá-los no destino. Por padrão, essa remoção não libera o espaço físico em disco — os arquivos de dados e de índice do mecanismo WiredTiger retêm o espaço até que ele seja explicitamente recuperado. Isso é comum quando se adiciona sharding a uma instância em execução há algum tempo.

Resolver

Execute o compact em cada shard afetado para recuperar o espaço fragmentado:

db.runCommand({compact: "<collectionName>"})

Consulte Migrar intervalos em um cluster fragmentado e Gerenciar o balanceador de cluster fragmentado para obter contexto sobre o comportamento do moveChunk.

Verificar

Após a conclusão do compact em cada shard, compare os valores de Disk Usage (Bytes) entre os shards em Monitoring Data para confirmar se a distribuição está mais uniforme.