必须先让Ceph主动释放故障OSD数据职责再换盘，否则新盘上线会反复读取坏扇区引发持续backfill、recovery和I/O hang；需通过dmesg、smartctl、ceph-volume list和ceph health detail交叉验证是否真为物理损坏，再严格按ceph osd out→stop→crush rm→auth del→rm/purge顺序操作，最后用ceph-volume lvm zap和prepare重建并手动reweight。
直接换盘不等于数据安全迁移，必须先让 Ceph 主动释放故障 OSD 的数据职责，再物理更换，否则新盘上线后集群会反复尝试读取坏扇区，触发持续 backfill、recovery 和 I/O hang。
怎么确认是物理硬盘损坏而不是临时掉线
不能只看 ceph osd tree 显示 down 就动手。先登录对应节点，用这些命令交叉验证：
-
dmesg -T | grep -i "sdk1\|error\|fail"—— 查看内核是否报 I/O 错误、sector read failure 或 end_request 超时 -
smartctl -a /dev/sdk1 | grep -E "(Reallocated_Sector_Ct|Current_Pending_Sector|UDMA_CRC_Error_Count)"—— 任一值 > 0 就说明物理层已不可靠 -
ceph-volume lvm list | grep sdk1—— 确认该盘是否还被 Ceph 认作有效 data 设备；若无输出或显示broken，基本可判报废 -
ceph health detail | grep -A5 "OSD_DOWN\|PG_DAMAGED"—— 若出现inconsistentPG，说明已有对象校验失败，不能再等
移除故障 OSD 的关键顺序不能错
顺序颠倒会导致 ceph osd rm 失败、pvremove 卡死，甚至引发元数据损坏。以下命令必须逐条执行、每步确认成功后再继续：
-
ceph osd out osd.197—— 先标记为 out，让 CRUSH 开始迁出主 PG，避免新写入 -
systemctl stop ceph-osd@197—— 必须停进程，否则crush rm后它可能还在跑并上报 up 状态 -
ceph osd crush rm osd.197—— 从 CRUSH map 移除，这是触发数据重平衡的起点 -
ceph auth del osd.197—— 清理认证密钥，避免残留 keyring 干扰后续 prepare -
ceph osd rm 197—— 最后才删 OSD 记录；Jewel 及之后版本推荐用ceph osd purge 197 --yes-i-really-mean-it更彻底
执行完立刻跑 ceph -s，确认状态变为 HEALTH_WARN 且 recovery 进度在上涨，才算真正启动重平衡。
擦除新盘并重建 OSD 的实操要点
新盘不是插上就能用。LVM metadata、旧 UUID、残留 superblock 都会导致 ceph-volume lvm prepare 报 device is in use 或静默失败：
- 先用
lsblk确认新盘设备名（如/dev/sdk1），再执行：ceph-volume lvm zap /dev/sdk1 --destroy—— 强制清空 LVM label 和 filesystem signature - 如果原 OSD 是 BlueStore，新盘必须用
--bluestore；FileStore 已淘汰，别再用--filestore - prepare 命令里不要指定
--osd-id—— 让 Ceph 自动分配新 ID，避免 ID 冲突或 CRUSH map 错位；正确写法：ceph-volume lvm prepare --bluestore --data /dev/sdk1 - prepare 成功后，手动运行
systemctl start ceph-osd@，再检查ceph osd tree是否显示up且权重正常
重平衡期间必须盯住的三个指标
数据平移不是“开始就完事”，卡在 99%、反复 retry、IO 打满导致业务延迟，都是常见但容易被忽略的问题：
-
ceph -s中的recovery io和backfill io数值 —— 若长期为 0，说明 CRUSH weight 为 0 或新 OSD 未激活；若持续 > 100MB/s 且宿主机 iowait > 50%，需临时限速：ceph tell osd.* injectargs '--osd-max-backfills 2 --osd-recovery-max-active 1' -
ceph pg dump_stuck inactive—— 出现 stuck inactive PG，大概率是新 OSD 的bluefs分区空间不足或 journal device 不可用 -
ceph osd df中新 OSD 的VAR列（used/size 比值）增长是否线性 —— 若某段时间停滞，立即查该 OSD 日志：journalctl -u ceph-osd@，重点搜-n 100 --no-pager ERROR和ENOSPC
最易被跳过的环节是：换盘后没等 ceph -s 回到 HEALTH_OK 就认为完成。实际中，即使 recovery 完成，CRUSH weight 默认仍是 0，需手动 ceph osd reweight osd. 才算真正回归服务流量。这个值不调，新盘永远只存冷数据，热数据仍压在其他 OSD 上。
