不能直接在已有数据的单节点上“升级”为副本集，必须停写、初始化、同步，否则rs.initiate()会失败或导致数据不一致；核心矛盾在于副本集要求所有节点从同一初始状态开始同步，而单节点已有的数据快照必须被所有成员共同承认。
不能直接在已有数据的单节点上“升级”为副本集——必须停写、初始化、同步，否则 rs.initiate() 会失败或导致数据不一致。核心矛盾在于：副本集要求所有节点从同一初始状态开始同步，而单节点已有的数据快照必须被所有成员共同承认。
为什么 rs.initiate() 在有数据的单节点上会失败
当你对一个已有大量数据的单节点执行 rs.initiate()，MongoDB 会尝试以该节点当前状态为“起点”创建副本集。但问题在于：
- oplog 尺寸默认很小（通常几百MB），远不足以覆盖你已有的全部变更历史；没有足够 oplog，新加入的 Secondary 无法通过增量同步追平，只能全量同步（initial sync）
- 如果此时已有客户端持续写入，
rs.initiate()可能卡在等待多数节点就绪阶段，或触发NotMasterNoSlaveOk错误 - 即使强制成功，后续添加 Secondary 时，它会因找不到可追溯的 oplog 起点而报
OplogStartMissing或直接进入STARTUP2→RECOVERING→FAILED
真正可行的三步迁移路径
绕过“原地升级”幻想，用最小停机窗口完成切换：
-
停写 + 快照备份：先停止应用写入，用
mongodump --out或文件系统快照（LVM/ZFS）保存当前完整数据。这步耗时取决于数据量，但可离线做 -
启动空副本集并恢复：用相同配置启动三个节点（含
replSetName），只在 Primary 上执行rs.initiate()；再用mongorestore把备份导入 Primary —— 此时 oplog 从恢复后第一条写开始记录，Secondary 同步安全 -
逐个添加 Secondary 并验证：Primary 恢复后，依次对每个 Secondary 执行
rs.add("host:port")；观察rs.status().members[n].stateStr变为SECONDARY，且optimeDate追平 Primary
避免 initial sync 拖垮网络和磁盘 I/O
当 Secondary 加入时，默认触发全量同步（initial sync），这对 TB 级数据极不友好：
- 不要让 Secondary 直接从 Primary 拉取整个
dbPath—— 它会锁死 Primary 的磁盘读，同时占满带宽 - 更优做法：在 Secondary 启动前，先用
rsync或快照把 Primary 的dbPath克隆过去（确保 MongoDB 已停），再启动 mongod；这样 initial sync 只需补 oplog 差异，几秒到几分钟即可完成 - 确认
storage.journal.enabled: true已开启，否则 initial sync 中断后可能需重来
连接字符串和客户端适配必须同步改
副本集上线后，老的 mongodb://localhost:27017 连接会失效：
- 必须改用副本集 URI：
mongodb://node1:27017,node2:27017,node3:27017/?replicaSet=myrs - 驱动默认
readPreference=primary，如需读从节点，显式设readPreference=secondaryPreferred，但注意可能读到旧数据（maxStalenessSeconds需评估） - 应用层必须处理
NotWritablePrimary和InterruptedAtShutdown类错误，并实现重试逻辑 —— 主从切换期间写请求必然短暂失败
最关键的细节常被忽略：oplog 大小不是“越大越好”，而是要覆盖最长的 Secondary 同步中断时间。TB 级数据建议将 oplogSizeMB 设为至少 20480（20GB），否则新节点加进来还没同步完，oplog 就被覆盖了。
