[SERVER-31158] voting inMemory nodes should refuse to join replica sets that have writeConcernMajorityJournalDefault set to true Created: 19/Sep/17  Updated: 06/Dec/22  Resolved: 09/Apr/20

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

Type: Bug Priority: Major - P3
Reporter: Eric Milkie Assignee: Backlog - Replication Team
Resolution: Won't Fix Votes: 0
Labels: neweng
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
related to SERVER-29649 Add startupWarning when a replset nod... Closed
related to SERVER-38685 Startup warning if In-Memory SE is us... Closed
Assigned Teams:
Replication
Operating System: ALL
Participants:

 Description   

As per the docs, you must set writeConcernMajorityJournalDefault to false if you are running voting, but non-journaling, nodes in your replica set:
https://docs.mongodb.com/manual/reference/replica-configuration/#rsconf.writeConcernMajorityJournalDefault
If you do not do this, the effect will be that your majority writes may hang if a majority of nodes includes a non-journaling node.
A worse effect is that if you also use --enableMajorityReadConcern, the commit level will never advance, and so the majority snapshot never advances. This can eventually fill up cache memory with write history.



 Comments   
Comment by Siyuan Zhou [ 09/Apr/20 ]

I agree fassert on installing a config that is incompatible with the in-memory node is a clean idea. However I'm concerned that adding the constraint in 4.6 would fail upgrade surprisingly. Given that we've already added the warning and the worst case is to fail in another loud way, I'd lean towards to closing the ticket as "Won't Fix".

Comment by Eric Milkie [ 20/Sep/17 ]

I was imagining a node might refuse to accept a config where it was a voting member and the flag was set to true. That would have other repercussions of course.

I'm fine with the startup warning as 3.5 required. Feel free to close this ticket or backlog it in the meantime.

Comment by Spencer Brody (Inactive) [ 20/Sep/17 ]

Our plan for handling this was just to add a startupWarning on the inMemory node in this configuration (SERVER-29649). It's currently in 3.5 Desired but that's because I forgot that with read concern majority always on in 3.6 the situation gets worse. If we bumped that up to 3.5 Required do you think that'd be sufficient?

Comment by Spencer Brody (Inactive) [ 20/Sep/17 ]

I don't really understand this request. If a secondary is running the inMemory storage engine how would it force the primary to change its commit level calculation.

Comment by Eric Milkie [ 20/Sep/17 ]

Alternatively, an inMemory storage engine node could simply report all writes as durable even though they are not, for the purposes of replica set update position notifications.

Generated at Thu Feb 08 04:26:11 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.