能，但仅限MongoDB 5.0.22+/6.0.11+/7.0.2+版本，且必须在mongos节点执行；低版本或连错节点（如shard primary）会静默失败，锁仅作用于当前实例。
mongos 上执行 db.fsyncLock() 真的能锁住所有分片吗？
能，但仅限 MongoDB 5.0.22+ / 6.0.11+ / 7.0.2+ 版本，且必须在 mongos 节点上执行，不是任意 mongod。低版本或连错节点（比如误连 shard primary）会静默失败——锁只作用于当前连接实例，对其他分片毫无影响。
关键判断依据是返回文档中的 lockCount 字段：成功时该值应 ≥ 1，且所有 shard primary 和 config server 的写入都会被阻塞（可通过监控 mongostat 的 netIn 和 opcounters.update 骤降验证）。若某 shard 仍有写入流量，说明它没被锁住，备份必然不一致。
- 必须用具备
hostManager角色或自定义fsync权限的用户执行，普通root不行 - Atlas、云托管集群明确不支持该命令，别试
- 锁期间 balancer 自动暂停，但需额外确认
sh.getBalancerState()返回false，避免 chunk 迁移干扰
为什么不能边 dump 边保持 fsyncLock？
因为 mongodump 本身会触发 WiredTiger 检查点和 journal 刷盘，而 db.fsyncLock() 已冻结磁盘写入通道，两者冲突会导致 mongodump 卡死或报错 OperationFailed: cannot acquire lock。这不是超时问题，是底层存储引擎的互斥机制。
正确顺序只能是：先 db.fsyncLock() → 立即并行执行所有 mongodump --host <shard-primary> → 所有 dump 完成后再 db.fsyncUnlock()。dump 过程中任何写入请求都会挂起，所以窗口必须极短（通常
- dump 必须显式指定每个 shard primary 的地址，如
--host shard1a:27018，绝不能走mongos路由 - config server 也要单独 dump：
mongodump --host config1:27019 --db config - dump 命令加
--forceTableScan避免因 collection 状态异常跳过数据
fsyncLock 备份后恢复时最常踩的坑
直接 mongorestore 到原集群，90% 会出现 chunk 元数据错乱：新导入的数据无法被路由到对应 shard，查询返回空，sh.status() 显示 chunks 分布异常甚至 orphaned data 报警。
根本原因是 mongorestore 不更新 config server 的 chunks、shards、databases 三张核心集合。它只写数据，不写路由元数据。
- 必须按顺序恢复：先 restore config 数据库（含全部元数据），再逐个 restore shard 数据目录
- restore shard 时务必加
--drop（清旧数据）和--noIndexRestore（跳过索引重建，避免 chunk 边界计算错误） - 恢复后手动运行
sh.startBalancer()，并观察sh.isBalancerRunning()是否稳定为true
什么情况下 fsyncLock 方案会彻底失效？
当集群正在经历主节点选举、config server 同步延迟 > 1s、或某个 shard primary 因磁盘满/oom 被踢出副本集时，db.fsyncLock() 可能只锁住部分节点，甚至锁住一个已降级的 former-primary——此时它的 oplog 已停止更新，dump 出来的数据是陈旧的，且无任何错误提示。
这类故障无法靠脚本自动检测，必须人工介入：执行前用 sh.status() 确认无 pending chunks；用 rs.status() 在每个 shard 上验证 members[n].stateStr === "PRIMARY" 且 optimes.lastCommittedOpTime.ts 连续增长；检查所有节点 df -h 和 mongotop --host 是否正常响应。
真正高可用场景下，fsyncLock 只适合低峰期秒级快照，跨机房异地容灾或分钟级 RPO 要求，必须切到 Percona Backup 或云厂商的存储层快照方案。
