summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorSage Weil <sage@inktank.com>2013-07-15 10:05:37 -0700
committerSage Weil <sage@inktank.com>2013-07-15 10:05:37 -0700
commit8c178e0d39d8d4a4820eb061f79d74f95e60199f (patch)
tree787731650d5506099028e4fab0b00b4a642b9545
parent6af0ed9bc4cc955f8c30ad9dc6e9095599f323d0 (diff)
downloadceph-8c178e0d39d8d4a4820eb061f79d74f95e60199f.tar.gz
mon: once sync full is chosen, make sure we don't change our mind
It is possible for a sequence like: - probe - first probe reply has paxos trim that indicates a full sync is needed - start sync - clear store - something happens that makes us abort and bootstrap (e.g., the provider mon restarts - probe - first probe reply has older paxos trim bound and we call an election - on election completion, we crash because we have no data. Non-determinism of the probe decision aside, we need to ensure that the info we share during probe (fc, lc) is accurate, and that once we clear the store we know we *must* do a full sync. This is a backport of aa60f940ec1994a61624345586dc70d261688456. Fixes: #5621 Signed-off-by: Sage Weil <sage@inktank.com> Reviewed-by: Greg Farnum <greg@inktank.com>
-rw-r--r--src/mon/Monitor.cc4
1 files changed, 4 insertions, 0 deletions
diff --git a/src/mon/Monitor.cc b/src/mon/Monitor.cc
index 6a91215d31e..127754f01f6 100644
--- a/src/mon/Monitor.cc
+++ b/src/mon/Monitor.cc
@@ -1523,6 +1523,10 @@ void Monitor::sync_start(entity_inst_t &other)
set<string> targets = get_sync_targets_names();
store->clear(targets);
+ // make sure paxos knows it has been reset. this prevents a
+ // bootstrap and then different probe reply order from possibly
+ // deciding a partial or no sync is needed.
+ paxos->init();
// assume 'other' as the leader. We will update the leader once we receive
// a reply to the sync start.