ApsaraDB for MongoDB:Alta utilização de espaço em disco em instâncias do MongoDB

Arquitetura de replica set

Se sua instância do ApsaraDB for MongoDB utiliza uma arquitetura de replica set, faça login no console do ApsaraDB for MongoDB e use os métodos a seguir para verificar o uso de espaço:

• Visão geral

  Na página Basic Information, vá até a seção Specification Information para visualizar o Disk space e o Usage da instância.

• Análise de gráficos de monitoramento

  No painel de navegação à esquerda, clique em Monitoring Information. Selecione um nó de destino para visualizar seu Disk Usage (Bytes) e Disk Usage (%).

  Uma instância de replica set do ApsaraDB for MongoDB consiste em um nó primário para operações de leitura e gravação, um ou mais nós secundários para alta disponibilidade, um nó oculto e nós opcionais somente leitura. O uso de espaço de cada nó é composto por data_size e log_size, onde ins_size = data_size + log_size:

  • data_size: Espaço em disco usado pelos dados, excluindo o banco de dados local. Inclui arquivos de dados (com prefixo collection), arquivos de índice (com prefixo index) e arquivos de metadados como WiredTiger.wt.

  • log_size: Tamanho físico do banco de dados local, tamanho dos logs de runtime do MongoDB e tamanho de alguns logs de auditoria.

• Análise detalhada

  Use os métodos a seguir para analisar detalhadamente o uso de espaço:

  • Use os comandos nativos do MongoDB db.stats() e db.$collection_name.stats().

    Para obter mais informações sobre esses comandos, consulte a documentação do MongoDB a seguir:

    • db.stats()

    • db.collection.stats()

    • db.collection.storageSize()

    • db.collection.totalIndexSize()

    • db.collection.totalSize()

  • Acesse a página CloudDBA > Storage Analysis.

    Na página CloudDBA > Storage Analysis, visualize as seguintes informações:

    • Visão geral do uso de espaço para bancos de dados e coleções, crescimento médio diário e previsão de dias até que o armazenamento esteja cheio.

    • Uso de espaço de bancos de dados e tabelas anômalos.

    • Detalhamento do uso de espaço para coleções de negócios, incluindo tamanho de arquivos de índice e de dados, análise de taxa de compressão e tamanho médio de documentos.

Arquitetura de sharded cluster

Caso sua instância do ApsaraDB for MongoDB utilize uma arquitetura de sharded cluster, faça login no console do ApsaraDB for MongoDB e use os métodos abaixo para verificar o uso de espaço:

• Análise de gráficos de monitoramento

  Na página Monitoring Information, selecione um nó de destino para visualizar seu Disk Usage (Bytes) e Disk Usage (%).

• Análise detalhada

  Analise sequencialmente o uso de espaço de cada nó usando os comandos nativos do MongoDB db.stats() e db.$collection_name.stats().

Impacto na instância durante a compactação

A operação compact pode ser demorada, pois sua duração é proporcional ao tamanho da coleção. Para não afetar as operações de leitura e gravação, execute o compact fora dos horários de pico.

Método de compactação

Para minimizar o impacto nos seus negócios, execute primeiro o comando db.runCommand({compact:"collectionName"}) em um nó secundário e, em seguida, realize um failover primário/secundário. Substitua collectionName pelo nome da sua coleção.

Para mais detalhes sobre como usar o comando compact, consulte Defragment disks to improve disk utilization.

Lacuna de espaço causada por journal logs grandes

Em versões do ApsaraDB for MongoDB anteriores à 4.0, se o número de arquivos abertos na máquina host atingir o limite, o thread de limpeza do servidor de log interno será interrompido e o journal log crescerá indefinidamente. Caso encontre entradas de log semelhantes às mostradas abaixo nos logs de runtime do MongoDB, atualize o kernel para o ApsaraDB for MongoDB 4.0 ou superior. Como correção temporária, reinicie o processo mongod. Para mais detalhes, consulte log-server thread exit quietly on error while the mongodb process still running.

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.

Crescimento de logs devido a atraso de replicação e backups

