ApsaraDB for MongoDB:Cómo consultar el progreso de la adición o eliminación de nodos shard

Para versiones de MongoDB anteriores a la 6.0

Antes de estimar el progreso de la tarea, obtenga estadísticas de ejecución del Balancer (recuentos de éxitos y fallos) e información de chunks para las colecciones fragmentadas pendientes de migración.

Puede obtener los resultados de ejecución del Balancer y la información sobre los chunks de las tablas fragmentadas pendientes de migración mediante los dos métodos siguientes:

• Método 1: Utilice la salida del comando sh.status().

  Céntrese en dos partes de la salida de sh.status(). La primera parte muestra los resultados recientes del Balancer, como en este ejemplo.

  ...
    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 segunda parte muestra detalles de los chunks para las colecciones fragmentadas, como en este ejemplo.

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

  En este ejemplo, “d-xxxxxxxxxxxxxxx5” es el nodo shard recién agregado. También puede ejecutar el comando getShardDistribution en la base de datos que contiene la colección fragmentada para obtener detalles de la distribución de chunks, como se muestra a continuación.

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

• Método 2: Lea los datos relevantes directamente desde la base de datos config.

  Consulte las estadísticas de chunks agregadas por shard de la siguiente manera.

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

  Para ver los chunks en un shard específico agrupados por namespace, ejecute el siguiente comando.

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

  Para contar los chunks migrados correctamente a un nodo shard específico en las últimas 24 horas, ejecute el siguiente comando.

  // 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 versiones de MongoDB 6.0 y posteriores

Antes de estimar el progreso de la tarea, céntrese en la distribución de datos entre los shards. Aún puede usar la salida de sh.status() como referencia, pero cambie el enfoque del recuento desigual de chunks a la distribución real del volumen de datos.

• Obtenga información sobre la distribución de colecciones fragmentadas y el equilibrio de datos.

  Use el comando getShardDistribution para obtener detalles de la distribución y centrarse en el equilibrio de datos. Ejemplo:

  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

  También puede ejecutar el siguiente comando para obtener información de distribución más detallada (incluido el recuento de documentos, el tamaño total, el recuento de documentos huérfanos y el tamaño de huérfanos):

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

  El siguiente ejemplo de salida muestra un desequilibrio notable de datos entre los 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
                  }
            ]
  }

  A partir de esta salida, puede determinar que la instancia tiene 4 nodos shard y que el volumen total de datos para la colección fragmentada <db>.<collection> es de aproximadamente 2051303530231 bytes (833101815840 + 409714745937 + 178157177704 + 630329790750 = 2051303530231), o alrededor de 1910.4 GB.

• Consulte el volumen de datos migrados correctamente durante el último día.

  Ejecute la siguiente consulta:

  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)

  Salida de ejemplo:

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

  Esta salida muestra que el 2024-09-21 se migraron 183117965820 bytes (aproximadamente 170.5 GB).

Para versiones de MongoDB anteriores a la 6.0

Después de obtener el número de chunks migrados correctamente y la distribución actual de datos, estime el progreso general de la tarea y el tiempo esperado de finalización.

Suponga las siguientes condiciones ideales durante la adición de shards: el recuento total de chunks permanece constante, el recuento de shards se mantiene fijo (sin adiciones ni eliminaciones concurrentes de shards), la carga del servicio permanece estable y los parámetros del Balancer usan valores predeterminados. Con el ejemplo de Step 3 en Para versiones de MongoDB anteriores a la 6.0, se sabe que:

• Hay 5 nodos shard.

• Se migraron 300 chunks correctamente durante la ventana del Balancer.

• La colección fragmentada <db>.<collection> tiene 58260 chunks en total (13630 + 13629 + 13652 + 13630 + 3719 = 58260).

Por lo tanto, se puede calcular lo siguiente:

• En equilibrio, cada shard debería contener 11652 chunks (58260 ÷ 5 = 11652).

• A la tasa de migración actual, la finalización de la tarea requiere otros 26.4 días ((11652 – 3719) ÷ 300 ≈ 26.4).

• La tarea de adición de shards tiene un 32 % de avance (3719 ÷ 11652 = 32 %).

Para versiones de MongoDB 6.0 y posteriores

Suponga que la instancia de clúster fragmentado tiene solo una colección que requiere balanceo. Con el ejemplo de Step 3 en Para versiones de MongoDB 6.0 y posteriores, se sabe que:

• Hay 4 nodos shard.

• El 2024-09-21, se migraron aproximadamente 170.5 GB (183117965820 bytes).

• La colección fragmentada <db>.<collection> tiene un volumen total de datos de aproximadamente 1910.4 GB (2051303530231 bytes).

Por lo tanto, se puede calcular lo siguiente:

• En equilibrio, cada shard debería contener aproximadamente 477.6 GB (512825882557.75 bytes).

• El volumen total de datos que necesita migrarse para alcanzar el equilibrio es de 875559682949 bytes (815.4 GB), desglosado de la siguiente manera:

  Shard1 necesita migrar 320275933282.25 bytes (833101815840 – 512825882557.75).

  Shard2 necesita migrar 103111136620.75 bytes (409714745937 – 512825882557.75).

  Shard3 necesita migrar 334668704853.75 bytes (178157177704 – 512825882557.75).

  Shard4 necesita migrar 117503908192.25 bytes (630329790750 – 512825882557.75).

  (320275933282.25 + 103111136620.75 + 334668704853.75 + 117503908192.25 = 875559682949)

• A la tasa de migración actual, el equilibrio se alcanzará en aproximadamente 4.8 días (815.4 GB ÷ 170.5 GB/día ≈ 4.8 días).