ApsaraDB for MongoDB:Metrik Opcounters dan Repl Opcounters

Mengapa Repl Opcounters pada secondary lebih tinggi daripada Opcounters pada primary?

Operasi yang memengaruhi beberapa dokumen, seperti insert batch atau update/delete multi-dokumen, dihitung sebagai satu operasi pada node primary. Saat operasi tersebut direplikasi ke node secondary, proses replikasi bersifat berbasis dokumen. Akibatnya, nilai Repl Opcounters pada node secondary bisa lebih tinggi daripada nilai Opcounters pada node primary.

Contoh berikut menunjukkan perilaku ini:

1. Sebelum update, periksa opcounters.

   • Counter update Opcounters pada node primary adalah 13.

     > db.serverStatus().opcounters.update
     NumberLong(13)

   • Counter update Repl Opcounters pada node secondary adalah 11.

     > db.serverStatus().opcountersRepl.update
     NumberLong(11)

2. Lakukan update batch pada node primary. Field modifiedCount yang dikembalikan menunjukkan bahwa update batch ini memodifikasi empat dokumen.

   > db.coll.updateMany({x:2},{$set:{x:3}})
   { "acknowledged" : true, "matchedCount" : 4, "modifiedCount" : 4 }

3. Setelah update, periksa opcounters lagi.

   • Counter update Opcounters pada node primary sekarang menjadi 14.

     > db.serverStatus().opcounters.update
     NumberLong(14)

   • Counter update Repl Opcounters pada node secondary sekarang menjadi 15.

     > db.serverStatus().opcountersRepl.update
     NumberLong(15)

Mengapa Repl Opcounters menampilkan insert selama update?

Hal ini dapat terjadi karena operasi update Anda menentukan opsi {upsert:true}. Jika dokumen yang ingin Anda update tidak ada, MongoDB mengubah operasi tersebut menjadi operasi insert. Jika oplog mencatat operasi insert, replikasi juga menerapkan operasi insert pada node secondary. Oleh karena itu, Repl Opcounters mencatat operasi insert yang sesuai.

Contoh berikut menunjukkan perilaku ini:

1. Sebelum update, periksa opcounters.

   • Pada node primary, Opcounters menunjukkan update: 33 dan insert: 1516.

     > db.serverStatus().opcounters
     {
       "insert" : NumberLong(1516),
       "query" : NumberLong(70),
       "update" : NumberLong(33),
       "delete" : NumberLong(1043),
       "getmore" : NumberLong(2662),
       "command" : NumberLong(4000)
     }

   • Pada node secondary, Repl Opcounters menunjukkan update: 24 dan insert: 1539.

     > db.serverStatus().opcountersRepl
     {
       "insert" : NumberLong(1539),
       "query" : NumberLong(0),
       "update" : NumberLong(24),
       "delete" : NumberLong(6),
       "getmore" : NumberLong(0),
       "command" : NumberLong(26)
     }

2. Pada node primary, jalankan operasi update dengan opsi {upsert:true}. Field upsertedId yang dikembalikan menunjukkan bahwa satu dokumen telah disisipkan.

   > db.coll.updateOne({x:"a"}, {$set:{x:"b"}}, {upsert:true})
   {
     "acknowledged" : true,
     "matchedCount" : 0,
     "modifiedCount" : 0,
     "upsertedId" : ObjectId("64bf72b829907f52b4b363ea")
   }

3. Setelah update, periksa opcounters lagi.

   • Pada node primary, counter update Opcounters sekarang menjadi 34 dan counter insert tetap 1516.

     > db.serverStatus().opcounters
     {
       "insert" : NumberLong(1516),
       "query" : NumberLong(70),
       "update" : NumberLong(34),   // Perhatikan perubahan pada counter ini.
       "delete" : NumberLong(1043),
       "getmore" : NumberLong(2706),
       "command" : NumberLong(4286)
     }

   • Pada node secondary, counter insert Repl Opcounters sekarang menjadi 1540 dan counter update tetap 24.

     > db.serverStatus().opcountersRepl
     {
       "insert" : NumberLong(1540), // Perhatikan perubahan pada counter ini.
       "query" : NumberLong(0),
       "update" : NumberLong(24),
       "delete" : NumberLong(6),
       "getmore" : NumberLong(0),
       "command" : NumberLong(26)
     }

Mengapa jumlah update pada primary lebih tinggi daripada secondary?

Hal ini mungkin terjadi karena logika aplikasi Anda mencakup operasi update berulang. Jika operasi update berulang tidak benar-benar mengubah data apa pun, operasi tersebut tidak direplikasi ke node secondary. Oleh karena itu, jumlah operasi update yang dicatat pada node secondary lebih rendah.

Contoh berikut menunjukkan perilaku ini:

1. Sebelum update, periksa opcounters.

   • Jumlah update dalam Opcounters pada node primary adalah 34.

     > db.serverStatus().opcounters
     {
       "insert" : NumberLong(1516),
       "query" : NumberLong(70),
       "update" : NumberLong(34),
       "delete" : NumberLong(1043),
       "getmore" : NumberLong(2760),
       "command" : NumberLong(4609)
     }

   • Jumlah update dalam Repl Opcounters pada node secondary adalah 24.

     > db.serverStatus().opcountersRepl
     {
       "insert" : NumberLong(1540),
       "query" : NumberLong(0),
       "update" : NumberLong(24),
       "delete" : NumberLong(6),
       "getmore" : NumberLong(0),
       "command" : NumberLong(26)
     }

