3つのメンバーで構成されるMongoDBレプリケーションセットがあります。
_ "members" : [
{
"_id" : 6,
"Host" : "10.0.0.17:27017",
"arbiterOnly" : false,
"buildIndexes" : true,
"hidden" : false,
"priority" : 2,
"tags" : {
},
"slaveDelay" : NumberLong(0),
"votes" : 1
},
{
"_id" : 7,
"Host" : "10.0.0.18:27017",
"arbiterOnly" : false,
"buildIndexes" : true,
"hidden" : false,
"priority" : 2,
"tags" : {
},
"slaveDelay" : NumberLong(0),
"votes" : 1
},
{
"_id" : 8,
"Host" : "10.0.0.19:27017",
"arbiterOnly" : false,
"buildIndexes" : true,
"hidden" : false,
"priority" : 2,
"tags" : {
},
"slaveDelay" : NumberLong(0),
"votes" : 1
}
],
_
クラスターの負荷は中程度で、1秒あたり数十リクエスト以下です。プライマリレポートのdb.serverStatus()
は、ほとんどすべてのトランザクションがロールバックされていることを報告します。
_"transaction begins" : 2625009877,
"transaction checkpoint currently running" : 0,
"transaction checkpoint generation" : 22618,
"transaction checkpoint max time (msecs)" : 5849,
"transaction checkpoint min time (msecs)" : 153,
"transaction checkpoint most recent time (msecs)" : 1869,
"transaction checkpoint scrub dirty target" : 0,
"transaction checkpoint scrub time (msecs)" : 0,
"transaction checkpoint total time (msecs)" : 11017082,
"transaction checkpoints" : 22617,
"transaction checkpoints skipped because database was clean" : 0,
"transaction failures due to cache overflow" : 0,
"transaction fsync calls for checkpoint after allocating the transaction ID" : 22617,
"transaction fsync duration for checkpoint after allocating the transaction ID (usecs)" : 354402,
"transaction range of IDs currently pinned" : 0,
"transaction range of IDs currently pinned by a checkpoint" : 0,
"transaction range of IDs currently pinned by named snapshots" : 0,
"transaction range of timestamps currently pinned" : 8589934583,
"transaction range of timestamps pinned by the oldest timestamp" : 8589934583,
"transaction sync calls" : 0,
"transactions committed" : 30213144,
"transactions rolled back" : 2594972913,
"update conflicts" : 578
_
基本的に、私の質問は次のとおりです。ここで何が起こっているのですか?非常に多くのトランザクションと非常に多くのロールバックがあるのは正常ですか?そうでない場合、根本的な原因は何であり、それを修正するのに熱心ですか?
更新:_3.6.8-2.0
_(これは3.6シリーズの最新のPerconaパッケージでした)にアップグレードしましたが、問題は解決しませんでした。
db.serverStatus().wiredTiger
のメトリックの多くは、MongoDB APIではなく、基盤となるWiredTigerストレージエンジンのメトリックと用語を反映しているため、混乱する可能性があります。 transactions、sessions、rollbacksは、エンドユーザーのMongoDB機能とはストレージ内部のコンテキストが異なります。公開されたメトリックの一部は、エンドユーザーの監視にはあまり役立ちませんが、基盤となるストレージAPIに精通している開発者に診断の洞察を提供する場合があります。
ここで何が起こっているのですか?
WiredTigerストレージエンジンは Multiversion Concurrency Control(MVCC) を使用して、データの読み取りと書き込みを行う内部スレッドへの同時アクセスを提供します。 MongoDBサーバーには、基盤となるストレージエンジンAPIを使用してMongoDB API(ドライバーによって使用される)を介して公開されるコマンドを実装する統合レイヤーがあります。
WiredTiger APIには 内部セッションとトランザクション があり、内部スレッドがデータの一貫したスナップショットを処理できるようになっています。内部トランザクションは、コミット(データが書き込まれた)またはロールバック(トランザクションが意図的にまたはエラーのために中止された)することで終了できます。
非常に多くのトランザクションと非常に多くのロールバックがあるのは正常ですか?
はい、これは正常です。 MongoDB統合レイヤーを介した読み取り専用クエリは、一貫した読み取りのためにWiredTigerトランザクションAPIを使用しますが、トランザクションをコミットするデータがないため、意図的に中止され、「トランザクションのロールバック」メトリックに追加されます。
「トランザクションのロールバック」メトリックは、書き込みの競合(透過的に再試行される同じドキュメントへの同時内部更新)などの他のユースケースのためにインクリメントすることもできます。
そうでない場合、根本的な原因とその修正方法は何ですか?
このメトリックは、懸念や監視のために特に焦点を当てるべきではありません。