ApsaraDB for MongoDB:Métriques Opcounters et Repl Opcounters

Pourquoi les Repl Opcounters secondaires sont-ils supérieurs aux Opcounters principaux ?

Les opérations affectant plusieurs documents, telles qu'une insertion par lot ou une mise à jour ou suppression multi-documents, sont comptabilisées comme une seule opération sur le nœud principal. Lorsqu'une opération affectant plusieurs documents est répliquée vers les nœuds secondaires, le processus de réplication s'effectue au niveau du document. Par conséquent, la valeur Repl Opcounters sur un nœud secondaire peut être supérieure à la valeur Opcounters sur le nœud principal.

L'exemple suivant illustre ce comportement :

1. Avant la mise à jour, vérifiez les opcounters.

   • Le compteur update Opcounters sur le nœud principal est de 13.

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

   • Le compteur update Repl Opcounters sur le nœud secondaire est de 11.

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

2. Exécutez une mise à jour par lot sur le nœud principal. Le champ modifiedCount renvoyé indique que cette mise à jour par lot a modifié quatre documents.

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

3. Après la mise à jour, vérifiez à nouveau les opcounters.

   • Le compteur update Opcounters sur le nœud principal est désormais de 14.

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

   • Le compteur update Repl Opcounters sur le nœud secondaire est désormais de 15.

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

Pourquoi Repl Opcounters affiche-t-il des insertions lors des mises à jour ?

Cela peut se produire si votre opération de mise à jour spécifie l'option {upsert:true}. Si le document que vous souhaitez update n'existe pas, MongoDB convertit l'opération en une opération insert. Si l'oplog enregistre une opération insert, la réplication applique également une opération insert sur le nœud secondaire. Par conséquent, Repl Opcounters enregistre l'opération insert correspondante.

L'exemple suivant illustre ce comportement :

1. Avant la mise à jour, vérifiez les opcounters.

   • Sur le nœud principal, les Opcounters affichent update: 33 et insert: 1516.

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

   • Sur le nœud secondaire, les Repl Opcounters affichent update: 24 et insert: 1539.

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

2. Sur le nœud principal, exécutez une opération de mise à jour avec l'option {upsert:true}. Le champ upsertedId renvoyé indique qu'un document a été inséré.

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

3. Après la mise à jour, vérifiez à nouveau les opcounters.

   • Sur le nœud principal, le compteur update Opcounters est désormais de 34 et le compteur insert reste à 1516.

     > db.serverStatus().opcounters
     {
       "insert" : NumberLong(1516),
       "query" : NumberLong(70),
       "update" : NumberLong(34),   // Note the change in this counter.
       "delete" : NumberLong(1043),
       "getmore" : NumberLong(2706),
       "command" : NumberLong(4286)
     }

   • Sur le nœud secondaire, le compteur insert Repl Opcounters est désormais de 1540 et le compteur update reste à 24.

     > db.serverStatus().opcountersRepl
     {
       "insert" : NumberLong(1540), // Note the change in this counter.
       "query" : NumberLong(0),
       "update" : NumberLong(24),
       "delete" : NumberLong(6),
       "getmore" : NumberLong(0),
       "command" : NumberLong(26)
     }

Pourquoi le nombre de mises à jour sur le nœud principal est-il supérieur à celui du nœud secondaire ?

Cela peut être dû au fait que la logique de votre application inclut des opérations update répétitives. Si une opération update répétée ne modifie aucune donnée, elle n'est pas répliquée vers les nœuds secondaires. Par conséquent, le nombre d'opérations update enregistrées sur les nœuds secondaires est inférieur.

L'exemple suivant illustre ce comportement :

1. Avant la mise à jour, vérifiez les opcounters.

   • Le nombre update dans les Opcounters sur le nœud principal est de 34.

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

   • Le nombre update dans les Repl Opcounters sur le nœud secondaire est de 24.

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

2. Exécutez une opération de mise à jour sur le nœud principal. Les informations renvoyées indiquent qu'aucune modification réelle n'a eu lieu.

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

