SECONDARY节点数据明显落后是复制延迟（replication lag），非不同步；常见原因包括磁盘I/O瓶颈、网络抖动、oplog过小或节点负载过高；optimeDate落后超10分钟且日志出现“could not find base oplog entry”时需人工干预，如调大oplog或重置同步。
副本集节点状态显示 SECONDARY 但数据明显落后
这通常不是“不同步”，而是延迟复制（replication lag）——SECONDARY 节点还没来得及应用主节点的 oplog。先确认是否真滞后：连接到该节点，执行 db.printSlaveReplicationInfo()（MongoDB 4.4+ 已弃用，改用 rs.printSlaveReplicationInfo()），或查 rs.status().members[n].optimeDate 和 rs.status().members[0].optimeDate 对比时间差。
常见诱因包括：磁盘 I/O 瓶颈、网络抖动、oplog 太小导致被覆盖、SECONDARY 节点负载过高（比如同时跑备份或慢查询）。不要急着“强制同步”，先看 rs.status().members[n].health 是否为 1，stateStr 是否稳定为 SECONDARY。
- 如果
optimeDate落后超过 10 分钟，检查该节点的mongod日志里是否有replSet warning: too much time has passed或oplog gap detected - 若日志出现
could not find base oplog entry，说明 oplog 已被覆盖，自动同步失效，必须人工干预 - 临时缓解可降低写入压力，或调大 oplog —— 通过
db.adminCommand({replSetResizeOplog: 1, size: 10240})（单位 MB，需在 PRIMARY 上执行，且仅对 WiredTiger 有效）
SECONDARY 节点卡在 STARTUP2 或反复切换 RECOVERING
这表示节点无法完成初始同步（initial sync）或追同步失败。根本原因通常是：本地数据目录损坏、磁盘空间不足、网络中断导致同步中断后未清理残留、或 oplog 不连续。
典型错误日志包含：Failed to fetch missing oplog entries、Cannot read from oplog、Invalid replica set config（配置版本不一致）。此时不能靠重启解决，必须重置同步起点。
- 停掉该节点的
mongod进程，清空其dbPath下所有文件（保留mongod.lock可删，journal目录也建议清空） - 确保该节点能连通 PRIMARY，且防火墙放行 27017 及内部通信端口
- 重启
mongod，它会自动触发全量初始同步（initial sync）——从 PRIMARY 拉取完整数据快照 + 回放 oplog。注意：此过程占用大量磁盘 IO 和网络带宽，避免在业务高峰进行 - 监控
rs.status().members[n].syncSourceHost是否已选定，以及rs.status().members[n].stateStr是否逐步变为STARTUP2 → RECOVERING → SECONDARY
手动触发全量同步失败后如何安全重建 SECONDARY
当初始同步卡死（比如 stuck at Cloning data）、或同步中途崩溃多次，继续等待只会浪费资源。最稳妥的做法是：用 PRIMARY 的当前快照冷拷贝替代网络同步。
前提：PRIMARY 节点启用 journal 且运行中，目标 SECONDARY 节点已停机，且两者 MongoDB 版本完全一致（含 patch 版本，如 6.0.15）。
- 在 PRIMARY 上执行
db.fsyncLock()（锁定写入），再用cp -r /var/lib/mongodb/* /tmp/primary-snapshot/做一次文件系统快照（确保原子性，推荐用rsync --archive --delete） - 将快照复制到目标节点的
dbPath目录（如/var/lib/mongodb），并chown mongodb:mongodb权限 - 启动目标节点前，删除其
local数据库目录下的system.replset文件（否则会沿用旧配置） - 启动后，该节点会以“空配置”加入集群，PRIMARY 自动将其纳入配置 —— 无需手动
rs.add()，但需确认rs.conf()中该节点host字段与实际一致
修复后验证数据一致性不能只看 rs.status()
rs.status() 显示所有节点 stateStr 是 PRIMARY 或 SECONDARY，不代表数据一致。oplog 时间戳对齐只是“操作序列”一致，不保证文档级最终一致（比如写入时发生冲突、应用层逻辑异常、或 bulkWrite 中部分失败）。
真正有效的验证方式是：抽样比对关键集合的文档数、校验和、以及业务敏感字段（如订单状态、余额）。
- 在 PRIMARY 和各 SECONDARY 上分别执行：
db.collection.stats().count和db.collection.aggregate([{$group: {_id: null, sum: {$sum: "$amount"}}}]) - 对小集合可直接导出哈希：
db.collection.find().sort({_id:1}).map(d => Object.values(d).join("")).reduce((a,b) => a+b, "").hash()（注意内存限制，慎用于大集合） - 生产环境建议用
mongoexport导出主键 + 关键字段，用diff或脚本逐行比对；更可靠的是部署mongodbdump --oplog后做二进制比对
修复完成后，最容易被忽略的是 oplog 容量是否仍够用——尤其在经历大写入后，务必用 db.getReplicationInfo() 检查 timeDiffHours 是否低于 24 小时，否则下次故障可能又触发不可恢复的 oplog gap。
