ApsaraDB for MongoDB:Como verificar o progresso de adição ou remoção de nós shard

Para versões do MongoDB anteriores à 6,0

Antes de estimar o progresso da tarefa, obtenha estatísticas de execução do Balancer (contagens de sucesso e falha) e informações sobre chunks de coleções com sharding pendentes de migração.

Obtenha os resultados de execução do Balancer e informações sobre chunks de tabelas com sharding pendentes de migração usando os dois métodos a seguir:

• Método 1: Utilize a saída do comando sh.status().

  Concentre-se em duas partes da saída do sh.status(). A primeira parte mostra os resultados recentes do Balancer, conforme este exemplo.

  ...
    balancer:
          Collections with active migrations: 
                  <db>.<collection> started at Wed Sep 27 2023 10:25:21 GMT+0800 (CST)
          Failed balancer rounds in last 5 attempts:  0
          Migration Results for the last 24 hours: 
                  300 : Success
    databases:
  ...

  A segunda parte exibe detalhes dos chunks para coleções com sharding, como neste exemplo.

  ...
  databases:
  ...
      {  "_id" : "<db>",  "primary" : "d-xxxxxxxxxxxxxxx3",  "partitioned" : true,  "version" : {  "uuid" : UUID("3409a337-c370-4425-ad72-8b8c6b0abd52"),  "lastMod" : 1 } }
            <db>.<collection>
                          shard key: { "<shard_key>" : "hashed" }
                          unique: false
                          balancing: true
                          chunks:
                                  d-xxxxxxxxxxxxxxx1      13630
                                  d-xxxxxxxxxxxxxxx2      13629
                                  d-xxxxxxxxxxxxxxx3      13652
                                  d-xxxxxxxxxxxxxxx4      13630
                                  d-xxxxxxxxxxxxxxx5      3719
                          too many chunks to print, use verbose if you want to force print
  ...

  Neste exemplo, “d-xxxxxxxxxxxxxxx5” é o nó shard recém-adicionado. Também é possível executar o comando getShardDistribution no banco de dados que contém a coleção com sharding para obter detalhes da distribuição de chunks, conforme mostrado abaixo.

  use <db>
  db.<collection>.getShardDistribution()

• Método 2: Leia os dados relevantes diretamente do banco de dados config.

  Visualize estatísticas de chunks agregadas por shard da seguinte forma.

  db.getSiblingDB("config").chunks.aggregate([{$group: {_id: "$shard", count: {$sum: 1}}}])

  Para visualizar chunks em um shard específico agrupados por namespace, execute o comando a seguir.

  db.getSiblingDB("config").chunks.aggregate([{$match: {shard: "d-xxxxxxxxxxxxxx"}},{$group: {_id: "$ns", count: {$sum: 1}}}])

  Para contar chunks migrados com sucesso para um nó shard específico nas últimas 24 horas, execute o comando abaixo.

  // details.to specifies the destination shard for chunk migration
  // Use ISODate to define the time range in the time field
  db.getSiblingDB("config").changelog.find({"what" : "moveChunk.commit", "details.to" : "d-xxxxxxxxxxxxx","time" : {"$gte": ISODate("2023-09-26T00:00:00")}}).count()

Para versões do MongoDB 6.0 e posteriores

Antes de estimar o progresso da tarefa, concentre-se na distribuição de dados entre os shards. Ainda é possível usar a saída do sh.status() como referência, mas mude o foco da contagem desigual de chunks para a distribuição real do volume de dados.

