Loading...

XML

Word

Printable

JSON

Type: Task
Resolution: Fixed
Priority: Major - P3
Fix Version/s: 3.6.0-rc2
Affects Version/s: None
Component/s: Replication
Labels:
None

Backwards Compatibility:
Fully Compatible
Sprint:
Repl 2017-10-23, Repl 2017-11-13
Linked BF Score:
0
Confidence Status:
None
Work Order:
3

Aha! Reference:
None
Tracking Level:
None
Risk Status:
None
Exec Notes:
None
Goal Name:
None
Goal Link:
None

~~SERVER-31019~~ will not fail initial sync if the upgrade/downgrade began before initial sync and finishes after. Having UUIDs get added while initial sync is occurring sounds potentially dangerous. Additionally, ~~SERVER-29452~~ forces 3.6 binaries to fail to start up if there is no featureCompatibilityVersion document. They should therefore fail to initial sync from sources that do not have a featureCompatibilityVersion document.

depends on

SERVER-31634 FeatureCompatibilityVersion::setIfCleanStartup() should store FCV=3.4 for shardsvrs

Closed

is depended on by

SERVER-29452 Handle missing featureCompatibilityVersion document during startup

Closed

is duplicated by

SERVER-86142 Handle FCV change during initial sync while copying collections with recordIdsReplicated:true

Closed

is related to

SERVER-31019 Changing fCV during initial sync leads to divergent data across replica set members

Closed

SERVER-31607 Remove FeatureCompatibilityVersionInfo struct

Closed

Assignee:: Judah Schvimer
Reporter:: Judah Schvimer
Participants:: Githook User, Judah Schvimer, Maria van Keulen, Spencer Brody
Votes:: 0 Vote for this issue
Watchers:: 5 Start watching this issue

Created:: Sep 25 2017 09:44:06 PM UTC
Updated:: Feb 16 2024 08:30:33 PM UTC
Resolved:: Oct 27 2017 03:40:10 PM UTC
Confidence Status Last Update:: 17/Oct/17 5:45 PM

Details

Description

Attachments

Issue Links

Activity

People

Dates