[SERVER-79269] Invariant that we don't check FCV in oplog application Created: 24/Jul/23  Updated: 21/Aug/23

Status: Open
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Task Priority: Major - P3
Reporter: Judah Schvimer Assignee: Backlog - Replication Team
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to SERVER-49748 Initial sync should clone admin.syste... Closed
is related to SERVER-36498 Remove 'config.transactions' entries ... Closed
is related to SERVER-70202 Investigate calling serverGlobalParam... Closed
is related to SERVER-79317 Provide more documentation and helper... Closed
Assigned Teams:
Replication
Participants:

 Description   

Oplog application should do exactly what the primary does, and not check FCV. FCV should only be checked on the primary. We should be able to invariant that FCV is only checked on primary nodes. This should make code like SERVER-49748 unnecessary. If in adding this invariant we discover places where we check FCV, we should understand why they do so and correct them.



 Comments   
Comment by Judah Schvimer [ 14/Aug/23 ]

In triage 2 concerns came up:
1. Some changes to how we generate implicitly replicated data could require FCV checks.
2. If a feature flag on the primary requires checking FCV, and the secondary code passes through the feature flag, it will also check FCV (even though it's unnecessary). We would need to provide a way to bypass that FCV check on the secondary, or make sure all feature flags that gate on FCV are checked outside of the secondary oplog application path.

Generated at Thu Feb 08 06:40:33 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.