不能直接挂载现有MongoDB数据目录到K8s Pod启动副本集，因mongod拒绝启动：锁文件残留、UID/GID权限不匹配、WiredTiger日志与元数据状态不一致、oplog截断或replset ID不匹配均导致失败；必须通过dump/restore+增量同步三步迁移。
不能直接挂载现有 MongoDB 数据目录到 Kubernetes Pod 里启动副本集——mongod 会拒绝启动，报 Unable to lock file: /data/db/mongod.lock 或 Found data in /data/db that is not empty，根本原因是容器内 UID/GID、文件系统权限、WiredTiger 日志状态与原环境不一致，且 K8s 的 volume 挂载机制无法还原原磁盘的 inode 和 journal 状态。
为什么不能把 /data/db 直接 bind mount 进 StatefulSet
本地磁盘或 NFS 共享路径（如 /nfs/data/mongo-0）即使内容完整，被挂进容器后：
• mongod 启动时检测到 mongod.lock 文件残留，认为是异常退出，强制 abort；
• 容器默认以 mongodb 用户（UID 999）运行，但原数据可能是 root 或其他 UID 创建，导致 Permission denied；
• WiredTiger 的 WiredTiger.wt 和日志文件（WiredTigerLog.*）必须成套存在且未被截断，而跨环境挂载极易破坏一致性；
• 即使强行删锁文件启动，副本集初始化阶段也会因 oplog 截断或 replset ID 不匹配失败，日志出现 replSetReconfig should only be run on PRIMARY 或 Our replica set config is invalid or we are not a member of it。
真正可行的迁移路径：dump/restore + 增量同步
平滑迁移必须绕过“直接挂盘”这个死胡同，分三步走：
• 全量导出：在原副本集 Primary 上执行 mongodump --host rs0/old-primary:27017 --out /backup/mongodump-$(date +%F)，确保包含 admin.system.version 和 local.oplog.rs（若需增量）；
• 部署空副本集：用 StatefulSet + PVC 启动三个干净 Pod（不挂旧盘），等待 mongo-0 就绪后，在 mongo-0 上执行 rs.initiate()，再 rs.add("mongo-1.mongo:27017")、rs.add("mongo-2.mongo:27017")；
• 恢复 + 追增量：先 mongorestore --host rs0/mongo-0.mongo:27017 /backup/mongodump-2026-05-12；再用 mongotail 或自写脚本监听原 Primary 的 oplog，将新写入操作实时 replay 到新集群，直到切换流量前最后一刻停写、追完尾部 oplog。
StorageClass 和 PVC 配置必须避开常见陷阱
即便不复用旧盘，PVC 的配置也直接影响迁移后稳定性：
• volumeClaimTemplates 中 accessModes 必须为 ["ReadWriteOnce"]，MongoDB 不接受 ReadWriteMany；
• StorageClass 的 reclaimPolicy 推荐设为 Delete（非 Retain），避免误删 PVC 后残留 PV 锁死数据；
• 若用 NFS（如 192.168.32.30:/nfs/data），务必在 storageClassName 对应的 StorageClass 中设置 mountOptions: ["nfsvers=4.1","hard","intr"]，否则高并发下易出现 Input/output error；
• 所有 PVC 必须独立声明（不可共用一个 PVC 名），StatefulSet 每个 Pod 需绑定专属 PVC，否则多个 mongod 进程同时写同一份数据会直接损坏 WiredTiger 文件。
最易被忽略的一点：迁移窗口期内，原副本集的 oplog 大小必须足够容纳从 dump 开始到最终 cut-over 的全部变更。用 db.getReplicationInfo() 查看 oldestTimestamp，确保它早于 dump 时间戳；否则增量同步会丢数据。