Quando uma instância do ApsaraDB for MongoDB apresenta atraso de replicação, o tamanho utilizável do oplog deixa de ser limitado pela coleção de tamanho fixo definida no arquivo de configuração. Teoricamente, ele pode crescer até 20% da capacidade de disco provisionada. Após a resolução do atraso, o espaço extra ocupado pelo oplog não é recuperado automaticamente.

Durante um backup físico, uma instância do ApsaraDB for MongoDB em um nó oculto gera diversos checkpoints, consumindo mais espaço de dados e logs.

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

Tipo de shard key inadequado

Em um sharded cluster, a escolha do tipo de shard key é fundamental. Os dois tipos principais são hashed sharding e ranged sharding. Para balanceamento de disco, o hashed sharding costuma ser uma estratégia melhor que o ranged sharding, pois o ApsaraDB for MongoDB usa uma função de hash interna para distribuir os dados uniformemente entre os shards com base nos valores das chaves. Por outro lado, o ranged sharding distribui os dados com base em intervalos de valores de chave, o que pode concentrar novos dados em um chunk "quente", causando alto I/O de disco nesse shard e desequilíbrio de dados a curto prazo.

Campo de shard key inadequado

Embora o número de chunks em cada shard possa ser semelhante, a maior parte dos dados fica concentrada em poucos chunks. Consequentemente, os shards que contêm esses chunks "quentes" armazenam significativamente mais dados que os demais. Ao executar o comando sh.status() e verificar os logs de runtime do ApsaraDB for MongoDB, você poderá ver mensagens de aviso semelhantes às seguintes:

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" }

O balancer do mongos considera principalmente a contagem de chunks em cada shard para determinar se os dados estão equilibrados. Isso pode levar a um cenário em que a contagem de chunks está balanceada, mas a distribuição real dos dados está altamente distorcida. Esse comportamento ocorre porque os valores da shard key dentro de um chunk são quase idênticos. Quando o chunk atinge o limiar de divisão de 64 MB, o MongoDB o divide e cria um chunk vazio. Com o tempo, embora a contagem de chunks aumente e ocorram migrações, os chunks migrados costumam estar vazios — resultando em uma contagem de chunks equilibrada, mas com dados desbalanceados. Para corrigir isso, reprojetue sua estratégia de sharding para usar um campo de alta cardinalidade como shard key.

Bancos de dados sem sharding em um sharded cluster

Uma instância de sharded cluster do ApsaraDB for MongoDB suporta bancos de dados com e sem sharding. Todos os dados de um banco de dados sem sharding residem em um único shard primário; portanto, se esse banco de dados for grande, seu shard primário poderá armazenar significativamente mais dados que os outros shards.

Esse problema também pode ocorrer quando você importa dados de um cluster mongos de origem para um novo, mas negligencia a configuração do sharding no cluster de destino antes da importação.

Para resolver essas questões, recomendamos o seguinte:

• Ao inicializar um cluster de destino com uma importação, projete e ative o sharding antes de começar.

• Se houver muitos bancos de dados sem sharding com tamanhos aproximadamente iguais, use o comando movePrimary para mover bancos de dados específicos para shards diferentes.

• Caso exista um banco de dados muito grande sem sharding, recomenda-se habilitar o sharding nele ou migrá-lo para uma instância independente de replica set.

• Se essa situação ocorrer, mas houver espaço em disco suficiente, opte por ignorar o problema.

Uso desigual de disco devido a operações moveChunk

Uma operação moveChunk grava dados em um shard de destino e depois os remove do shard de origem. Por padrão, a operação de remoção não libera espaço em disco. No mecanismo WiredTiger, cada coleção possui arquivos de dados e de índice separados, e o espaço total em disco só diminui se esses arquivos forem excluídos. Esse problema é mais comum quando o sharding é ativado em um cluster que já está em execução há algum tempo sem um projeto de sharding prévio.

Portanto, após muitas operações moveChunk ou de remoção de documentos, execute uma operação compact no shard afetado para recuperar o espaço fragmentado.