-
Type: New Feature
-
Resolution: Won't Fix
-
Priority: Major - P3
-
None
-
Affects Version/s: None
-
Component/s: Upgrade/Downgrade
-
None
As of SERVER-29350, a last-stable binary version secondary in a replica set cannot replicate from a latest binary version primary once the primary's featureCompatibilityVersion has been set to the latest version. Instead, its attempts to send heartbeats to the primary will fail with IncompatibleServerVersion errors. Rather than continuously sending these failing heartbeats, a last-stable binary version secondary in this state should gracefully fail. This framework should be available for all last-stable binary versions >= 3.8.
A proposed implementation to detect this scenario and crash upon detection follows:
- If a node detects IncompatibleServerVersion errors upon sending heartbeats to a majority of the nodes in a replica set, it should crash. It is necessary to detect these errors from a majority of the nodes to make sure node availability is not hindered in the event that there are multiple last-stable binary version nodes.
- This detection will be performed by the replication coordinator. The replication coordinator will conclude that a node has become isolated when the heartbeats the node sends fail with IncompatibleServerVersion errors from a majority. This high-level implementation is justifiable because we only want a last-stable binary version mongod to crash in the event that it is part of a latest featureCompatibilityVersion replica set.
- is related to
-
SERVER-29428 Make 3.4 mongod fail gracefully in featureCompatibilityVersion 3.6 cluster
- Closed