[SERVER-40112] db.disableFreeMonitoring() returns "not master" on secondary even after rs.slaveOk() Created: 13/Mar/19  Updated: 29/Oct/23  Resolved: 05/Apr/19

Status: Closed
Project: Core Server
Component/s: Admin, Shell
Affects Version/s: 4.0.6
Fix Version/s: 4.1.10, 4.0.10

Type: Bug Priority: Major - P3
Reporter: Alexey Rogulin Assignee: Mark Benvenuto
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Backports
Backwards Compatibility: Fully Compatible
Operating System: ALL
Backport Requested:
v4.0
Steps To Reproduce:

After connecting to a secondary node in a 4.0.6 replica set:

...
To enable free monitoring, run the following command: db.enableFreeMonitoring()
To permanently disable this reminder, run the following command: db.disableFreeMonitoring()
---
 
replset:SECONDARY> rs.slaveOk()
replset:SECONDARY> db.disableFreeMonitoring()
2019-03-13T15:32:54.998-0400 E QUERY    [js] Error: command failed: {
	"operationTime" : Timestamp(1552505570, 1),
	"ok" : 0,
	"errmsg" : "not master",
	"code" : 10107,
	"codeName" : "NotMaster",
	"$clusterTime" : {
		"clusterTime" : Timestamp(1552505570, 1),
		"signature" : {
			"hash" : BinData(0,"AAAAAAAAAAAAAAAAAAAAAAAAAAA="),
			"keyId" : NumberLong(0)
		}
	}
} :
_getErrorWithCode@src/mongo/shell/utils.js:25:13
doassert@src/mongo/shell/assert.js:18:14
_assertCommandWorked@src/mongo/shell/assert.js:536:17
assert.commandWorked@src/mongo/shell/assert.js:620:16
DB.prototype.disableFreeMonitoring@src/mongo/shell/db.js:1994:9
@(shell):1:1

Sprint: Security 2019-03-25, Security 2019-04-08
Participants:

 Description   

Despite specifying rs.slaveOk(), db.disableFreeMonitoring() returns a "not master" error.

Original Description

I disabled free monitoring from shell on a primary node without issues. When I connect to a secondary node I see the message:

To enable free monitoring, run the following command: db.enableFreeMonitoring()
To permanently disable this reminder, run the following command: db.disableFreeMonitoring()

When I execute `db.disableFreeMonitoring()`, I'm getting the following error:

2019-03-13T18:46:43.618+0000 E QUERY    [js] Error: command failed: {
	"operationTime" : Timestamp(1552502797, 1),
	"ok" : 0,
	"errmsg" : "not master",
	"code" : 10107,
	"codeName" : "NotMaster",
	"$clusterTime" : {
		"clusterTime" : Timestamp(1552502797, 1),
		"signature" : {
			"hash" : BinData(0,"AAAAAAAAAAAAAAAAAAAAAAAAAAA="),
			"keyId" : NumberLong(0)
		}
	}
} :
_getErrorWithCode@src/mongo/shell/utils.js:25:13
doassert@src/mongo/shell/assert.js:18:14
_assertCommandWorked@src/mongo/shell/assert.js:536:17
assert.commandWorked@src/mongo/shell/assert.js:620:16
DB.prototype.disableFreeMonitoring@src/mongo/shell/db.js:1994:9
@(shell):1:1

 I tried to repeat that command after "rs.slaveOk()", but I got exactly the same error.

Just in case, "db.getFreeMonitoringStatus()" returns:

{
	"state" : "undecided",
	"ok" : 1,
	"operationTime" : Timestamp(1552503490, 1),
	"$clusterTime" : {
		"clusterTime" : Timestamp(1552503490, 1),
		"signature" : {
			"hash" : BinData(0,"AAAAAAAAAAAAAAAAAAAAAAAAAAA="),
			"keyId" : NumberLong(0)
		}
	}
}



 Comments   
Comment by Luke Chen [ 11/Apr/19 ]

Fixing up fixversion as this ticket was not included as part of 4.0.9 release.

Comment by Githook User [ 08/Apr/19 ]

Author:

{'name': 'Mark Benvenuto', 'username': 'markbenvenuto', 'email': 'mark.benvenuto@mongodb.com'}

Message: SERVER-40112 db.disableFreeMonitoring() returns 'not master' on secondary after restart

(cherry picked from commit b5883226855662d54f990ebb7dcfd952c037a11c)
Branch: v4.0
https://github.com/mongodb/mongo/commit/9c58f99b8c66e045881c921fb8bef70d93efc5ca

Comment by Githook User [ 05/Apr/19 ]

Author:

{'email': 'mark.benvenuto@mongodb.com', 'name': 'Mark Benvenuto', 'username': 'markbenvenuto'}

Message: SERVER-40112 db.disableFreeMonitoring() returns 'not master' on secondary after restart
Branch: master
https://github.com/mongodb/mongo/commit/b5883226855662d54f990ebb7dcfd952c037a11c

Comment by Mark Benvenuto [ 03/Apr/19 ]

I have re-opened the issue since I incorrectly closed it. I misread the bug and made a mistake in closing it.

It took me sometime to figure out this issue which is why I did not reply immediately. I thought this issue occurred if the secondary received the disableFreeMonitoring command while the secondary was running so I tried testing that case.

I took a different investigative route today. I have found an issue that does occur if a secondary replica is added or restarted after Free Monitoring is disabled. There are tested for adding/restarting nodes when free monitoring is on, but not off.

To workaround this bug, you can pass --enableFreeMonitoring=off, this will disable free monitoring permanently. If the server is started with this flag and a user runs db.enableFreeMonitoring(), Free Monitoring will not be enabled.

Comment by Alexey Rogulin [ 01/Apr/19 ]

@mark.benvenuto, you mentioned "The secondaries simply obey the state of the primary replica", but I created this bug ticket simply because they do not. I disabled free monitoring on primary through the shell command, but secondaries are still in "undecided" state and notify me about it every time I open mongo shell. They should either obey the state of the primary, or they should not suggest running that shell command if it is designed to not work on secondaries.

P.S. I could not find the button to reopen the ticket.

Comment by Mark Benvenuto [ 01/Apr/19 ]

I am closing this ticket as "Works As Designed". If you have any more questions, feel free to reopen the ticket.

Comment by Mark Benvenuto [ 18/Mar/19 ]

Free Monitoring can only be controlled on the primary replica via the commands. The secondaries simply obey the state of the primary replica. There is no way to tell free monitoring that only primaries should upload data.

If you absolutely do not want a replica to upload data, then you can pass the command-line switch - enableFreeMonitoring=off at startup to that replica. This will disable free monitoring for a given replica. Please note that even if that node becomes primary it will not upload data.

Comment by Eric Sedor [ 13/Mar/19 ]

Thanks arogulin; I can confirm your reproduction steps. We're assigning this ticket to the appropriate team to be evaluated against our currently planned work. Updates will be posted on this ticket as they happen.

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