• Obtenha informações sobre a distribuição de coleções com sharding e o equilíbrio de dados.

  Use o comando getShardDistribution para obter detalhes da distribuição e focar no equilíbrio dos dados. Exemplo:

  mongos> db.xxx.getShardDistribution()
  Shard d-xxx at xxx
   data : 379.26MiB docs : 8277367 chunks : 1
   estimated data per chunk : 379.26MiB
   estimated docs per chunk : 8277367
  Shard d-xxx at xxx
   data : 379.11MiB docs : 8272852 chunks : 1
   estimated data per chunk : 379.11MiB
   estimated docs per chunk : 8272852
  Shard d-xxx at xxx
   data : 379.18MiB docs : 8275108 chunks : 1
   estimated data per chunk : 379.18MiB
   estimated docs per chunk : 8275108
  Totals
   data : 1.11GiB docs : 24825327 chunks : 3
   Shard d-xxx contains 33.34% data, 33.34% docs in cluster, avg obj size on shard : 48B
   Shard d-xxx contains 33.32% data, 33.32% docs in cluster, avg obj size on shard : 48B
   Shard d-xxx contains 33.33% data, 33.33% docs in cluster, avg obj size on shard : 48B

  Também é possível executar o comando a seguir para obter informações de distribuição mais detalhadas (incluindo contagem de documentos, tamanho total, contagem de documentos órfãos e tamanho dos órfãos):

  db.getSiblingDB("admin").aggregate( [{ $shardedDataDistribution: { } },{ $match: { "ns": "<db>.<collection>" } }] ).pretty()

  A saída de exemplo a seguir mostra um desequilíbrio notável de dados entre os shards.

  {
          "ns" : "<db>.<collection>",
          "shards" : [
                  {
                          "shardName" : "d-xxxxxxxxxxxxxxx1",
                          "numOrphanedDocs" : 0,
                          "numOwnedDocuments" : 504298920,
                          "ownedSizeBytes" : NumberLong("833101815840"),
                          "orphanedSizeBytes" : 0
                  },
                  {
                          "shardName" : "d-xxxxxxxxxxxxxxx2",
                          "numOrphanedDocs" : 0,
                          "numOwnedDocuments" : 250283901,
                          "ownedSizeBytes" : NumberLong("409714745937"),
                          "orphanedSizeBytes" : 0
                  },
                  {
                          "shardName" : "d-xxxxxxxxxxxxxxx3",
                          "numOrphanedDocs" : 0,
                          "numOwnedDocuments" : 109098088,
                          "ownedSizeBytes" : NumberLong("178157177704"),
                          "orphanedSizeBytes" : 0
                  },
                  {
                          "shardName" : "d-xxxxxxxxxxxxxxx4",
                          "numOrphanedDocs" : 0,
                          "numOwnedDocuments" : 382018055,
                          "ownedSizeBytes" : NumberLong("630329790750"),
                          "orphanedSizeBytes" : 0
                  }
            ]
  }

  Com base nessa saída, é possível determinar que a instância possui 4 nós shard e o volume total de dados da coleção com sharding <db>.<collection> é de aproximadamente 2051303530231 bytes (833101815840 + 409714745937 + 178157177704 + 630329790750 = 2051303530231), ou cerca de 1910,4 GB.

