summaryrefslogtreecommitdiff
path: root/src/mongo/db/s/resharding
diff options
context:
space:
mode:
authorBrett Nawrocki <brett.nawrocki@mongodb.com>2022-03-30 17:45:33 +0000
committerEvergreen Agent <no-reply@evergreen.mongodb.com>2022-04-01 22:02:53 +0000
commit0425d814900d230115ea0e1b91fadf8ee2352919 (patch)
treeb434e68a062ce26c829f55d3c8c8dc1282546720 /src/mongo/db/s/resharding
parent362859101de94cf094ae82e6b029b9a22d0d3bd5 (diff)
downloadmongo-0425d814900d230115ea0e1b91fadf8ee2352919.tar.gz
SERVER-65047 Strengthen guarantees for resharding aborting across FCVs
Previously, resharding operations were aborted after sending the request to finalize the FCV version on the shards when upgrading, making it is possible that a resharding recipient will update its FCV to its target value prior to aborting. It was therefore not possible to differentiate a resharding operation that has upgraded to the latest version since starting from one that has been the latest version throughout. For this reason, the resharding operations are now aborted first. Furthermore, the resharding command currently ensures that the FCV cannot change while setting up the coordinator. However, it did not check to make sure that the current FCV is not currently in an upgrading or downgrading state. After making the above change, this would allow for the possibility for a new resharding operation to begin during an FCV upgrade, after resharding operations are aborted, but before the shards complete the FCV upgrade. This would have the consequence of the operation running across FCVs without being aborted. As such, the reshard command now fails if the current FCV is either upgrading or downgrading. These changes in combination should guarantee that during a version change, a new resharding operation cannot begin and a previously running resharding operation always aborts completely before reaching the target version. Note that it is still possible for a resharding operation to reach an upgrading or downgrading FCV before being aborted. These changes were made in the interest of being able to assert that newly added optional fields that should always be set were indeed set. As such, this change also enables the assertion disabled by SERVER-65039.
Diffstat (limited to 'src/mongo/db/s/resharding')
-rw-r--r--src/mongo/db/s/resharding/resharding_metrics_new.cpp10
1 files changed, 7 insertions, 3 deletions
diff --git a/src/mongo/db/s/resharding/resharding_metrics_new.cpp b/src/mongo/db/s/resharding/resharding_metrics_new.cpp
index 6c80bd77e47..1d2f883d46c 100644
--- a/src/mongo/db/s/resharding/resharding_metrics_new.cpp
+++ b/src/mongo/db/s/resharding/resharding_metrics_new.cpp
@@ -61,11 +61,15 @@ BSONObj createOriginalCommand(const NamespaceString& nss, BSONObj shardKey) {
}
Date_t readStartTime(const CommonReshardingMetadata& metadata, ClockSource* fallbackSource) {
- const auto& startTime = metadata.getStartTime();
- if (startTime.has_value()) {
+ try {
+ const auto& startTime = metadata.getStartTime();
+ tassert(6503901,
+ "Metadata is missing start time despite feature flag being enabled",
+ startTime.has_value());
return startTime.get();
+ } catch (const DBException&) {
+ return fallbackSource->now();
}
- return fallbackSource->now();
}
} // namespace