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 533c4a893f6a08bf1444a1f75528f82ff04f34cb..0e1ac455b6e07001450fbdd08f641143643b29b1 100644 (file)
--- a/src/mon/MDSMonitor.cc
+++ b/src/mon/MDSMonitor.cc
@@ -1903,9 +1903,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