[DOCS-13482] Investigate changes in SERVER-46288: Reconfig in 4.2 style with the current config on FCV downgrade Created: 02/Mar/20  Updated: 13/Nov/23  Due: 20/Mar/20  Resolved: 19/Mar/20

Status: Closed
Project: Documentation
Component/s: manual
Affects Version/s: None
Fix Version/s: 4.3.4, Server_Docs_20231030, Server_Docs_20231106, Server_Docs_20231105, Server_Docs_20231113

Type: Task Priority: Major - P3
Reporter: Backlog - Core Eng Program Management Team Assignee: Kay Kim (Inactive)
Resolution: Works as Designed Votes: 0
Labels: docs-administration
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Documented
documents SERVER-46288 Reconfig in 4.2 style with the curren... Closed
Related
is related to DOCS-13408 Investigate changes in SERVER-46089: ... Closed
is related to DOCS-13610 Investigate changes in SERVER-47189: ... Closed
Participants:
Days since reply: 3 years, 46 weeks, 6 days ago
Epic Link: DOCS: 4.4 Server Release Work

 Description   

Description

Downstream Change Summary

FCV downgrade from 4.4 to 4.2 does a reconfig automatically and waits for the new config to replicate on all nodes in the replica set, including non-voting nodes and arbiters.

Description of Linked Ticket

Safe reconfig introduces a new field on the config which will make 4.2 binary to fail to start up. Now that we allow 4.4 binary to use and store a config with the new field. We cannot just remove the extra field on downgrade on each node as in SERVER-45092, since in mixed version replset, a reconfig can propagate the config with the extra field to 4.4 binary with FCV 4.2. That will fail 4.2 binary after downgrade.

Instead, we'll do a reconfig with a higher config version but no term if the last config has a term field with the same configuration and wait for it to replicate to all nodes before downgrading FCV.

Also remove the FCV check in ReplSetHeartbeatArgsV1::addToBSON, we don't need to check FCV to decide whether to include "configTerm" in heartbeats.

Scope of changes

Impact to Other Docs

MVP (Work and Date)

Resources (Scope or Design Docs, Invision, etc.)



 Comments   
Comment by Kay Kim (Inactive) [ 19/Mar/20 ]

Thanks much. I think we're all set w/o needing extra documentation since on:

https://docs.mongodb.com/master/release-notes/4.4-downgrade-replica-set/#downgrade-feature-compatibility-version-fcv

where we already

  • Ensure that no replica set member is in ROLLBACK or RECOVERING state.
  • And ensure that all members of the replica set reflect the updated featureCompatibilityVersion
Comment by Siyuan Zhou [ 19/Mar/20 ]

This is separate from the proposal of arbiter work which we decided not to do. We run a reconfig automatically on FCV downgrade and wait for it to replicate to all nodes. That's a stronger requirement than waiting for FCV to replicate to a majority of nodes, but we already expect all nodes to be alive on FCV downgrade, so this behavior may not noticeable by users. I'd trust Doc team's judgement on whether this is worth documenting.

Generated at Thu Feb 08 08:07:55 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.