[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: |
|
||||||||||||||||||||||||||||||||
| 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:
And in this list, we need to make sure the writeConcern parameter works correctly:
|
| 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: |
| Comment by Githook User [ 30/Jan/14 ] |
|
Author: {u'username': u'milkie', u'name': u'Eric Milkie', u'email': u'milkie@10gen.com'}Message: |
| Comment by Githook User [ 30/Jan/14 ] |
|
Author: {u'username': u'milkie', u'name': u'Eric Milkie', u'email': u'milkie@10gen.com'}Message: |
| Comment by Githook User [ 30/Jan/14 ] |
|
Author: {u'username': u'milkie', u'name': u'Eric Milkie', u'email': u'milkie@10gen.com'}Message: |
| Comment by Githook User [ 30/Jan/14 ] |
|
Author: {u'username': u'milkie', u'name': u'Eric Milkie', u'email': u'milkie@10gen.com'}Message: Note that this will require some modifications/backporting to 2.4.10 for full support. |
| Comment by Githook User [ 30/Jan/14 ] |
|
Author: {u'username': u'milkie', u'name': u'Eric Milkie', u'email': u'milkie@10gen.com'}Message: |
| Comment by Githook User [ 30/Jan/14 ] |
|
Author: {u'username': u'milkie', u'name': u'Eric Milkie', u'email': u'milkie@10gen.com'}Message: |
| 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. |
| 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(). 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. |