[SERVER-54962] Test that 4.4 nodes do not silently ignore secondaryDelaySecs Created: 04/Mar/21  Updated: 29/Oct/23  Resolved: 16/Mar/21

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

Type: Bug Priority: Major - P3
Reporter: Pavithra Vetriselvan Assignee: Pavithra Vetriselvan
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: File downgrade_shard_with_secondarydelaysecs.js    
Issue Links:
Documented
is documented by DOCS-14300 Investigate changes in SERVER-54908: ... Closed
Backwards Compatibility: Fully Compatible
Operating System: ALL
Sprint: Repl 2021-03-08, Repl 2021-03-22
Participants:

 Description   

After SERVER-54908, we will also need to change 4.4 to prevent a 4.4 binary from starting up if the secondaryDelaySecs field is present. This would only occur during a manual downgrade (i.e. not using Atlas):
1. Start up shard server processes on MDB 4.9 / FCV 4.4.
2. rs.init() with secondaryDelaySecs.
3. Downgrade shard binary to MDB 4.4 / FCV 4.4 (MDB won't automatically change existing secondaryDelaySecs fields to slaveDelay since that occurs only when downgrading the FCV).
4. User now has a 4.4 binary that will silently ignore the secondaryDelaySecs field entirely.

By adding an error during startup in 4.4, the user will know that they have to change the field back to slaveDelay in order for MDB to properly use the delay field. We should document this behavior.

EDIT:
Since 4.4 will already fail to parse an invalid config and not startup, this ticket will just add a test for 5.0.



 Comments   
Comment by Githook User [ 16/Mar/21 ]

Author:

{'name': 'Pavi Vetriselvan', 'email': 'pavithra.vetriselvan@mongodb.com', 'username': 'pvselvan'}

Message: SERVER-54962 Test downgrading a shard server binary with secondaryDelaySecs
Branch: master
https://github.com/mongodb/mongo/commit/90a4e42dfaebdd401236999d1374f07490c01bfb

Generated at Thu Feb 08 05:35:03 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.