3. Après la mise à jour, vérifiez à nouveau les opcounters.

   • Le nombre update dans les Opcounters sur le nœud principal est désormais de 35.

     > db.serverStatus().opcounters
     {
       "insert" : NumberLong(1516),
       "query" : NumberLong(70),
       "update" : NumberLong(35),    // Note the change in this counter.
       "delete" : NumberLong(1043),
       "getmore" : NumberLong(2778),
       "command" : NumberLong(4729)
     }

   • Le nombre update dans les Repl Opcounters sur le nœud secondaire reste à 24.

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

Pourquoi les Opcounters sont-ils actifs sur une base de données inactive ?

Même en l'absence de trafic utilisateur, les données de surveillance signalent toujours un petit nombre d'opérations. Celles-ci comprennent :

• Les opérations internes de base nécessaires au fonctionnement de la base de données MongoDB, telles que les battements de cœur du replica set, la synchronisation entre le nœud principal et les nœuds secondaires, et l'actualisation des sessions.

• Les opérations de routine des composants de gestion d'ApsaraDB for MongoDB, telles que les vérifications d'état, la surveillance et l'écoute des événements.

Pourquoi les métriques Opcounters diffèrent-elles des agrégations oplog ?

Dans l'oplog, vous pouvez utiliser le champ op pour distinguer les types d'opérations. Les valeurs courantes incluent :

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

Les transactions sont enregistrées dans l'oplog avec un type d'opération op: "c". Les opérations individuelles insert, update et delete au sein de la transaction sont stockées en interne dans le champ o.applyOps. Si vous agrégez les résultats en vous basant uniquement sur le champ op de premier niveau de l'oplog, vos résultats ne correspondront pas aux métriques Opcounters dans les scénarios impliquant des transactions. Pour plus d'informations sur le format de l'oplog, consultez Analyse des champs oplog.

Pour compter les types d'opérations spécifiques au sein d'une transaction, connectez-vous à votre instance MongoDB à l'aide du shell mongo et exécutez la commande suivante.

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

Voici la description des paramètres de cette commande :

• Timestamp(1733849400,0) : Une limite inférieure pour l'horodatage ts dans la requête oplog. Remplacez cette valeur par l'heure de requête souhaitée. Vous pouvez lire cet horodatage à partir de local.oplog.rs ou utiliser un horodatage UNIX standard.

• "o.applyOps.0.op":"u" : Spécifie que la première opération dans l'oplog de la transaction est une mise à jour. Vous pouvez remplacer cette valeur par d'autres types d'opérations. Par exemple, si la première opération est une insertion, utilisez "o.applyOps.0.op":"i".

• {$count:"count"} : Compte uniquement le nombre d'entrées oplog correspondantes. Vous pouvez utiliser d'autres opérateurs d'agrégation pour d'autres types d'analyses.

Pour afficher les métriques de surveillance liées aux transactions, accédez à la page Monitoring Information dans la console ApsaraDB for MongoDB et consultez la métrique Transaction Operands. Pour plus d'informations sur cette métrique, consultez la section Éléments et métriques de surveillance.

L'exemple suivant illustre ce comportement :

1. Avant la mise à jour, vérifiez les Opcounters.

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

2. Sur le nœud principal, exécutez une opération d'écriture au sein d'une transaction.

   // Start a session.
   session = db.getMongo().startSession( { readPreference: { mode: "primary" } } );
   coll1 = session.getDatabase("mydb1").foo;
   coll2 = session.getDatabase("mydb2").bar;
   // Start a transaction.
   session.startTransaction( { readConcern: { level: "local" }, writeConcern: { w: "majority" } } );
   // Execute two insert operations in the transaction.
   try {
      coll1.insertOne( { abc: 1 } );
      coll2.insertOne( { xyz: 999 } );
   } catch (error) {
      // Abort the transaction if an error occurs.
      session.abortTransaction();
      throw error;
   }
   // Commit the transaction.
   session.commitTransaction();
   session.endSession();

3. Après la mise à jour, vérifiez à nouveau les Opcounters. Le nombre insert dans les Opcounters est passé de 4 à 6.

   > db.serverStatus().opcounters
   {
     "insert" : NumberLong(6),   // Note the change in this counter.
     "query" : NumberLong(6728),
     "update" : NumberLong(110532),
     "delete" : NumberLong(3067),
     "getmore" : NumberLong(222823),
     "command" : NumberLong(1918887)
   }