[SERVER-52763] Making StaleShardVersion use the new versions with timestamps Created: 11/Nov/20  Updated: 29/Oct/23  Resolved: 26/Feb/21

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

Type: Task Priority: Major - P3
Reporter: Sergi Mateo Bellido Assignee: Sergi Mateo Bellido
Resolution: Fixed Votes: 0
Labels: PM-1965-Milestone-0-Metadata-Format
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
related to SERVER-52587 Making collection and database instan... Closed
Backwards Compatibility: Fully Compatible
Sprint: Sharding 2020-11-16, Sharding 2020-11-30, Sharding 2020-12-14, Sharding 2020-12-28, Sharding 2021-01-11, Sharding 2021-01-25, Sharding 2021-02-22, Sharding 2021-03-08
Participants:

 Comments   
Comment by Sergi Mateo Bellido [ 26/Feb/21 ]

Nothing to do in this ticket because:

  • A StaleConfigInfo has a ChunkVersion and the ChunkVersion class was extended with a Timestamp field in SERVER-53093
  • A StaleDbRoutingVersion has a DatabaseVersion and the DatabaseVersion class was extended with a Timestamp field in SERVER-52933
  • We don't have to worry about potential issues parsing the versions of stale errors in old binaries. Let's assume that we have a sharded cluster with 5.0 binaries and 5.0 FCV. If we want to downgrade our sharded cluster to BIN 4.4 FCV 4.4 first we should execute a setFCV(4.4). Once this operation is completed, we can guarantee that all the metadata in the sharded cluster is in the old metadata format, so it is safe to start replacing the 5.0 binaries by the new ones. See SERVER-53104 for more details.
Generated at Thu Feb 08 05:28:56 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.