doc: talk about mon failures a bit

Signed-off-by: Sage Weil <sage@newdream.net>

diff --git a/doc/ops/manage/failures/mon.rst b/doc/ops/manage/failures/mon.rst
index 702d6fd88ca0451c2783bdedff8a1e15a39a9073..3ff650ffce44580b95719e7154071d8db0fa4da8 100644 (file)
--- a/doc/ops/manage/failures/mon.rst
+++ b/doc/ops/manage/failures/mon.rst
@@ -2,3 +2,35 @@
  Recovering from ceph-mon failure
 ==================================
 
+Any single ceph-mon failure should not take down the entire monitor
+cluster as long as a majority of the nodes are available.  If that
+is the case--the remainin nodes are able to form a quorum--the ``ceph
+health`` command will report any problems::
+
+ $ ceph health
+ HEALTH_WARN 1 mons down, quorum 0,2
+
+and
+
+ $ ceph health detail
+ HEALTH_WARN 1 mons down, quorum 0,2
+ mon.b (rank 1) addr 192.168.106.220:6790/0 is down (out of quorum)
+
+Generally speaking, simply restarting the affected node will repair things.
+
+If there are not enough monitors for form a quorum, the ``ceph``
+command will block trying to reach the cluster.  In this situation,
+you need to get enough ``ceph-mon`` daemons running to form a quorum
+before doing anything else with the cluster.
+
+
+Replacing a monitor
+===================
+
+If, for some reason, a monitor data store becomes corrupt, the monitor
+can be recreated and allowed to rejoin the cluster, much like a normal
+monitor cluster expansion.  See :ref:`adding-mon`.
+
+
+
+

diff --git a/doc/ops/manage/grow/mon.rst b/doc/ops/manage/grow/mon.rst
index 1acc204fa0ad116e61184e9f4866621b6ecfc648..fb1c93cd9a0f2f1d531dcc2abb2bb34b89baf38f 100644 (file)
--- a/doc/ops/manage/grow/mon.rst
+++ b/doc/ops/manage/grow/mon.rst
@@ -2,6 +2,8 @@
  Resizing the monitor cluster
 ==============================
 
+.. _adding-mon:
+
 Adding a monitor
 ----------------