ApsaraDB for MongoDB:OpcountersおよびRepl Opcountersメトリック

インスタンスのセカンダリノードのRepl Opcountersメトリックの値が、インスタンスのプライマリノードのOpcountersメトリックの値よりもはるかに大きいのはなぜですか。

バッチ挿入、複数の更新、複数の削除など、複数のドキュメントに影響を与える操作は、単一の操作として解釈されます。 複数のドキュメントに影響を与える操作がインスタンス内のセカンダリノードにレプリケートされる場合、インスタンス内のセカンダリノードのRepl Occountersメトリックの値は、インスタンス内のプライマリノードのOccountersメトリックの値よりも大きくなる可能性があります。

例：

1. 更新の前に、Occountersメトリックを表示します。

   • インスタンス内のプライマリノードのOccountersメトリックの値は13として表示されます。

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

   • インスタンス内のセカンダリノードのRepl Occountersメトリックの値は11として表示されます。

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

2. インスタンスのプライマリノードでバッチ更新を実行します。 返されたmodifiedCountフィールドは、バッチ更新で4つのドキュメントが変更されたことを示します。

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

3. 更新後、Oppcountersメトリックを再度表示します。

   • プライマリノードのOccountersメトリックの値は14として表示されます。

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

   • インスタンス内のセカンダリノードのRepl Occountersメトリックの値は15として表示されます。

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

更新操作のみを実行すると、セカンダリノードのRepl Opcountersメトリックに多くの挿入操作が表示されるのはなぜですか。

この問題は、更新操作に {upsert:true} オプションを指定すると発生する可能性があります。 update操作を実行するドキュメントが存在しない場合は、代わりにinsert操作が実行されます。 insert操作がインスタンスのoplogコレクションに記録されている場合、insert操作はプライマリ /セカンダリレプリケーションを使用してインスタンスのセカンダリノードに同期されます。 したがって、insert操作はRepl Opcountersメトリックに記録されます。

例：

1. 更新の前に、Occountersメトリックを表示します。

   • インスタンス内のプライマリノードのOccountersメトリックでは、更新操作の数は33として表示され、挿入操作の数は1516として表示されます。

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

   • インスタンス内のセカンダリノードのRepl Occountersメトリックでは、更新操作の数は24として表示され、挿入操作の数は1539として表示されます。

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

2. プライマリノードで {upsert:true} オプションを有効にして更新操作を実行します。 返されたussertedIdフィールドは、ドキュメントが挿入されたことを示します。

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

3. 更新後、Oppcountersメトリックを再度表示します。

   • プライマリノードのOccountersメトリックでは、更新操作の数は34として表示され、挿入操作の数は1516として表示されます。

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

   • セカンダリノードのRepl Occountersメトリックでは、更新操作の数は24として表示され、挿入操作の数は1540として表示されます。

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

インスタンスのプライマリノードでの更新操作の数が、インスタンスのセカンダリノードにレプリケートされる更新操作の数よりもはるかに多いのはなぜですか。

この問題は、ビジネスロジックに重複する更新操作が含まれている場合に発生します。 実際の変更は発生しないため、重複更新操作はセカンダリノードにレプリケートされません。 したがって、セカンダリノードに複製される更新操作の数は少なくなる。

例：

1. 更新の前に、Occountersメトリックを表示します。

   • インスタンス内のプライマリノードのOccountersメトリックでは、更新操作の数は34として表示されます。

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

   • インスタンス内のセカンダリノードのRepl Occountersメトリックでは、更新操作の数は24と表示されます。

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

2. プライマリノードで更新操作を実行します。 返された結果は、実際の変更が発生しないことを示します。

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

3. 更新後、Oppcountersメトリックを再度表示します。

   • プライマリノードのOccountersメトリックでは、更新操作の数は35として表示されます。

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

   • 2次ノードのRepl Occountersメトリックでは、更新操作の数は24として表示されます。

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

データベースを使用しない場合でも、Occountersメトリックによって追跡されるさまざまな種類の操作が表示されるのはなぜですか。

業務アクセスが発生していない場合, 監視チャートに表示される操作には次の種類があります。

• ApsaraDB for MongoDBデータベースの通常の操作を維持するために実行される基本的な内部操作 (レプリカセットハートビート、プライマリ /セカンダリ同期、セッション更新など) 。

• 検出、モニタリング、リスニングなど、ApsaraDB for MongoDBデータベースの管理および制御コンポーネントによって毎日実行される操作。

Opcountersメトリックによって追跡される項目が、インスタンスのoplogコレクションのopフィールドによって集計された項目と異なるのはなぜですか。

oplogコレクションでは、opフィールドを使用して特定の操作タイプを区別できます。 フィールドの有効な値:

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

トランザクション内のすべての操作はop:c型であり、トランザクション内のすべてのinsert、update、およびdelete操作はo.applyOpsにのみ格納されます。 oplogコレクションのopフィールドのみに基づいて集計を実行すると、トランザクションが存在するシナリオで取得された結果は、Opcountersメトリックに表示された結果と一致しません。 oplog形式の詳細については、「oplogフィールドの解析」をご参照ください。

トランザクション内の特定の操作の数をカウントする場合は、mongoシェルクライアントを使用してApsaraDB for MongoDBに接続し、次のコマンドを実行します。

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

パラメーター：

• Timestamp(1733849400,0): oplogエントリをクエリするときのts timestampの下限。 目的のクエリ時間に置き換える必要があります。 local.oplog.rsからタイムスタンプを読み取るか、UNIXタイムスタンプを使用できます。

• "o.applyOps. 0.op ":" u "トランザクションoplogの最初の操作タイプ。 トランザクションoplogの最初の操作タイプが更新の場合、別の操作タイプに置き換えることができます。 たとえば、最初の操作タイプがinsertの場合、"o.applyOps" に置き換えることができます。 0.op ":" i "

• {$count:"count"}: 要件を満たすoplogエントリの数。 集計ステートメントの他の演算子を他の分析に使用できます。

トランザクション関連のメトリックを表示する場合は、ApsaraDB for MongoDBコンソールのモニタリングデータモジュールでトランザクション操作のメトリックを表示できます。 詳細については、「モニタリング項目とメトリクス」をご参照ください。

例：

1. 更新の前に、Occountersメトリックを表示します。

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

2. インスタンスのプライマリノードでトランザクション内書き込み操作を実行します。

   // 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" } } );
   // Perform two insert operations in the transaction.
   try {
      coll1.insertOne( { abc: 1 } );
      coll2.insertOne( { xyz: 999 } );
   } catch (error) {
      // Abort the transaction when an error occurs.
      session.abortTransaction();
      throw error;
   }
   // Commit the transaction.
   session.commitTransaction();
   session.endSession();

3. 更新後、Oppcountersメトリックを再度表示します。 Opcountersメトリックでは、挿入操作の数が4から6に変わります。

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