[SERVER-47053] Relax oplog application constraints in EMRC=false variants Created: 23/Mar/20  Updated: 29/Oct/23  Resolved: 24/Mar/20

Status: Closed
Project: Core Server
Component/s: Replication
Affects Version/s: 4.5.1
Fix Version/s: 4.7.0

Type: Bug Priority: Major - P3
Reporter: William Schultz (Inactive) Assignee: William Schultz (Inactive)
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Backports
Depends
Duplicate
is duplicated by SERVER-47132 Unable to run tests from the shell du... Closed
Related
related to SERVER-47022 Oplog application mode must be set to... Backlog
related to SERVER-21700 Do not relax constraints during stead... Closed
Backwards Compatibility: Fully Compatible
Operating System: ALL
Backport Requested:
v4.4
Sprint: Repl 2020-04-06
Participants:
Linked BF Score: 50

 Description   

When using rollbackViaRefetch, we need to relax oplog application constraints when applying oplog entries during RECOVERING before we have reached minValid. Since we do not currently set our application mode to kRecovering correctly during this period, we should relax constraints by setting oplogApplicationEnforcesSteadyStateConstraints=false in the EMRC=false variants to avoid constraint violations that cause node crashes.



 Comments   
Comment by Daniel Gottlieb (Inactive) [ 08/Jun/20 ]

Ah understood. I hadn't realized that the constraint checking was just for testing. No need to pre-emptively catch all the things!

The thought was that EMRC=false would likely be removed by 4.6, and we may not start enforcing constraints by default until 4.8 (or later)

4.8 would probably need to be aware that it can be starting on 4.6 data files.

Comment by William Schultz (Inactive) [ 08/Jun/20 ]

daniel.gottlieb That sounds like a plausible and problematic scenario. However, it should be noted that currently (e.g. in 4.4), we relax constraints by default in production, so any issues with constraint enforcement should not be "real" issues yet. In SERVER-21700 we explicitly decided to enforce constraints only in our testing infrastructure to see what bugs it might surface.

In relation to potential constraint enforcement issues with EMRC=false, our thinking was that it may be a moot point, if we start enforcing constraints in production after we have removed EMRC=false entirely. The thought was that EMRC=false would likely be removed by 4.6, and we may not start enforcing constraints by default until 4.8 (or later), so we wouldn't have to worry about the interaction of EMRC=false and constraint enforcement in production. Does that make sense? I do think the scenario you described could be a real bug, but I don't feel as compelled to test it (or fix it) if EMRC=false will be going away for good in 4.6. If that bug turned up in a real BF, then that's different, and we would probably need to determine some way to address it, at least to avoid more BFs in this development cycle.

Comment by Daniel Gottlieb (Inactive) [ 08/Jun/20 ]

william.schultz I've seen a few similar tickets filed. Can you tell me if the following case can happen and/or is handled?

  • Running with eMRC=false, do a rollback via refetch
  • After rolling back ops, we at some point take an unstable checkpoint
  • Before durably applying operations up through minValid, restart the node with eMRC=on
  • Oplog application needs to be relaxed until the node applies up to the previous minValid
Comment by Githook User [ 26/Mar/20 ]

Author:

{'name': 'William Schultz', 'username': 'will62794', 'email': 'william.schultz@mongodb.com'}

Message: SERVER-47053 Check for undefined setParameters options in servers.js
Branch: master
https://github.com/mongodb/mongo/commit/255521e38defd59ad8ffaffbc68ed63238ada62d

Comment by Githook User [ 24/Mar/20 ]

Author:

{'name': 'William Schultz', 'username': 'will62794', 'email': 'william.schultz@mongodb.com'}

Message: SERVER-47053 Don't enforce oplog application constraints on EMRC=false variant
Branch: master
https://github.com/mongodb/mongo/commit/6923fac12fdf1a1dd1ad313033b8418d69bb29ee

Comment by William Schultz (Inactive) [ 23/Mar/20 ]

It should be acceptable to set oplogApplicationEnforcesSteadyStateConstraints:false on the entire majority read concern off variant, since we expect it is likely that we will remove EMRC=false entirely (PM-1769) before the enforcement of constraints is turned on by default in production. Right now we explicitly set oplogApplicationEnforcesSteadyStateConstraints:true in our tests.

Generated at Thu Feb 08 05:13:09 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.