MongoDB ignores version field when doing forced replSetReconfig

[Joseph Glanville]

Hi,

When applying a forced update to the replica set configuration using replSetReconfig the version field is incremented by a random amount regardless of if the operator provided a version number for the new replica set configuration.

This is problematic in the case where you want to manage the replica set by an automated external service as you need control over the version number to do this correctly.

I would expect that in the case a version number is provided that it is used and only if it's not used would a new version be generated.

Joseph.

[Dwight Merriman]

the original intent with force:true was for use in exceptional situations, when it isn't possible to establish a primary in a replica set.  the idea was that this would be rare and a manual human intervention event, as normally it could be dangerous to reconfigure without a primary as different members could accept different reconfigs from different clients.  

the random increment of the version number is to help mitigate this somewhat.  if two set members received forced reconfigs, if they both simply incremented their version #, they would end up at the same new version number, but potentially with different conifgurations.

to say another way, the idea for force:true was that it is for cases where establishing a primary is impossible forver (say if 2 servers were permanently destroyed from a 3 member set).  in theory, one might automate that, but it would require a high level of care, and should be rare, and in a situation like the example i'd want to look at the situation manually personally.

90%++ of reconfigs should be non-forced.

i don't think i answered the question but just gave the background so reply if there is more to discuss?

[Joseph Glanville]

Hi Dwight,

Sorry for the slow reply, for some reason the list replies didn't arrive in my mailbox.

Thanks for describing the original rationale, I suspected as much.

I agree the random increment is probably a useful measure in the case that an administrator is manually triggering a force reconfigure and there is the chance for operator error to issue this against more than one peer.

I also agree that force reconfigure from scripts isn't a good idea for similar reasons, mostly that most scripts do not have complete information.

However my use-case is very different. I have an external system that has complete knowledge of all MongoDB peers, oplog positions, etc and could ensure that only monotonically increasing replSetConfig version numbers are used.

Being able to apply all reconfigures with known version numbers greatly increases the safety of my usecase because otherwise if my system does actually issue a reconfigure using stale information due to a race condition that it will be properly rejected by the cluster.

Without this functionality such a system can't be made fully safe.

Would it be possible to implement a means to circumvent this random increment in the case that you really do understand the consequences?

Joseph.