MDSMonitor: do not assign standby-replay when degraded

The journal (or potentially other rank metadata) may be in the process of being
migrated or modified.

Fixes: http://tracker.ceph.com/issues/36384
Signed-off-by: Patrick Donnelly <pdonnell@redhat.com>
(cherry picked from commit 065e98edfb26c1bbf9779e1094b966ac428247c5)

diff --git a/src/mon/MDSMonitor.cc b/src/mon/MDSMonitor.cc
index 7be5f14f77a65b808a1103974a4829587eb50b46..4cc066fc6ec7ec9ed0ca676d76de8f36629f5fd3 100644 (file)
--- a/src/mon/MDSMonitor.cc
+++ b/src/mon/MDSMonitor.cc
@@ -2173,9 +2173,10 @@ bool MDSMonitor::maybe_promote_standby(FSMap &fsmap, std::shared_ptr<Filesystem>
        do_propose = true;
       }
     }
-  } else {
+  } else if (!fs->mds_map.is_degraded()) {
     // There were no failures to replace, so try using any available standbys
-    // as standby-replay daemons.
+    // as standby-replay daemons. Don't do this when the cluster is degraded
+    // as a standby-replay daemon may try to read a journal being migrated.
 
     // Take a copy of the standby GIDs so that we can iterate over
     // them while perhaps-modifying standby_daemons during the loop