[SERVER-49815] mongos attach user client metadata to non-user request Created: 22/Jul/20  Updated: 20/Oct/20  Resolved: 20/Oct/20

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: 3.6.18
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Asya Kamsky Assignee: Benjamin Caimano (Inactive)
Resolution: Duplicate Votes: 0
Labels: sa-groomed
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
duplicates SERVER-49336 Set client metadata if it is missing ... Closed
Operating System: ALL
Participants:

 Description   

An example from a customer log file shows that their client metadata is in a log line from moveChunk which was initiated by the system.

2020-07-22T15:52:34.075+0000 I COMMAND  [conn2903218] command admin.$cmd command: moveChunk { moveChunk: "db.coll", shardVersion: [ Timestamp(1, 24), ObjectId('5f185d9f3354ab24e366e50f') ], epoch: ObjectId('5f185d9f3354ab24e366e50f'), configdb: "atlas-config-0/atlas-config-00...", fromShard: "atlas-shard-4", toShard: "atlas-shard-1", min: { id: -8485502273906393736 }, max: { id: -7747632510958011672 }, maxChunkSizeBytes: 67108864, secondaryThrottle: false, waitForDelete: true, takeDistLock: false, lsid: { id: UUID("6617fbc7-a91f-431a-a977-2f2ceab9a567"), uid: BinData(0, ...) }, $clusterTime: { clusterTime: Timestamp(1595432503, 611), signature: { hash: BinData(0, ...), keyId: ... } }, $client: { driver: { name: "nodejs", version: "3.5.6" }, os: { type: "Linux", name: "linux", architecture: "x64", version: "4.15.0-1060-gcp" }, platform: "'Node.js v10.19.0, LE (unified)", mongos: { host: "atlas-shard-12-....mongodb.net:27016", client: "10.xxx", version: "3.6.18" } }, $configServerState: { opTime: { ts: Timestamp(1595432503, 611), t: 16 } }, $db: "admin" } numYields:0 reslen:301 locks:{ Global: { acquireCount: { r: 15486, w: 16 } }, Database: { acquireCount: { r: 7735, w: 14, W: 2 } }, Collection: { acquireCount: { r: 1366, w: 2, W: 5 }, acquireWaitCount: { W: 1 }, timeAcquiringMicros: { W: 69476755 } }, oplog: { acquireCount: { r: 6369, w: 7 } } } protocol:op_msg 650850ms



 Comments   
Comment by Benjamin Caimano (Inactive) [ 20/Oct/20 ]

Hey asya, I think we've fixed this as part of SERVER-49336. Previously, we used forwarded metadata to overwrite the client metadata. If that specific client was then used for a non-external op, it would show the external metadata. Now, we maintain two separate objects, one of which lasts for client lifetime and one which lasts for operation lifetime.

Comment by Asya Kamsky [ 28/Jul/20 ]

note that it's possible that moveChunk may have been initiated as a result of the user running a sh.shardCollection() command - if that's the only scenario in which this happens, it's possible that it's not outright "wrong" (though still highly misleading)...

Generated at Thu Feb 08 05:20:55 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.