[SERVER-21603] getLastError does not wait for replication on mongos v3.0 with mongod v3.2 Created: 20/Nov/15  Updated: 25/Jan/17  Resolved: 24/Nov/15

Status: Closed
Project: Core Server
Component/s: Replication, Sharding
Affects Version/s: 3.2.0-rc3
Fix Version/s: 3.2.0-rc4

Type: Bug Priority: Major - P3
Reporter: Randolph Tan Assignee: Spencer Brody (Inactive)
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to SERVER-21586 Investigate v3.0 mongos and v3.2 clus... Closed
is related to SERVER-21631 Remove gleStats format detection base... Closed
Backwards Compatibility: Fully Compatible
Operating System: ALL
Steps To Reproduce:

Run jstests/rename.js with everything in v3.2 except for mongos (in v3.0)

Sprint: Sharding D (12/11/15)
Participants:

 Description   

getLastError on v3.0 mongos does not appear to wait for write concern after a command that writes (insert, update, remove, create. rename, findAndModify, etc).

This appears to be caused by a change in the format of $gleStats in command response from

{ ok: 1.0, $gleStats: { lastOpTime: Timestamp 1448055284000|3, electionId: ObjectId('564f91f159f75549f0be5a83') } }

in v3.0 to

{ ok: 1.0, $gleStats: { lastOpTime: { ts: Timestamp 1448054994000|4, t: 2 }, electionId: ObjectId('564f909b0000000000000002') } }



 Comments   
Comment by Githook User [ 24/Nov/15 ]

Author:

{u'username': u'stbrody', u'name': u'Spencer T Brody', u'email': u'spencer@mongodb.com'}

Message: SERVER-21603 Revert to old format for gleStats if being talked to by an old mongos
Branch: master
https://github.com/mongodb/mongo/commit/3b3ef4253a6c5d5d3f18127ac2272a9696488aec

Comment by Andy Schwerin [ 21/Nov/15 ]

milkie's proposal will work, but it would be nice to know if we can find a procedure that also allows rolling upgrade form RC3 to RC4, which as Eric describes would not be possible. It may not be possible while also allowing rolling upgrade from 3.0 to 3.2.0-rc4.

Comment by Randolph Tan [ 21/Nov/15 ]

milkie That sounds plausible and not too risky. The fields are internal, so we should have more flexibility.

Comment by Eric Milkie [ 20/Nov/15 ]

I wonder if it would work if we returned a new field in $gleStats for the new format of lastOpTime instead of changing the format of the existing field. And return both fields in the object. We could then instruct 3.2 mongos to parse the new field with the term, instead of the old one.

Comment by Randolph Tan [ 20/Nov/15 ]

Yes.

Comment by Eric Milkie [ 20/Nov/15 ]

We're prescribing upgrading mongoses last for this upgrade, correct?

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