单实例升级副本集必须重启并重配置，因其副本集模式非运行时开关，需停进程、加--replSet与--oplogSize参数、执行rs.initiate()初始化，否则无法启用oplog、选举及rs.*命令。
不能“无缝平滑”——MongoDB单实例转副本集必然引入一次主从切换和短暂写不可用，但可以控制在秒级、对业务影响极小。关键不是避免切换，而是让切换不触发全量同步、不中断连接、不丢数据。
为什么单实例升级副本集必须重启并重配置？
MongoDB的副本集模式不是运行时开关，它依赖一套独立的启动参数和内部状态机。单实例默认以 standalone 模式启动，不维护 oplog、不参与选举、不接受 rs.* 命令。要启用副本集，必须：
- 停掉当前
mongod进程（无法热加载副本集配置） - 修改启动参数，加入
--replSet和--oplogSize（否则默认 oplog 只有 5% 磁盘空间，远不够同步窗口） - 首次启动后执行
rs.initiate()初始化副本集元数据
这个过程本身不丢失数据，但会中断正在建立的连接；如果应用没做重连，会出现短时写失败。
如何避免 initial sync 导致的长时间同步卡住？
很多人以为加了第二个节点才触发 initial sync，其实第一次 rs.initiate() 后，本机节点会进入 STARTUP2 → RECOVERING → SECONDARY 状态，期间也会尝试读取本地 oplog 并校验——如果 oplog 为空或不合法，它会强制回退到 initial sync 流程，从自己拉数据，造成数分钟无响应。
解决办法只有两个：
- 启动前确保
--oplogSize足够大（建议至少 10GB 或覆盖 24 小时写入量），且不要用--smallfiles -
rs.initiate()必须传入显式配置，明确指定该节点为members[0].host，且members[0].priority = 1、members[0].votes = 1，避免因默认配置缺失导致状态反复
错误示例：rs.initiate() 不带参数，系统可能生成含 localhost 的 host 字段，后续其他节点无法解析；正确写法：rs.initiate({ _id: "rs0", members: [{ _id: 0, host: "mydb.example.com:27017" }] })
客户端连接怎么不感知主节点变化？
单实例时代你可能直连 localhost:27017，升级副本集后，primary 可能随时漂移（哪怕只有一台机器，故障恢复也可能触发重新选举）。硬编码地址会让应用突然读到 stale 数据或写失败。
必须改用副本集连接字符串：
- 格式为
mongodb://mydb.example.com:27017/?replicaSet=rs0 - 驱动会自动发现 primary，并在切换时重试（前提是你的驱动版本 ≥ 4.4 兼容版）
- 确认应用代码里没有
connect("localhost:27017")这类写死逻辑
如果你用的是旧版驱动（比如 Python PyMongo NotMaster 错误——这种必须升级驱动，别指望靠重连兜底。
升级后最常被忽略的三件事
很多人 rs.initiate 成功、看到 PRIMARY 状态就以为完事了，但接下来这三步不做，后续扩容或升级会出大问题：
- 立刻运行
db.adminCommand({ setFeatureCompatibilityVersion: "4.4" })，否则未来升级到 5.0 会被拒绝 - 检查
db.getReplicationInfo()，确认 oplog 起始时间合理（不应是 epoch 零点），否则说明 oplog 没生效 - 把原单实例的备份策略从“停机快照”改成“基于 oplog 的持续备份”，因为副本集模式下，停机备份可能跨 oplog 边界，恢复时无法保证一致性
真正麻烦的从来不是第一次加节点，而是加完之后忘了 featureCompatibilityVersion 和 oplog 状态——等半年后想升 5.0，才发现卡在兼容性检查上，又得倒回去补操作。
