[SERVER-34757] Await replication before cloning in clone_catalog_data.js test Created: 30/Apr/18  Updated: 29/Oct/23  Resolved: 30/Aug/18

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

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

Issue Links:
Depends
Backwards Compatibility: Fully Compatible
Operating System: ALL
Sprint: Sharding 2018-07-30, Sharding 2018-08-13, Sharding 2018-09-10
Participants:
Linked BF Score: 31

 Description   

A failure in clone_catalog_data.js is primarily caused because this command is meant to be called internally. When the command is run through movePrimary, the config's opTime will be gossiped. This gossiping guarantees that a stale read can't be run against the config server. When called directly, the shard running cloneCatalogData could potentially have an outdated version of the config's opTime, meaning that the requested majority commit point could be outdated as well. If the requested majority commit point is outdated, it could allow a config secondary to return outdated collection information. This happens here, causing the destination shard to create a collection it doesn't think exists yet – thus generating a new UUID in the cloning process. 

The fix for the test is to await replication (or opTime committed) before attempting to call _cloneCatalogData.



 Comments   
Comment by Githook User [ 30/Aug/18 ]

Author:

{'name': 'Blake Oler', 'email': 'blake.oler@mongodb.com', 'username': 'BlakeIsBlake'}

Message: SERVER-34757 Await replication before cloning in clone_catalog_data.js test
Branch: master
https://github.com/mongodb/mongo/commit/b53b7547a477bacc801268e01e675fc32c394cdd

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