只能在secondary节点执行db.fsynclock()，因为primary锁住会导致全集群写入阻塞、服务不可用，而secondary锁定仅影响自身oplog应用且不中断主从同步；必须确保其处于secondary状态且未被选举风险。
必须在副本集的 secondary 节点上操作，且 db.fsyncLock() 不能在 primary 上执行——否则整个集群写入会卡死。
为什么只能锁 secondary 节点？
副本集里只有 secondary 允许短暂暂停写入而不影响服务可用性。primary 锁住后，所有写请求会阻塞，db.fsyncLock() 会持续持有全局写锁，直到 db.fsyncUnlock() 被调用；如果误在 primary 执行，应用层将感知为“数据库无响应”。secondary 锁定只影响该节点自身的本地写（比如 oplog 应用），不影响主从同步链路——只要它没被选举为新 primary，就安全。
- 检查当前节点角色：
rs.isMaster().ismaster返回false才可继续 - 确认该 secondary 处于
SECONDARY状态，而非RECOVERING或STARTUP2 - 锁定前建议先执行
rs.stepDown(60)防止它在快照过程中被意外选为 primary
LVM 快照前必须满足的三个硬性条件
缺一不可，否则快照内容不一致，恢复后可能启动失败或数据损坏。
- MongoDB 必须使用
WiredTiger存储引擎（4.0+ 默认），且journal开启（配置中storage.journal.enabled: true） - 数据目录（
dbPath）和日志目录（storage.journal.path）必须位于同一个逻辑卷（LV）下；跨卷快照无法保证原子性 - 该 LV 所在的卷组（VG）需预留足够空间——快照大小不是“备份体积”，而是“快照期间数据变更量”的上限；建议按日均写入量的 1.5 倍预估，例如日均写 20GB，快照至少配 30G
执行快照时容易忽略的关键步骤顺序
顺序错一步，备份就不可用。注意：所有命令必须在连接到目标 secondary 的 mongo shell 和系统 shell 中交替执行，不能跳步。
- 在 mongo shell 中执行：
db.fsyncLock()—— 此时该节点拒绝所有写，但仍在同步 oplog - 立刻在系统 shell 中运行：
lvcreate --size 30G --snapshot --name mdb_snap_$(date +%Y%m%d) /dev/vg0/mongodb_lv - 快照创建成功后，**马上**回到 mongo shell 执行：
db.fsyncUnlock()—— 拖延会导致 secondary 同步延迟飙升 - 挂载快照：
mkdir -p /mnt/mdb_snap; mount /dev/vg0/mdb_snap_$(date +%Y%m%d) /mnt/mdb_snap - 验证快照完整性：
ls -l /mnt/mdb_snap/data/_mdb_catalog.wt（存在即说明 WiredTiger 文件结构完整）
加密存储引擎（AES256-GCM）恢复时的致命陷阱
如果你的 MongoDB Enterprise 启用了 encryptionKeyFile + AES256-GCM，冷快照恢复后直接启动 mongod 会因 IV 重用导致数据解密失败，错误信息类似：Failed to decrypt data: invalid tag。
- 必须用
--eseDatabaseKeyRollover参数单独启动一次：mongod --config /etc/mongod.conf --eseDatabaseKeyRollover - 该命令不会启动服务，只滚动密钥并退出；之后再正常启动即可
- 此步骤不可省略，也不可与普通启动合并——否则 mongod 会报错退出
真正麻烦的不是操作多，而是所有环节都依赖时间窗口和状态判断：secondary 是否真静默、LV 是否真同卷、加密密钥是否被正确轮转。任何一个被跳过或误判，恢复出来的就是一具无法启动的“尸体”。