2. Lakukan operasi update pada node primary. Informasi yang dikembalikan menunjukkan bahwa tidak ada modifikasi aktual yang terjadi.

   > db.coll.updateMany({x:"ab"},{$set:{x:"cd"}})
   { "acknowledged" : true, "matchedCount" : 0, "modifiedCount" : 0 }

3. Setelah update, periksa opcounters lagi.

   • Jumlah update dalam Opcounters pada node primary sekarang menjadi 35.

     > db.serverStatus().opcounters
     {
       "insert" : NumberLong(1516),
       "query" : NumberLong(70),
       "update" : NumberLong(35),    // Perhatikan perubahan pada counter ini.
       "delete" : NumberLong(1043),
       "getmore" : NumberLong(2778),
       "command" : NumberLong(4729)
     }

   • Jumlah update dalam Repl Opcounters pada node secondary tetap 24.

     > db.serverStatus().opcountersRepl
     {
       "insert" : NumberLong(1540),
       "query" : NumberLong(0),
       "update" : NumberLong(24),
       "delete" : NumberLong(6),
       "getmore" : NumberLong(0),
       "command" : NumberLong(26)
     }

Mengapa Opcounters aktif pada database yang tidak digunakan?

Bahkan tanpa traffic pengguna, data pemantauan tetap melaporkan sejumlah kecil operasi. Operasi tersebut terdiri dari hal-hal berikut:

• Operasi internal dasar yang menjaga database MongoDB tetap berjalan, seperti heartbeat replica set, sinkronisasi primary/secondary, dan refresh session.

• Operasi rutin dari komponen manajemen ApsaraDB for MongoDB, seperti pemeriksaan kesehatan, pemantauan, dan pendengaran event.

Mengapa metrik Opcounters berbeda dari agregasi oplog?

Di oplog, Anda dapat menggunakan field op untuk membedakan jenis operasi. Nilai umum meliputi:

kCommand: "c"
kInsert: "i"
kUpdate: "u"
kDelete: "d"
kNoop: "n"

Transaksi dicatat di oplog dengan jenis operasi op: "c". Operasi insert, update, dan delete individual dalam transaksi disimpan secara internal di field o.applyOps. Jika Anda mengagregasi hasil hanya berdasarkan field op tingkat atas dari oplog, hasil Anda tidak akan sesuai dengan metrik Opcounters dalam skenario yang melibatkan transaksi. Untuk informasi lebih lanjut tentang format oplog, lihat Analysis of oplog fields.

Untuk menghitung jenis operasi spesifik dalam transaksi, sambungkan ke instans MongoDB Anda menggunakan mongo shell dan jalankan perintah berikut.

use local
db.oplog.rs.aggregate([{$match:{"op":"c","ts":{"$gte": Timestamp(1733849400,0)},"o.applyOps":{$exists:true},"o.applyOps.0.op":"u"}},{$count:"count"}])

Berikut ini penjelasan parameter dalam perintah ini:

• Timestamp(1733849400,0): Batas bawah untuk stempel waktu ts dalam kueri oplog. Ganti nilai ini dengan waktu kueri yang diinginkan. Anda dapat membaca stempel waktu ini dari local.oplog.rs atau menggunakan stempel waktu UNIX standar.

• "o.applyOps.0.op":"u": Menentukan bahwa operasi pertama dalam oplog transaksi adalah update. Anda dapat mengganti ini dengan jenis operasi lain. Misalnya, jika operasi pertama adalah insert, gunakan "o.applyOps.0.op":"i".

• {$count:"count"}: Hanya menghitung jumlah entri oplog yang cocok. Anda dapat menggunakan operator agregasi lain untuk jenis analisis lainnya.

Untuk melihat metrik pemantauan terkait transaksi, buka halaman Monitoring Information di konsol ApsaraDB for MongoDB dan lihat metrik Transaction Operands. Untuk informasi lebih lanjut tentang metrik ini, lihat Monitoring items and metrics.

Contoh berikut menunjukkan perilaku ini:

1. Sebelum update, periksa Opcounters.

   > db.serverStatus().opcounters
   {
     "insert" : NumberLong(4), 
     "query" : NumberLong(6723),
     "update" : NumberLong(110489),
     "delete" : NumberLong(3065),
     "getmore" : NumberLong(222670),
     "command" : NumberLong(1917525)
   }

2. Pada node primary, lakukan operasi write dalam transaksi.

   // Mulai sesi.
   session = db.getMongo().startSession( { readPreference: { mode: "primary" } } );
   coll1 = session.getDatabase("mydb1").foo;
   coll2 = session.getDatabase("mydb2").bar;
   // Mulai transaksi.
   session.startTransaction( { readConcern: { level: "local" }, writeConcern: { w: "majority" } } );
   // Lakukan dua operasi insert dalam transaksi.
   try {
      coll1.insertOne( { abc: 1 } );
      coll2.insertOne( { xyz: 999 } );
   } catch (error) {
      // Batalkan transaksi jika terjadi error.
      session.abortTransaction();
      throw error;
   }
   // Commit transaksi.
   session.commitTransaction();
   session.endSession();

3. Setelah update, periksa Opcounters lagi. Jumlah insert dalam Opcounters berubah dari 4 menjadi 6.

   > db.serverStatus().opcounters
   {
     "insert" : NumberLong(6),   // Perhatikan perubahan pada counter ini.
     "query" : NumberLong(6728),
     "update" : NumberLong(110532),
     "delete" : NumberLong(3067),
     "getmore" : NumberLong(222823),
     "command" : NumberLong(1918887)
   }