[SERVER-64548] Do not assume that the DatabaseVersion has always a valid timestamp Created: 16/Mar/22  Updated: 12/Jul/23  Resolved: 31/Mar/22

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

Type: Bug Priority: Major - P3
Reporter: Sergi Mateo Bellido Assignee: Kaloian Manassiev
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
Related
Operating System: ALL
Sprint: Sharding EMEA 2022-03-21, Sharding EMEA 2022-04-04
Participants:
Case:

 Description   

In 5.0 we extended the DatabeVersion with a new field: a timestamp. The idea was that this timestamp would replace another field: the uuid. As part of the setFCV(5.0) command, we patched up the information on the CSRS and asked all shards to refresh, patching up their routing and filtering information.

However, we didn't think about what happened with mongos: it could totally happen that we had a mongos under FCV 5.0 sending commands with DBVersions that didn't have timestamps. However that was not a problem because the DatabaseVersion class wasn't assuming that the timestamp was mandatory, so if it wasn't present that class was relying on the epoch field.

The problem was introduced in 5.1, when we changed the implementation of the DatabaseVersion to assume that the Timestamp was always present. The problematic scenario is when we are replacing the binaries: first we change the ones on the shards and afterwards the ones on the mongoses. Thus, it could happen that one of those stale mongoses send a command with a version that doesn't have timestamps to a shard that it is expecting them.

 


Generated at Thu Feb 08 06:00:36 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.