ApsaraDB for MongoDB：Lihat kemajuan penambahan atau penghapusan shard

Metode yang tersedia untuk versi sebelum MongoDB 6.0

Sebelum mengevaluasi tugas, Anda harus mendapatkan hasil operasional balancer dan informasi chunk dari koleksi sharded yang akan dimigrasikan. Hasil operasional balancer mencakup statistik jumlah chunk yang dimigrasikan dan chunk yang gagal dimigrasikan.

Anda dapat menggunakan salah satu metode berikut untuk mendapatkan informasi di atas:

• Metode 1: Lihat output yang dikembalikan untuk perintah sh.status()

  Dalam output yang dikembalikan untuk perintah sh.status(), Anda harus fokus pada hasil operasional terbaru balancer dan informasi chunk dari tabel sharded yang akan dimigrasikan. Contoh berikut menunjukkan hasil operasional terbaru balancer:

  ...
    balancer:
          Koleksi dengan migrasi aktif: 
                  <db>.<koleksi> dimulai pada Rabu, 27 September 2023 10:25:21 GMT+0800 (CST)
          Putaran balancer gagal dalam 5 percobaan terakhir:  0
          Hasil Migrasi dalam 24 jam terakhir: 
                  300 : Sukses
    database:
  ...

  Contoh berikut menunjukkan informasi chunk dari koleksi sharded yang akan dimigrasikan:

  ...
  database:
  ...
      {  "_id" : "<db>",  "primary" : "d-xxxxxxxxxxxxxxx3",  "partitioned" : true,  "version" : {  "uuid" : UUID("3409a337-c370-4425-ad72-8b8c6b0abd52"),  "lastMod" : 1 } }
            <db>.<koleksi>
                          kunci shard: { "<kunci_shard>" : "hashed" }
                          unik: false
                          balancing: true
                          chunk:
                                  d-xxxxxxxxxxxxxxx1      13630
                                  d-xxxxxxxxxxxxxxx2      13629
                                  d-xxxxxxxxxxxxxxx3      13652
                                  d-xxxxxxxxxxxxxxx4      13630
                                  d-xxxxxxxxxxxxxxx5      3719
                          terlalu banyak chunk untuk dicetak, gunakan verbose jika Anda ingin memaksa pencetakan
  ...

  Dalam contoh di atas, d-xxxxxxxxxxxxxxx5 menunjukkan shard yang ditambahkan. Anda juga dapat menjalankan perintah getShardDistribution pada database tempat tabel partisi berada untuk mendapatkan informasi tentang distribusi chunk data. Contoh kode:

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

• Metode 2: Baca langsung informasi terkait dari database config

  Kueri statistik chunk dan kemudian agregasikan berdasarkan shard. Contoh kode:

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

  Kueri chunk pada shard tertentu dan kemudian agregasikan berdasarkan namespace. Contoh kode:

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

  Kueri jumlah chunk yang dimigrasikan ke shard tertentu dalam sehari sebelumnya. Contoh kode:

  // Tentukan field details.to sebagai shard yang ingin Anda migrasikan.
  // Tentukan field waktu sebagai rentang waktu tipe ISODate.
  db.getSiblingDB("config").changelog.find({"what" : "moveChunk.commit", "details.to" : "d-xxxxxxxxxxxxx","time" : {"$gte": ISODate("2023-09-26T00:00:00")}}).count()

Metode yang tersedia untuk versi setelah MongoDB 6.0

Sebelum mengevaluasi tugas, Anda harus fokus pada distribusi data di antara shard. Anda masih dapat menggunakan output yang dikembalikan oleh perintah sh.status() sebagai referensi. Namun, setelah Anda mendapatkan output, Anda harus lebih memperhatikan distribusi data pada setiap shard daripada jumlah chunk yang tidak merata pada setiap shard.

• Dapatkan distribusi data dan keseragaman koleksi sharded.

  Kami merekomendasikan Anda menjalankan perintah getShardDistribution untuk mendapatkan distribusi data pada koleksi sharded dan fokus pada keseragaman data, seperti yang ditunjukkan pada gambar berikut.

  Anda juga dapat menjalankan perintah berikut untuk mendapatkan distribusi lebih rinci, termasuk jumlah dan ukuran total dokumen serta dokumen yatim:

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

  Contoh berikut menunjukkan output untuk perintah di atas. Output tersebut menunjukkan bahwa data sangat tidak merata di antara shard.

  {
          "ns" : "<db>.<koleksi>",
          "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
                  }
            ]
  }

  Output tersebut juga menunjukkan item berikut: 1. Instance tempat Anda menjalankan perintah di atas berisi empat shard. 2. Volume data koleksi sharded bernama <db>.<koleksi> dalam instance tersebut sekitar 2.051.303.530.231 byte (833.101.815.840 + 409.714.745.937 + 178.157.177.704 + 630.329.790.750), yang setara dengan 1.910,4 GB.

