CephCX · Monitor RecoveryMonitor Recovery
Replacing a lost monitor
What you'll learn
- Remove a failed monitor from the monmap
- Deploy a replacement through cephadm
- Rebuild a monitor store without an orchestrator
- Verify the replacement actually joined quorum
Prerequisites
None — start here.
Verified against Ceph Tentacle 20.2.x · Ceph Squid 19.2.x (supported previous) · cephadm matches the verified Ceph release · podman 4.x · csi-rbd and csi-cephfs current · RBD / CephFS / RGW current (matches Ceph release) · Linux kernel 5.15+ (5.10 minimum) · Ubuntu 24.04 LTS (Ceph host baseline) · Debian 12 (Bookworm) (Ceph host baseline) · Rocky Linux / RHEL / AlmaLinux 9.x (Ceph host baseline) · Proxmox VE 9.x (cross-course integration) · Kubernetes 1.31+ (cross-course integration) · 2026-08-18
Why this matters in production
A three-monitor cluster with one monitor dead tolerates no further failure, and the obvious repair — add the replacement, then tidy up — takes quorum down before the replacement can help.
Establish what you actually have
ceph -s
ceph mon stat
ceph orch ps --daemon-type mon
mon: 3 daemons, quorum ceph-a,ceph-c (age 41m), out of quorum: ceph-b
| Reading | Meaning |
|---|---|
| 3 daemons, quorum of 2 | the map still counts the dead monitor |
out of quorum: ceph-b | present in the map, not participating |
| Quorum requirement | a strict majority of the map size, not of live monitors |
Remove first, then add
# a healthy monitor you are removing deliberately
ceph mon ok-to-stop ceph-b
# cephadm: drop the daemon, then confirm the monmap really lost it
ceph orch daemon rm mon.ceph-b --force
ceph mon dump | grep -E '^[0-9]+:'
ceph mon remove ceph-b # only if it is still listed
# the host is gone entirely
ceph orch host rm ceph-b --offline --force
# deploy the replacement by naming the full placement
ceph orch apply mon --placement="ceph-a,ceph-c,ceph-d"
Rebuilding a monitor store by hand
Use this where there is no orchestrator, or where cephadm cannot reach the new host yet. The store is built empty and filled by synchronising from the quorum.
ceph mon getmap -o /tmp/monmap
ceph auth get mon. -o /tmp/mon.keyring
sudo -u ceph mkdir -p /var/lib/ceph/mon/ceph-ceph-d
sudo -u ceph ceph-mon --mkfs -i ceph-d \
--monmap /tmp/monmap --keyring /tmp/mon.keyring
sudo systemctl enable --now ceph-mon@ceph-d
ceph mon add ceph-d 10.0.1.14:6789
The exported monmap does not contain the new monitor. It is the map of
the cluster the monitor must find, not a description of the monitor.
Verifying
ceph quorum_status --format json | python3 -c '
import sys,json
d = json.load(sys.stdin)
mons = [m["name"] for m in d["monmap"]["mons"]]
print("in map: ", ",".join(mons))
print("in quorum:", ",".join(d["quorum_names"]))
print("tolerates", len(mons) - (len(mons)//2 + 1), "further failures")'
ceph health detail
sudo du -sh /var/lib/ceph/*/mon.ceph-d/store.db
| Check | Passing looks like |
|---|---|
| Map size | the intended count, with no ghost entry |
| Quorum names | every monitor in the map |
| Store size on the new host | comparable to the others |
ceph health detail | no MON_DOWN, no clock skew |
Quiz
Knowledge check · 4 questions
Q1. Why is the dead monitor removed from the monmap before the replacement is added?
Q2. Adding a replacement monitor before removing the failed one can drop the cluster out of quorum.
Q3. Replace a monitor whose host has failed permanently.
A three-monitor cluster has `mon.ceph-b` on a host with a dead mainboard. The cluster is HEALTH_WARN with quorum ceph-a,ceph-c. A new host ceph-d is racked and enrolled.
Q4. Why does `ceph-mon --mkfs` build an empty store rather than seeding one?
Passing score: 75%. Answers are checked in this browser.
Production discipline
Remove the failed monitor from the map before adding its replacement,
every time — growing the map raises the quorum requirement while the new
monitor is still synchronising. Build the replacement store with
ceph-mon --mkfs; copying a working monitor store produces a daemon with
a borrowed identity and a Paxos position that is not its own.
Cross-course references
- Kubernetes: etcd member removal precedes member addition for exactly the same quorum arithmetic
- Linux: cluster membership changes are safest when they shrink before they grow