ApsaraDB for MongoDB:Comment vérifier la progression de l'ajout ou de la suppression de nœuds shard

Pour les versions MongoDB antérieures à 6,0

Avant d'estimer la progression de la tâche, obtenez les statistiques d'exécution du Balancer (nombre de succès et d'échecs) ainsi que les informations sur les chunks des collections fragmentées en attente de migration.

Vous pouvez obtenir les résultats d'exécution du Balancer et les informations sur les chunks des tables fragmentées en attente de migration à l'aide des deux méthodes suivantes :

• Méthode 1 : Utilisez la sortie de la commande sh.status().

  Concentrez-vous sur deux parties de la sortie de sh.status(). La première partie affiche les résultats récents du Balancer, comme dans cet exemple.

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

  La seconde partie présente les détails des chunks pour les collections fragmentées, comme illustré ci-dessous.

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

  Dans cet exemple, « d-xxxxxxxxxxxxxxx5 » correspond au nœud shard nouvellement ajouté. Vous pouvez également exécuter la commande getShardDistribution dans la base de données contenant la collection fragmentée pour obtenir les détails de la distribution des chunks, comme indiqué ci-dessous.

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

• Méthode 2 : Lisez directement les données pertinentes depuis la base de données config.

  Consultez les statistiques des chunks agrégées par shard comme suit.

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

  Pour afficher les chunks sur un shard spécifique regroupés par namespace, exécutez la commande suivante.

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

  Pour compter les chunks migrés avec succès vers un nœud shard spécifique au cours des dernières 24 heures, exécutez la commande suivante.

  // 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()

Pour les versions MongoDB 6.0 et ultérieures

Avant d'estimer la progression de la tâche, concentrez-vous sur la distribution des données entre les shards. Vous pouvez toujours utiliser la sortie de sh.status() comme référence, mais déplacez votre attention du nombre inégal de chunks vers la distribution réelle du volume de données.

• Obtenez la distribution des collections fragmentées et les informations sur l'équilibre des données.

  Utilisez la commande getShardDistribution pour obtenir les détails de la distribution et vous concentrer sur l'équilibre des données. Exemple :

  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

  Vous pouvez également exécuter la commande suivante pour obtenir des informations de distribution plus détaillées (incluant le nombre de documents, la taille totale, le nombre de documents orphelins et la taille des orphelins) :

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

  La sortie d'exemple suivante met en évidence un déséquilibre notable des données entre les 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
                  }
            ]
  }

  À partir de cette sortie, vous pouvez déterminer que l'instance dispose de 4 nœuds shard et que le volume total de données pour la collection fragmentée <db>.<collection> est d'environ 2 051 303 530 231 octets (833 101 815 840 + 409 714 745 937 + 178 157 177 704 + 630 329 790 750 = 2 051 303 530 231), soit environ 1 910,4 Go.

• Consultez le volume de données migré avec succès au cours de la journée écoulée.

  Exécutez la requête suivante :

  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)

  Exemple de sortie :

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

  Cette sortie indique que le 2024-09-21, 183 117 965 820 octets (environ 170,5 Go) ont été migrés.

Pour les versions MongoDB antérieures à 6,0

Après avoir obtenu le nombre de chunks migrés avec succès et la distribution actuelle des données, estimez la progression globale de la tâche et le délai d'achèvement prévu.

Supposons les conditions idéales suivantes lors de l'ajout d'un shard : le nombre total de chunks reste constant, le nombre de shards reste fixe (pas d'ajouts ou suppressions de shards concurrents), la charge de service reste stable et les paramètres du Balancer utilisent les valeurs par défaut. En utilisant l'exemple de l'Étape 3 sous Pour les versions MongoDB antérieures à 6,0, vous savez que :

• Il y a 5 nœuds shard.

• 300 chunks ont été migrés avec succès durant la fenêtre du Balancer.

• La collection fragmentée <db>.<collection> compte 58 260 chunks au total (13 630 + 13 629 + 13 652 + 13 630 + 3 719 = 58 260).

Par conséquent, les calculs suivants peuvent être effectués :

• À l'équilibre, chaque shard devrait contenir 11 652 chunks (58 260 ÷ 5 = 11 652).

• Au rythme actuel de migration, l'achèvement de la tâche nécessite encore 26,4 jours ((11 652 – 3 719) ÷ 300 ≈ 26,4).

• La tâche d'ajout de shard est achevée à 32 % (3 719 ÷ 11 652 = 32 %).

Pour les versions MongoDB 6.0 et ultérieures

Supposons que l'instance de cluster fragmenté ne possède qu'une seule collection nécessitant un équilibrage. En utilisant l'exemple de l'Étape 3 sous Pour les versions MongoDB 6.0 et ultérieures, vous savez que :

• Il y a 4 nœuds shard.

• Le 2024-09-21, environ 170,5 Go (183 117 965 820 octets) ont été migrés.

• La collection fragmentée <db>.<collection> a un volume total de données d'environ 1 910,4 Go (2 051 303 530 231 octets).

Par conséquent, les calculs suivants peuvent être effectués :

• À l'équilibre, chaque shard devrait contenir environ 477,6 Go (512 825 882 557,75 octets).

• Le volume total de données devant être migré pour atteindre l'équilibre est de 875 559 682 949 octets (815,4 Go), réparti comme suit :

  Shard1 doit migrer 320 275 933 282,25 octets (833 101 815 840 – 512 825 882 557,75).

  Shard2 doit migrer 103 111 136 620,75 octets (409 714 745 937 – 512 825 882 557,75).

  Shard3 doit migrer 334 668 704 853,75 octets (178 157 177 704 – 512 825 882 557,75).

  Shard4 doit migrer 117 503 908 192,25 octets (630 329 790 750 – 512 825 882 557,75).

  (320 275 933 282,25 + 103 111 136 620,75 + 334 668 704 853,75 + 117 503 908 192,25 = 875 559 682 949)

• Au rythme actuel de migration, l'équilibre sera atteint dans environ 4,8 jours (815,4 Go ÷ 170,5 Go/jour ≈ 4,8 jours).