• Lihat jumlah data yang berhasil dimigrasikan dalam sehari sebelumnya.

  Jalankan perintah berikut:

  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)

  Gambar berikut menunjukkan output yang dikembalikan untuk perintah di atas.

  Output tersebut menunjukkan bahwa 183.117.965.820 byte berhasil dimigrasikan pada 2024-09-21, yang setara dengan 170,5 GB.

Metode yang tersedia untuk versi sebelum MongoDB 6.0

Setelah Anda mendapatkan jumlah chunk yang dimigrasikan dari koleksi sharded dan distribusi data dalam koleksi sharded saat ini, Anda dapat memperkirakan kemajuan keseluruhan dan waktu penyelesaian yang diharapkan dari tugas tersebut.

Anggaplah Anda ingin menambahkan shard. Sebelum shard ditambahkan, jumlah total chunk tetap tidak berubah. Selain itu, jumlah shard tetap tidak berubah, yang menunjukkan bahwa tidak ada tugas yang diinisiasi untuk menambah atau menghapus shard. Saat shard sedang ditambahkan, beban kerja bisnis tetap konstan, dan parameter terkait balancer disetel ke nilai default mereka. Contoh pertama yang dijelaskan dalam metode yang tersedia untuk versi sebelum MongoDB 6.0 di Langkah 3 digunakan. Contoh tersebut menunjukkan item berikut:

• Lima shard ditambahkan.

• 300 chunk dimigrasikan dalam jendela waktu balancer.

• 58.260 chunk terdapat dalam koleksi sharded bernama <db>.<koleksi>. Jumlah chunk dihitung berdasarkan rumus berikut: 13.630 + 13.629 + 13.652 + 13.630 + 3.719 = 58.260.

Nilai berikut dapat dihitung berdasarkan hasil di atas:

• Saat chunk didistribusikan secara merata di seluruh shard, jumlah chunk di setiap shard adalah 11.652 (58.260/5 = 11.652).

• Berdasarkan kecepatan migrasi saat ini, dibutuhkan waktu tambahan 26,4 hari untuk menyelesaikan migrasi. Jumlah hari dihitung berdasarkan rumus berikut: (11.652 - 3.719)/300 ≈ 26,4.

• Proses tugas untuk menambahkan shard adalah 32% (3.719/11.652 = 32%).

Metode yang tersedia untuk versi setelah MongoDB 6.0

Anggaplah hanya satu koleksi dalam instance kluster sharded yang perlu diseimbangkan. Contoh pertama yang dijelaskan dalam metode yang tersedia untuk versi setelah MongoDB 6.0 di Langkah 3 digunakan. Contoh tersebut menunjukkan item berikut:

• Empat shard ditambahkan.

• 183.117.965.820 byte berhasil dimigrasikan pada 2024-09-21, yang setara dengan 170,5 GB.

• Volume data koleksi sharded bernama <db>.<koleksi> sekitar 2.051.303.530.231 byte (833.101.815.840 + 409.714.745.937 + 178.157.177.704 + 630.329.790.750), yang setara dengan 1.910,4 GB.

Nilai berikut dapat dihitung berdasarkan hasil di atas:

• Saat keseimbangan data tercapai di antara shard, volume data setiap shard sekitar 512.825.882.557,75 byte, yang setara dengan 477,6 GB.

• Untuk mencapai keseimbangan data di antara shard, Anda harus memigrasikan total 875.559.682.949 byte di antara shard, yang setara dengan 815,4 GB. Data spesifik yang dimigrasikan dari setiap shard:

  Jumlah data yang harus dimigrasikan dari Shard 1 adalah 320.275.933.282,25 byte (833.101.815.840 - 512.825.882.557,75).

  Jumlah data yang harus dimigrasikan dari Shard 2 adalah 103.111.136.620,75 byte (409.714.745.937 - 512.825.882.557,75).

  Jumlah data yang harus dimigrasikan dari Shard 3 adalah 334.668.704.853,75 byte (178.157.177.704 - 512.825.882.557,75).

  Jumlah data yang harus dimigrasikan dari Shard 4 adalah 117.503.908.192,25 byte (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)

• Dibutuhkan sekitar 4,8 hari (815,4 GB/170,5 GB per hari) untuk mencapai keseimbangan data pada tingkat migrasi saat ini.