[SERVER-22270] applyOps to config rs does not wait for majority Created: 21/Jan/16  Updated: 03/May/17  Resolved: 02/Feb/16

Status: Closed
Project: Core Server
Component/s: Sharding
Affects Version/s: 3.2.1, 3.3.0
Fix Version/s: 3.2.3, 3.3.2

Type: Bug Priority: Major - P3
Reporter: Randolph Tan Assignee: Judah Schvimer
Resolution: Done Votes: 0
Labels: code-and-test
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Documented
is documented by DOCS-7637 Commands that take a writeConcern Closed
is documented by DOCS-7079 applyOps takes a writeConcern Closed
Related
related to SERVER-22846 Add applyOps command to readConcern p... Closed
is related to SERVER-22269 ReadConcern: majority does not reflec... Closed
Backwards Compatibility: Fully Compatible
Operating System: ALL
Backport Completed:
Sprint: Sharding F (01/29/16), Sharding 10 (02/19/16)
Participants:

 Description   

All applyOps and writes to config replica sets should have a write concern of

{ w: 'majority', j: true }

.



 Comments   
Comment by Githook User [ 02/Feb/16 ]

Author:

{u'username': u'judahschvimer', u'name': u'Judah Schvimer', u'email': u'judah@mongodb.com'}

Message: SERVER-22270 applyOps takes a write concern

(cherry picked from commit 031193b825245e1d56d09e41b4c10652ef012579)
Branch: v3.2
https://github.com/mongodb/mongo/commit/43fe882029676fe18cbb235ee959547f8b058d65

Comment by Githook User [ 02/Feb/16 ]

Author:

{u'username': u'judahschvimer', u'name': u'Judah Schvimer', u'email': u'judah@mongodb.com'}

Message: SERVER-22270 applyOps takes a write concern
Branch: master
https://github.com/mongodb/mongo/commit/031193b825245e1d56d09e41b4c10652ef012579

Comment by Eric Milkie [ 22/Jan/16 ]

I believe that won't be a problem, as the applyOps command silently ignores any parameters it doesn't understand. We should be careful to test different upgrade scenarios regardless, though.

Comment by Andy Schwerin [ 22/Jan/16 ]

I'm a little concerned that people upgrading from 3.2.1 to a later 3.2.x
might not upgrade the binaries on configs first. We usually say that the
minor version binaries are drop in replacements.

Comment by Eric Milkie [ 21/Jan/16 ]

Agreed.

Comment by Kaloian Manassiev [ 21/Jan/16 ]

It is possible, but it will require always passing the latest optime to getLastError, because applyOps is run through the task executor, which uses a pool and we have no control over which connection will end up running getLastError.

Since upgrades always need to start with the config servers, I think it would be best if we add write concern support to applyOps and make the catalog manager pass write majority.

Comment by Eric Milkie [ 21/Jan/16 ]

Will it work if we simply call getLastError after applyOps, or do we need to expedite adding write concern support to the applyOps command?

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