[SERVER-19138] Add additional validation to replica set configuration for config server replica sets Created: 25/Jun/15  Updated: 30/Sep/15  Resolved: 08/Sep/15

Status: Closed
Project: Core Server
Component/s: Replication, Sharding
Affects Version/s: None
Fix Version/s: 3.1.8

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

Issue Links:
Depends
depends on SERVER-19137 Require config servers to have the --... Closed
Related
related to SERVER-19524 Support for configServer labeling of ... Closed
is related to SERVER-19762 Don't allow nodes started with --conf... Closed
Backwards Compatibility: Fully Compatible
Sprint: Sharding 7 08/10/15, RPL 9 (09/18/15)
Participants:

 Description   

Prohibit the following values for the given attributes on individual replica set members:

  1. arbiterOnly: true
  2. buildIndexes: false
  3. slaveDelay: <non-zero>


 Comments   
Comment by Andy Schwerin [ 17/Sep/15 ]

I would prefer not to enforce a node minimum.

Comment by Henrik Ingo (Inactive) [ 14/Sep/15 ]

Note that for development purposes it is common to just run with a single config server. (Just calling it out just in case.)

Comment by Eric Milkie [ 11/Sep/15 ]

Should we add a minimum number of nodes?
We could theoretically enforce at least three nodes for CSRS replica sets, as long as SCCC mode is not 'on' (which will allow the upgrade process to have a 1 node set while upgrading).

Comment by Githook User [ 08/Sep/15 ]

Author:

{u'username': u'dannenberg', u'name': u'matt dannenberg', u'email': u'matt.dannenberg@10gen.com'}

Message: SERVER-19138 Add additional validation of replica set configuration for config server replica sets
Branch: master
https://github.com/mongodb/mongo/commit/1a2251728cc269d62b580254d06a828017604918

Comment by Matt Dannenberg [ 03/Sep/15 ]

I'm planning to tackle this ticket in the near future. schwerin, spencer, renctan have you decided what all we would like to forbid?

Comment by Spencer Brody (Inactive) [ 04/Aug/15 ]

We should also consider forbidding slaveDelay, and perhaps buildIndexes:false, schwerin, what do you think?

Comment by Eric Milkie [ 01/Jul/15 ]

Yes, the answer is that in particular for CSRS, we want to make it very hard to have a situation where a primary is up but no writes are replicated to a majority of nodes.

Comment by Spencer Brody (Inactive) [ 01/Jul/15 ]

I believe it has to do with how read committed and arbiters interact, schwerin had a more concrete understanding why.

Comment by Eric Milkie [ 01/Jul/15 ]

This ticket needs a definitive list of validation points in the description.
On a side note, I don't understand why we need to prohibit arbiters.

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