[SERVER-12419] mongos GLE does not work correctly if previous write was from a command Created: 21/Jan/14  Updated: 11/Jul/16  Resolved: 31/Jan/14

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

Type: Bug Priority: Critical - P2
Reporter: Randolph Tan Assignee: Eric Milkie
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
Duplicate
is duplicated by SERVER-7739 getLastError does not work with dropD... Closed
is duplicated by SERVER-12474 mongos gle no longer returns updatedE... Closed
Related
related to SERVER-12535 aggregation $out should take a write ... Closed
is related to SERVER-12559 GLE does not report auth failures for... Closed
is related to SERVER-12623 make mongos write commands store last... Closed
Operating System: ALL
Participants:
Linked BF Score: 0

 Description   

... other than write commands.

For example, if you run the 'create' command and call gle, w: 2, it never actually gets sent to the shards!

We also need to confirm this on other commands that can do writes:

  • aggregate (with $out)
  • copydb
  • create
  • drop
  • dropDatabase
  • dropIndexes
  • findAndModify
  • mapReduce (with $out)
  • renameCollection

And in this list, we need to make sure the writeConcern parameter works correctly:

  • createRole
  • createUser
  • dropAllRolesFromDatabase
  • dropAllUsersFromDatabase
  • dropRole
  • dropUser
  • grantPrivilegesToRole
  • grantRolesToRole
  • grantRolesToUser


 Comments   
Comment by Githook User [ 05/Feb/14 ]

Author:

{u'username': u'gregstuder', u'name': u'Greg Studer', u'email': u'greg@10gen.com'}

Message: SERVER-12419 make mongos write commands report last error
Branch: master
https://github.com/mongodb/mongo/commit/a1c9bdb119919d53de74c906888a4125ed0a8ab0

Comment by Githook User [ 30/Jan/14 ]

Author:

{u'username': u'milkie', u'name': u'Eric Milkie', u'email': u'milkie@10gen.com'}

Message: SERVER-12419 switch to using a post-command hook to capture gle information
Branch: master
https://github.com/mongodb/mongo/commit/751f1101967da3593431f1b41a37867ccb169901

Comment by Githook User [ 30/Jan/14 ]

Author:

{u'username': u'milkie', u'name': u'Eric Milkie', u'email': u'milkie@10gen.com'}

Message: SERVER-12419 fix error status codes to match what batch_downconvert expects
Branch: master
https://github.com/mongodb/mongo/commit/0455a09b22d2e5fc7d0fa47e0fd8f83a9d3e03e6

Comment by Githook User [ 30/Jan/14 ]

Author:

{u'username': u'milkie', u'name': u'Eric Milkie', u'email': u'milkie@10gen.com'}

Message: SERVER-12419 Fix commands from mongos and GLE
Branch: master
https://github.com/mongodb/mongo/commit/b24de3a4b00cf2023a99b42c5a7e4ff5c2f0c4f7

Comment by Githook User [ 30/Jan/14 ]

Author:

{u'username': u'milkie', u'name': u'Eric Milkie', u'email': u'milkie@10gen.com'}

Message: SERVER-12419 add electionId to mongos batch response structure

Note that this will require some modifications/backporting to 2.4.10 for full support.
Branch: master
https://github.com/mongodb/mongo/commit/f83e6f60ab26f037b686d54168376fa1c8df82ce

Comment by Githook User [ 30/Jan/14 ]

Author:

{u'username': u'milkie', u'name': u'Eric Milkie', u'email': u'milkie@10gen.com'}

Message: SERVER-12419 Add support for electionId in replsets and wElectionId in GLE command
Branch: master
https://github.com/mongodb/mongo/commit/a40d78d52823547b5cfe8de8b50edb95b45cf902

Comment by Githook User [ 30/Jan/14 ]

Author:

{u'username': u'milkie', u'name': u'Eric Milkie', u'email': u'milkie@10gen.com'}

Message: SERVER-12419 standardize on one type for HostOpTimeMaps
Branch: master
https://github.com/mongodb/mongo/commit/dbc5a216866359da39c9a43a5f52cd28df8cb60c

Comment by Eric Milkie [ 23/Jan/14 ]

Note that this is problematic for talking to 2.4 shards as well. The code currently only records the ConnectionString and the optime; it doesn't record the state of the replica set. So if mongos calls getLastError on 2.4 replica set shards, it may not work correctly if the primary has moved.
This problem will be solved by the same fix as above; we will include an election id along with the optime for each shard ConnectionString that we store in our HostOpTimeMap.

Comment by Eric Milkie [ 21/Jan/14 ]

Current plan is to fetch the current internal optime to simulate the current behavior of calling getLastError with a write concern after a non-write command on mongos.

Commands on mongod will append the last written optime and the election id (which will uniquely identify a primary's term) to the command response, if responding to a mongos. This will be detected via ShardingState::needCollectionMetadata().
getLastError on mongod will take a new optional parameter, an election id (OID). If the objectID passed in does not match the current election id, the command will return an error as the primary has moved since the write occurred.

After running a command, mongos will need to remember the last primary it talked to, in addition to the optime and election id embedded in the command response. Upon receipt of a getLastError command, if the previous write was not a Write Command, mongos will need to issue getLastError to the proper primary node, passing in the optime and election id that it received from the command's response.

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