[SERVER-32911] Remove heartbeat version field, "hbv", from the heartbeat command once outgoing connections to last-stable binaries are closed on FCV upgrade Created: 25/Jan/18  Updated: 06/Dec/22

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

Type: Improvement Priority: Major - P3
Reporter: Dianna Hohensee (Inactive) Assignee: Backlog - Replication Team
Resolution: Unresolved Votes: 0
Labels: neweng
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Issue Links:
Gantt Dependency
has to be done after SERVER-32636 Close outgoing connections to servers... Closed
Assigned Teams:
Replication
Participants:

 Description   

The heartbeat version field was added in v3.6 to stop communication with v3.4 nodes when FCV 3.6 is set. v3.6 do so by adding a "hbv" field to heartbeat requests, which v3.4 nodes receive and validate that no unexpected fields are present in the request – v3.4 does not expect 'hbv', so it fails the command.

SERVER-32636 will close outgoing connections to old binary nodes on FCV upgrade. v3.8 (like v3.6) nodes will be unable to establish connections with older nodes once FCV is upgraded. Closing outgoing connections on FCV upgrade closes the loophole of v3.8 and v3.6 nodes continuing to communicate via previously established connections, and the heartbeat version check will be no longer needed.

See SERVER-31631 for history of heartbeat version.



 Comments   
Comment by Dianna Hohensee (Inactive) [ 28/Feb/18 ]

Currently the 'hbv' field is effecting nothing. Both v4.0 and v3.6 mongods send and receive the field, and nothing errors.

The field should be removed eventually since it's not performing any function. However, it's totally benign in the meantime. May need some kind of backwards compatible removal over two releases.

Moving the ticket over to replication to remove eventually. Probably backlog worthy to wait for the next new replication engineer.

Generated at Thu Feb 08 04:31:41 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.