Problem:
A customer was trying to edit a user's email address via the Admin -> mongodb page via db.users.update(...
They received an error in the response when submitting the command/query to mongodb:
WriteCommandError({
"operationTime" : Timestamp(1650314522, 26),
"ok" : 0,
"errmsg" : "not master",
"code" : 10107,
"codeName" : "NotMaster",
"$clusterTime" : {
"clusterTime" : Timestamp(1650314522, 26),
"signature" : {
"hash" : BinData(0,"0jl1YuG4GvHKjhpT7RQ7no/Dzic="),
"keyId" : NumberLong("7086209899641700355")
}
}
})
Background:
There are multiple listening copies of your mongodb, for the sake of redundancy and high availability, etc, called replicasets. Only one of the replicasets can act on write operations and this is called "primary" or "master". This error simply means your command/query landed on one of the replicasets which isn't the "master".
Resolution:
Unfortunately the connections via the Admin -> mongodb page are primarily meant for reading, so they hit the replicaset and don't have a means to specify that the connection go to Master/Primary. Thus your only option is to run the query a few times til you load-balancing nature results in the query landing on the proper replicaset that can perform the write.
UPDATE:
5.1.0, 5.1.1 witness a bug in which the UI is only attaching to a replicaset which isn't primary, no round-robin'ing is happening, thus you cannot perform write operations. This is resolved in 5.1.4, 5.2.0, and unfortunately in those versions the workaround is to use kubectl exec
, or restart mongo (to hopefully move around the primary vs secondary status of the replicateset) to perform an update.
Comments
0 comments
Please sign in to leave a comment.