• Visualize o volume de dados migrado com sucesso no último dia.

  Execute a consulta a seguir:

  pipeline = [
      { '$match': {
          'what': 'moveChunk.commit',
      } },
      { '$group': {
          '_id': {
              'date': { '$dateToString': { 'format': '%Y-%m-%d', 'date': '$time'} },
           },
          'chunks_moved': { '$sum': 1 },
          'docs_moved': { '$sum': '$details.counts.cloned' },
          'bytes_moved': { '$sum': '$details.counts.clonedBytes' },
      } }, 
      { '$sort': { '_id.date': -1} },
  ]
  db.getSiblingDB("config").changelog.aggregate(pipeline)

  Exemplo de saída:

  mongos> db.getSiblingDB("config").changelog.aggregate(pipeline)
  { "_id" : { "date" : "2024-09-24" }, "chunks_moved" : 91, "docs_moved" : NumberLong(33071040), "bytes_moved" : NumberLong("11532786734") }
  { "_id" : { "date" : "2024-09-23" }, "chunks_moved" : 294, "docs_moved" : NumberLong(109806635), "bytes_moved" : NumberLong("38294757573") }
  { "_id" : { "date" : "2024-09-22" }, "chunks_moved" : 737, "docs_moved" : NumberLong(266800041), "bytes_moved" : NumberLong("93047288531") }
  { "_id" : { "date" : "2024-09-21" }, "chunks_moved" : 1448, "docs_moved" : NumberLong(525308393), "bytes_moved" : NumberLong("183117965820") }
  { "_id" : { "date" : "2024-09-20" }, "chunks_moved" : 1459, "docs_moved" : NumberLong(530020503), "bytes_moved" : NumberLong("184390749022") }
  { "_id" : { "date" : "2024-09-19" }, "chunks_moved" : 1478, "docs_moved" : NumberLong(557833705), "bytes_moved" : NumberLong("186910196651") }
  { "_id" : { "date" : "2024-09-18" }, "chunks_moved" : 1360, "docs_moved" : NumberLong(508484825), "bytes_moved" : NumberLong("173486932689") }

  Essa saída indica que em 2024-09-21, foram migrados 183117965820 bytes (cerca de 170,5 GB).

Para versões do MongoDB anteriores à 6,0

Após obter o número de chunks migrados com sucesso e a distribuição atual de dados, estime o progresso geral da tarefa e o tempo esperado para conclusão.

Considere as seguintes condições ideais durante a adição de shards: a contagem total de chunks permanece constante, a quantidade de shards é fixa (sem adições ou remoções simultâneas), a carga do serviço mantém-se estável e os parâmetros do Balancer usam valores padrão. Usando o exemplo de Step 3 em Para versões do MongoDB anteriores à 6,0, sabe-se que:

• Existem 5 nós shard.

• 300 chunks foram migrados com sucesso durante a janela do Balancer.

• A coleção com sharding <db>.<collection> possui 58260 chunks no total (13630 + 13629 + 13652 + 13630 + 3719 = 58260).

Portanto, é possível calcular o seguinte:

• Em equilíbrio, cada shard deve conter 11652 chunks (58260 ÷ 5 = 11652).

• Na taxa atual de migração, a conclusão da tarefa requer mais 26,4 dias ((11652 – 3719) ÷ 300 ≈ 26,4).

• A tarefa de adição de shard está 32% concluída (3719 ÷ 11652 = 32%).

Para versões do MongoDB 6.0 e posteriores

Suponha que a instância de cluster com sharding tenha apenas uma coleção que precise de balanceamento. Usando o exemplo de Step 3 em Para versões do MongoDB 6.0 e posteriores, sabe-se que:

• Existem 4 nós shard.

• Em 2024-09-21, aproximadamente 170,5 GB (183117965820 bytes) foram migrados.

• A coleção com sharding <db>.<collection> tem um volume total de dados de cerca de 1910,4 GB (2051303530231 bytes).

Assim, pode-se calcular o seguinte:

• Em equilíbrio, cada shard deve conter aproximadamente 477,6 GB (512825882557,75 bytes).

• O volume total de dados que precisa ser migrado para atingir o equilíbrio é de 875559682949 bytes (815,4 GB), detalhado da seguinte forma:

  O Shard1 precisa migrar 320275933282,25 bytes (833101815840 – 512825882557,75).

  O Shard2 precisa migrar 103111136620,75 bytes (409714745937 – 512825882557,75).

  O Shard3 precisa migrar 334668704853,75 bytes (178157177704 – 512825882557,75).

  O Shard4 precisa migrar 117503908192,25 bytes (630329790750 – 512825882557,75).

  (320275933282,25 + 103111136620,75 + 334668704853,75 + 117503908192,25 = 875559682949)

• Na taxa atual de migração, o equilíbrio será atingido em cerca de 4,8 dias (815,4 GB ÷ 170,5 GB/dia ≈ 4,8 dias).