[SERVER-8136] allow db.currentOp() from mongos to show the query jobs performed on secondaries Created: 10/Jan/13  Updated: 06/Dec/22  Resolved: 17/Apr/18

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

Type: Bug Priority: Minor - P4
Reporter: stronglee Assignee: Backlog - Replication Team
Resolution: Duplicate Votes: 4
Labels: MongosOperationManagement
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Debian 6.0 kernel: Linux 2.6.38-2-amd64
cluster: a sharded cluster with 4 replica sets. Each rs contains a primary & a secondary & an arbiter


Issue Links:
Duplicate
duplicates SERVER-19318 currentOp command should return cursor Closed
Related
related to SERVER-8878 db.currentOp() and db.killOp() on a m... Closed
related to SERVER-34633 Allow $currentOp to retrieve operatio... Closed
Assigned Teams:
Replication
Operating System: Linux
Participants:

 Description   

I wanted to use db.killOp() to kill some long time queries which were performed on secondaries by using read preference "Secondary".
But the jobs are not shown when I use db.currentOp() so I can not kill them.
(Queries performed on primaries can be shown by using db.currentOp())



 Comments   
Comment by Bernard Gorman [ 17/Apr/18 ]

spencer: this behaviour has already been implemented as part of the $currentOp aggregation stage; a $currentOp pipeline accepts and will honour a read preference, if one is provided. See the abridged sample output below, with secondaries for each of three shards running on ports 27019, 27022, 27025.

I'm going to close this as a dupe of SERVER-19318 - please let me know if you think it needs to be reopened for any reason.

mongos> use admin
mongos> db.getMongo().setReadPref("secondary")
mongos> db.aggregate([{$currentOp: {idleConnections: true}}])
...
{
	"shard" : "shard01",
	"host" : "SEELE:27019",
	"desc" : "ReplBatcher",
	"active" : true,
	"currentOpTime" : "2018-04-17T18:51:33.523+0100",
	"opid" : "shard01:9287",
	"op" : "none",
	"ns" : "",
	"command" : {
 
	},
	"numYields" : 0,
	"locks" : {
 
	},
	"waitingForLock" : false,
	"lockStats" : {
 
	}
}
{
	"shard" : "shard02",
	"host" : "SEELE:27022",
	"desc" : "ReplBatcher",
	"active" : true,
	"currentOpTime" : "2018-04-17T18:51:33.523+0100",
	"opid" : "shard02:9214",
	"op" : "none",
	"ns" : "",
	"command" : {
 
	},
	"numYields" : 0,
	"locks" : {
 
	},
	"waitingForLock" : false,
	"lockStats" : {
 
	}
}
{
	"shard" : "shard03",
	"host" : "SEELE:27025",
	"desc" : "ReplBatcher",
	"active" : true,
	"currentOpTime" : "2018-04-17T18:51:33.524+0100",
	"opid" : "shard03:9192",
	"op" : "none",
	"ns" : "",
	"command" : {
 
	},
	"numYields" : 0,
	"locks" : {
 
	},
	"waitingForLock" : false,
	"lockStats" : {
 
	}
}
...
{
	"shard" : "shard01",
	"host" : "SEELE:27019",
	"op" : "getmore",
	"ns" : "admin.$cmd",
	"command" : {
		"getMore" : NumberLong("7629546417730682760"),
		"collection" : "$cmd.aggregate",
		"batchSize" : NumberLong(101),
		"$db" : "admin"
	},
	"originatingCommand" : {
		"aggregate" : 1,
		"pipeline" : [
			{
				"$currentOp" : {
					"idleConnections" : true
				}
			}
		],
		"fromMongos" : true,
		"needsMerge" : true,
		"cursor" : {
			"batchSize" : 0
		},
		"$readPreference" : {
			"mode" : "secondary"
		},
		"$db" : "admin"
	},
}
...

Comment by Ofer Cohen [ 12/Aug/15 ]

This feature is a must-to-have, because it's the only way to monitor easily large cluster queries (and other operations).

Comment by stronglee [ 11/Jan/13 ]

I connected to a mongos and I did the query on this mongos.

Please consider my case:
My app connects to a cluster via a mongos, and run the queries using 'Secondary' read preference.
Some times time consuming queries will be made and I just want a way to stop these queries to avoid dragging down the servers.

Comment by Eliot Horowitz (Inactive) [ 10/Jan/13 ]

Which node were you connected to?
You need to connect to the node on which you want to view/kill the ops.

Generated at Thu Feb 08 03:16:39 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.