做 MongoDB 复制集运维这几年被问得最多的问题之一就是“集群要加节点了怎么扩”、“机器要下线了节点怎么减”说实话复制集的扩容缩容并不复杂难的是在调整过程中不踩坑、不丢数据、不引发长时间不可用。今天这篇就把我在实际环境里折腾复制集扩容与缩容的经验完整梳理一遍从设计思路到具体命令再到问题排查一次性讲透。这套东西适合谁看一类是刚接触 MongoDB 复制集、准备上线生产环境的新手另一类是把复制集搭起来后一直没有好好规划过节点扩容缩容的运维同学。不管你是要应对业务量增长加节点还是要回收资源缩减集群只要你的 MongoDB 用的是复制集架构这篇文章里的思路和命令都能直接套用。先给一个基本认知MongoDB 复制集不是一锤子买卖它的节点是可以动态调整的官方早就把加节点、减节点这些操作做成了标准流程。但“能调整”和“调整得好”是两回事真正拉开差距的是你对节点角色、数据同步、选举机制这些底层逻辑的理解程度。1. 复制集扩容缩容到底解决什么问题1.1 什么时候需要扩容什么时候应该缩容先说扩容。最常见的场景就是业务量涨了读请求变多单节点的压力扛不住。复制集天然支持横向扩展把只读请求分散到多个副本节点上这是最典型的扩容理由。还有一个场景是数据量增长太快磁盘空间吃紧你需要在集群里增加节点来分担存储压力。另外如果当前集群只有两个数据节点加一个仲裁者可用性本身就比较脆弱一旦其中一个数据节点挂了副本数就不满足多数派要求这时候也需要加节点来提升容错能力。再比如你原来的复制集只有三节点想升级成五节点来应对更严格的高可用要求这也属于扩容的范畴。缩容的动机则更多来自成本控制和资源回收。业务高峰期过了或者说你发现副本太多数据同步的网络开销和存储冗余已经超过了收益那就应该减节点。还有一种情况是某个节点所在的物理机器要退役、机房要迁移你需要先把节点安全地移出集群再关停机器。这里有个重要的认知扩容缩容不是为了操作而操作而是为了让集群规模和业务需求匹配。扩的时候不能拍脑袋多加节点缩的时候也不能看哪个节点不顺眼就删每一步都要有明确的评估依据。1.2 为什么是复制集而非单机可用性与演进逻辑有人可能会问为什么非要用复制集单机 MongoDB 在开发环境跑得好好的为什么生产环境一定要上复制集道理很简单单机是单点挂了就全挂了。复制集的核心价值是提供自动故障转移主节点出问题后副本节点能通过选举自动顶上业务只会在选举窗口内短暂抖动不会完全不可用。复制集用心跳机制维护节点状态用多数派原则保证数据一致性这些机制共同构成了它作为高可用基础设施的底气。理解了这一点你就能明白扩容缩容的操作本质上是在“动态调整多数派”。集群规模变化后选举规则、投票权重都需要重新计算你不能只是简单地用 rs.add() 拉一个新节点进来就完事。很多人扩完容以后集群状态是红色的查了半天发现是投票权和优先级没配置好这就是对复制集内在机制理解不够导致的。所以接下来的内容我会先把扩容缩容的设计思考讲清楚再给具体命令这样你在实操的时候才能做到心里有数。2. 扩容缩容前的设计思路与资源评估2.1 节点角色与投票权规划复制集里每个成员都有两个关键属性votes投票权和 priority优先级。这两个参数决定了节点在选举中的话语权以及它有没有资格成为主节点。默认情况下每个节点 votes1、priority1。但在一个复制集里投票节点的总数是有硬性上限的最多 7 个投票节点。超过这个数量多余的节点想参与投票都投不了你必须把一些节点的 votes 设成 0。这里就牵扯到一个非常常见的扩容规划问题你想加到 10 个节点但只有 7 个能投票剩下 3 个只能当“数据备胎”这样设计是否合理我的经验是如果你的节点数超过 7通常说明你的架构有问题。复制集不等于无限横向扩展生产环境里更常见的做法是把读压力分散到一组专门用于读的副本节点上而不是一味添加投票节点。比如主节点 1 个、副本节点 4 个、隐藏节点 1 个、延迟节点 1 个分布到不同故障域这种设计比盲目凑 10 个节点科学得多。再说 priority。priority 为 0 的节点永远不可能被选举为主节点。如果你把某个节点的 priority 设为 0它的角色就是纯粹的副本。这个设置在做缩容时特别有用你想缩掉一个节点但还不想立即把它从配置里删除就可以先把它的 priority 改为 0让它退出选举竞争观察一段时间再决定是否彻底移除。2.2 数据同步、oplog 与磁盘容量的提前评估扩容最容易被低估的是数据同步时间。新节点加入复制集后会触发 initial sync初始同步这个过程要把主节点上的全量数据拷贝过来而且拷贝期间如果有新的写入需要通过 oplog 继续追平。如果数据量巨大比如几个 TB这个同步过程可能要跑很久期间会对主节点造成额外的 I/O 和网络压力。所以扩容之前我强烈建议先做三件事一是确认 oplog 的大小。oplog 是复制集同步的“流水账”它记录了对数据的所有写操作。如果 oplog 太小而新节点同步需要的时间太长oplog 覆盖窗口不够长新节点就可能追不上最终导致同步失败。生产环境里 oplog 至少要能覆盖几个小时甚至一天的写入量具体可以用 rs.printReplicationInfo() 查看当前 oplog 的日志窗口大小。二是评估磁盘空间。新节点要存一份完整副本磁盘占用跟主节点差不多。如果你的机器只有 500G 可用空间而主节点数据已经有 480G这个节点加进去大概率同步到一半就写满磁盘了。这种事故我见过不止一次都是因为扩容前没有认真核对磁盘空间。三是评估网络带宽。新增节点同步数据时主节点要往外传大量数据如果带宽本身就很紧张会影响线上业务。建议在业务低峰期做扩容操作或者在配置里限制同步占用的带宽可以通过流量控制工具实现MongoDB 本身没有直接的同步限速参数但你可以用操作系统层面的 tc 来限速。缩容则正好相反你需要确认的不是“能不能进去”而是“能不能安全出来”。数据节点被移除后它的数据要不要备份有没有可能以后还要用缩容前最好对节点做一次 mongodump 或者文件系统级别的快照备份宁可数据用不上也不能在用的时候发现没备。2.3 复制集规模的常规推荐配置结合我的实际经验不同规模的复制集配置可以参考下表。场景节点配置说明开发测试3 节点1 主 2 副成本低能体现多数派选举机制中小业务3 节点1 主 2 副标准高可用配置容错 1 个节点宕机读多写少5 节点1 主 3 副 1 仲裁读写分离读能力较强读写高并发分片集群 每片复制集单复制集横向扩展有限需要加分片备份需求311 隐藏节点做备份隐藏节点 priority0不参与选举表格里这个“仲裁节点”值得多说一句。仲裁者不存业务数据只参与投票它最大的作用是在偶数个数据节点情况下凑出一个多数派。仲裁节点很轻量但生产环境里我一般不推荐把仲裁节点和业务节点部署在同一台机器上否则这台机器一挂数据节点和数据节点加仲裁者一起没了集群照样可能选不出主节点。3. 扩容实操从零加入一个新副本节点3.1 配置 mongod 实例并加入复制集先强调一个前提新节点上需要安装 MongoDB版本最好和集群现有节点保持一致。跨版本扩容不是不可以但 MongoDB 官方对版本兼容有严格限制混版本集群在新版本特性、复制协议等方面都可能出问题能避免尽量避免。新节点的配置文件可以参考现有副本节点核心要保证两部分一是 replication.replSetName 必须和集群现有复制集名称一致二是 net.bindIp 和端口配置正确确保集群内其他节点能够访问。一个最小化的 mongod.conf 示例storage: dbPath: /data/mongo journal: enabled: true systemLog: destination: file logAppend: true path: /data/mongo/log/mongod.log net: bindIp: 0.0.0.0 port: 27017 replication: replSetName: rs0 processManagement: fork: true这里 bindIp 在生产环境不建议直接配置 0.0.0.0最好指定具体的内网 IP避免把 MongoDB 暴露到不安全的网络上。安全组和防火墙也要提前配好确保新节点和集群内已有节点之间的 27017 端口可以互通。配置写好以后启动 mongod 服务然后登入主节点执行 rs.add()。rs.add(192.168.1.101:27017)执行后可以用 rs.status() 观察新节点的状态刚加进去的时候 stateStr 一般是 STARTUP随后会进入 STARTUP2这是初始同步正在进行的状态。等它变成 SECONDARY就说明数据同步完成节点已经正常跟上集群节奏了。3.2 initial sync 过程中的关键观察点rs.add() 执行完之后千万别以为就万事大吉了。扩容过程中真正的风险都在 initial sync 阶段。整个 initial sync 的过程可以简单拆成几个步骤新节点从复制集的某个数据源节点获取全量数据快照。数据源节点会把快照期间产生的新 oplog 条目追加保存新节点一边拷贝数据一边追 oplog。全量拷贝完成后新节点继续应用未同步的 oplog 条目直到追上当前最新状态。追平后节点状态从 STARTUP2 切换为 SECONDARY开始正常参与后续的数据复制。这个过程中最常出问题的两个点一是数据拷贝时间过长二是发现追不上 oplog。我通常会在扩容期间做两个监控动作一个是观察同步是否有进展。用 db.currentOp() 可以看到正在进行的 initial sync 操作里面有进度信息。另外也能在日志里看到类似 “initial sync done” 的关键词。另一个是关注复制延迟replication lag。如果你发现新节点的 lag 数据一直涨说明它追不上写入速度这时候需要检查是不是数据源节点的 oplog 设置太小或者网络延迟太高。如果同步失败也不要慌可以先把节点从复制集配置里临时去掉修复问题后再重新加。需要注意的是重新加入会重新触发一次全量同步所以反复失败的成本很高排查问题的时候要有点耐心。3.3 优先级调整与切换演练节点成功加入集群并变成 SECONDARY 后扩容还没有真正结束。你还得考虑一个问题这个新节点的 priority 是多少如果新节点机器性能很强你想让它将来有能力成为主节点那 priority 可以设置成和当前主节点一样甚至更高。如果新节点只是一个读扩展节点不希望它参与主节点竞选就将 priority 设为 0除了投票权之外它永远只是个“干活的”。给节点设置 priority 的做法是先取出当前配置然后修改目标节点的 priority最后 rs.reconfig() 提交。cfg rs.conf() cfg.members[3].priority 0 rs.reconfig(cfg)这里有个非常重要的提醒rs.reconfig() 有时候会触发主节点切换。如果你不想让它切换可以在 reconfig 时加上 force 参数吗官方提供了 force 选项但要谨慎使用。force 会跳过一些校验在特殊情况下可以用来恢复集群。日常操作中如果你改了 priority 配置导致主节点变更这本身是正常的选举结果你不用太紧张。但如果你的业务不能接受主节点切换就要小心调整 priority 的时机。扩容完成后建议做一次主备切换演练新节点如果 priority 配置合理它应该能顺利接管主节点职责这能验证扩容后的集群确实是健康的。4. 缩容实操安全移除旧节点4.1 评估要缩容节点的角色与数据缩容比扩容更考验细心。因为扩容的时候新节点是“空”的怎么同步都行但缩容的时候节点上是有真实数据的而且它可能正在承担复制或者投票职责你不能说删就删。第一步是确认这个节点在复制集里扮演什么角色。用 rs.conf() 查看成员列表重点关注几个字段_id、host、votes、priority、hidden、secondaryDelaySecs。如果这个节点是 hidden 节点比如用做备份的隐藏节点它不参与业务读缩掉的影响就小。如果它是一个普通业务读副本缩掉后相关读流量会被分摊到其他副本上你要提前确认其他节点能扛住这些流量。如果它是主节点缩容必须先触发主节点切换把主节点角色让给其他节点然后再移除。直接 remove 一个主节点不是不可以但会导致集群重新选举引起短暂的业务抖动不如先主动切换把影响降到最低。4.2 执行 rs.remove() 与节点下线流程正式移除节点的命令很简单rs.remove(192.168.1.102:27017)执行之后这个节点会从复制集配置里被移除它自己也就不再参与复制和心跳了。但你还需要在机器上做两件事停掉 mongod 服务以及决定数据文件怎么处理。systemctl stop mongod如果你的缩容只是临时下线后面还要把这台机器加回来数据文件可以先保留重新加回来的时候可以省掉全量同步的时间。但如果你确定这台机器彻底退役建议把数据目录删掉或者格式化避免敏感数据泄露。这里还有一个容易忽略的点rs.remove() 只是在 MongoDB 层的配置中把这个节点移除了操作系统的进程还活着。如果你不手动停服务这台机器的 mongod 还会继续运行只是它已经不属于任何复制集了。如果它有写权限又有配置了独立的写路径就可能产生脏数据回头再想搞清楚数据都来不及。4.3 仲裁者与隐藏节点的特殊处理仲裁者节点没有数据但它参与投票是复制集可用性的关键组成。缩容仲裁者的场景一般是架构调整比如从“1 主 1 副 1 仲裁”变更为“1 主 2 副”这时候仲裁者就冗余了可以移除。移除仲裁者很简单它不涉及数据同步直接 rs.remove() 就行。但要注意仲裁者的移除会导致投票节点数量从 3 变为 2这时候复制集选举的多数派要求从“超过半数即 2/3”变成了“超过半数即 2/2”也就是说两个数据节点必须都活着才能选出主节点。如果其中一台挂了集群就无法自动恢复主节点可用性反而下降了。所以缩容仲裁者前一定要确认所有数据节点的健康状态并且要明确自己的可用性预期。如果你只是从三节点变成两节点实际上是放弃了故障自动恢复能力这在某些非核心系统里是可以接受的但要对业务方说清楚风险。隐藏节点的缩容则要稍微留意一下 hidden 属性。如果该节点配置了 hidden: true移除之前可以先通过修改配置把 hidden 去掉观察一下它和其他节点的同步状态。不过这并不是必须的如果缩容的目标就是彻底移除它直接 remove 也没有问题。5. 动态调整集群规模时的常见问题与排查实录5.1 扩容时 initial sync 一直追不上这是扩容最高频的坑。表现是新节点加入后一直处于 STARTUP2 状态replication lag 居高不下甚至越来越大。排查思路从两个方向入手。第一看数据源节点的 oplog 窗口是否足够大。执行 rs.printReplicationInfo()如果 configured oplog size 很小而时间窗口只有几十分钟那么只要新节点同步耗时超过这个窗口它永远追不上。解决办法是调整数据源节点的 oplog 大小比如把 --oplogSize 调大到 10G 甚至更高然后重启该节点。第二看数据源节点的 I/O 和网络是否已经过载。同步要从源节点读全量数据和 oplog如果源节点本身已经热得不行再给它加同步压力等于火上浇油。这时候可以考虑在新节点配置里用 replSetSyncFrom 将同步数据源临时指定到另一个负载较低的副本节点减轻主节点压力。具体命令如下db.adminCommand({ replSetSyncFrom: 192.168.1.103:27017 })这个命令可以让新节点从指定的节点同步而不是默认从主节点同步能有效缓解主节点压力。但要注意这只是临时调整新节点追平后会自动恢复正常同步关系。5.2 缩容后出现复制延迟或节点状态异常缩容后状态异常最常见的原因是残留配置。比如你在缩容了某个节点后其他有些节点的配置里还残留了对该节点的引用理论上 MongoDB 会自动清理但有时候网络分区或者操作顺序不对会导致残留。表现就是 rs.status() 里能看到已经移除的节点或者某些节点一直在尝试连接已下线的机器。处理方式很简单重新读取配置手动清理异常成员再次 reconfig。cfg rs.conf() cfg.members cfg.members.filter(function(m) { return m.host ! 192.168.1.102:27017 }) rs.reconfig(cfg, { force: true })force 参数在这里的作用是跳过某些配置校验适合修复已经处于异常状态的配置。但 force 之后要立刻检查新配置是否能满足复制集正常运行的要求不要带着一个很烂的配置就跑。5.3 投票权变化导致的选主异常复制集扩容后节点数量变化会直接影响多数派选举条件。比如说原先有 3 个投票节点故障容忍度是 1 个节点挂掉。扩容到 5 个投票节点后容忍度变成 2 个节点挂掉。这个提升是好事但要注意如果你只是“加到 5 个节点”但新节点没有正确设置投票权比如某几个新节点 votes0那实际投票节点数可能只有 3跟没扩容一样。反过来缩容时如果不小心把投票节点减得太多比如 7 个投票节点缩到 3 个选举多数派条件会从 4/7 变成 2/3容错能力相应下降。我建议每次调整完节点后都用 rs.status() 检查一下投票节点数和每个节点的 votes 值确保跟设计预期一致。另一个容易被忽略的点是如果副本集投票节点数为偶数比如 4 个投票节点选举时可能出现打平的局面导致无法选出主节点。所以生产环境一般建议投票节点总数保持奇数。当你缩容后得到偶数个投票节点时可以考虑加一个仲裁者来保证奇数。5.4 扩容缩容时的备份与回滚策略这是很多人忽略但在真实事故中救过命的操作。扩容前最好先对主节点做一次全量备份。因为扩容过程中如果出现数据文件损坏、误操作导致节点数据被覆盖等问题你还有机会恢复。备份方式一般用 mongodump 对指定库做逻辑备份或者用文件系统快照对 dbPath 做物理备份。根据数据量大小决定数据量小用 mongodump 简单直接数据量大建议用快照恢复速度更快。缩容前同样需要备份尤其是要缩容的节点可能是特殊角色比如原先的隐藏备份节点它的数据可能是你唯一的一份历史数据拷贝。把数据留下再下线这永远是安全的选择。回滚策略指的是你给集群做的配置修改要能快速恢复。比如你 rs.remove() 了一个节点后来发现这个节点还有需要的数据配置这时候只要数据文件还在重新 rs.add() 并且等待同步就能加回来。但如果你已经把数据目录清空了加回来就得重新全量同步耗时很久。所以我的习惯是缩容下来的机器先保留数据文件和 mongod 配置 24 小时以上确认业务完全没有异常后再清理。5.5 扩容缩容操作时机的选择最后说一下时机。MongoDB 复制集支持在线扩容缩容不要求停机但这不代表任何时候都能无感操作。扩容时全量同步会占用源节点的 I/O 和网络带宽如果业务高峰期执行可能影响线上读写性能。缩容时主节点切换会导致短暂的主节点不可用窗口如果业务没有配置自动重连或重试机制这个窗口内可能有报错。我一般建议把这类操作安排在凌晨或业务低峰期并且提前通知相关业务方。操作前在监控上划好线操作过程中随时盯住复制延迟、磁盘增长、CPU 和内存使用率这几个指标。出现异常就果断中止操作该回滚回滚该调整调整不要硬着头皮往下走。写在最后的个人经验在整个扩容缩容的实操里我自己踩过最大的一个坑就是“扩容前没有把 oplog 调大结果同步跑到半夜才追平”。从那次以后我给团队定了一个硬性检查清单扩容前必须先看 oplog 窗口必须先确认新节点磁盘空间必须在低峰期操作。看似都是小事但每一个都对应过真实的线上故障。另一个实用的习惯是在每次扩容缩容后把 rs.conf() 的最终配置导出存档。这样做的好处是后面排查问题的时候不用靠记忆去猜当时配置了哪些参数直接看存档就能定位。尤其是有多套环境的时候不同复制集的配置差异往往就是问题根源。复制集扩容缩容并没有想象中那么神秘只要理解了多数派、投票权、优先级和 oplog 这几个核心概念再掌握 rs.add、rs.remove、rs.reconfig 这几个基本操作你就能比较从容地应对集群规模调整的需求。真正决定操作质量的是对细节的敬畏和对风险的预案。希望这篇文章能帮你少走一些弯路。
做 MongoDB 复制集运维这几年被问得最多的问题之一就是“集群要加节点了怎么扩”、“机器要下线了节点怎么减”说实话复制集的扩容缩容并不复杂难的是在调整过程中不踩坑、不丢数据、不引发长时间不可用。今天这篇就把我在实际环境里折腾复制集扩容与缩容的经验完整梳理一遍从设计思路到具体命令再到问题排查一次性讲透。这套东西适合谁看一类是刚接触 MongoDB 复制集、准备上线生产环境的新手另一类是把复制集搭起来后一直没有好好规划过节点扩容缩容的运维同学。不管你是要应对业务量增长加节点还是要回收资源缩减集群只要你的 MongoDB 用的是复制集架构这篇文章里的思路和命令都能直接套用。先给一个基本认知MongoDB 复制集不是一锤子买卖它的节点是可以动态调整的官方早就把加节点、减节点这些操作做成了标准流程。但“能调整”和“调整得好”是两回事真正拉开差距的是你对节点角色、数据同步、选举机制这些底层逻辑的理解程度。1. 复制集扩容缩容到底解决什么问题1.1 什么时候需要扩容什么时候应该缩容先说扩容。最常见的场景就是业务量涨了读请求变多单节点的压力扛不住。复制集天然支持横向扩展把只读请求分散到多个副本节点上这是最典型的扩容理由。还有一个场景是数据量增长太快磁盘空间吃紧你需要在集群里增加节点来分担存储压力。另外如果当前集群只有两个数据节点加一个仲裁者可用性本身就比较脆弱一旦其中一个数据节点挂了副本数就不满足多数派要求这时候也需要加节点来提升容错能力。再比如你原来的复制集只有三节点想升级成五节点来应对更严格的高可用要求这也属于扩容的范畴。缩容的动机则更多来自成本控制和资源回收。业务高峰期过了或者说你发现副本太多数据同步的网络开销和存储冗余已经超过了收益那就应该减节点。还有一种情况是某个节点所在的物理机器要退役、机房要迁移你需要先把节点安全地移出集群再关停机器。这里有个重要的认知扩容缩容不是为了操作而操作而是为了让集群规模和业务需求匹配。扩的时候不能拍脑袋多加节点缩的时候也不能看哪个节点不顺眼就删每一步都要有明确的评估依据。1.2 为什么是复制集而非单机可用性与演进逻辑有人可能会问为什么非要用复制集单机 MongoDB 在开发环境跑得好好的为什么生产环境一定要上复制集道理很简单单机是单点挂了就全挂了。复制集的核心价值是提供自动故障转移主节点出问题后副本节点能通过选举自动顶上业务只会在选举窗口内短暂抖动不会完全不可用。复制集用心跳机制维护节点状态用多数派原则保证数据一致性这些机制共同构成了它作为高可用基础设施的底气。理解了这一点你就能明白扩容缩容的操作本质上是在“动态调整多数派”。集群规模变化后选举规则、投票权重都需要重新计算你不能只是简单地用 rs.add() 拉一个新节点进来就完事。很多人扩完容以后集群状态是红色的查了半天发现是投票权和优先级没配置好这就是对复制集内在机制理解不够导致的。所以接下来的内容我会先把扩容缩容的设计思考讲清楚再给具体命令这样你在实操的时候才能做到心里有数。2. 扩容缩容前的设计思路与资源评估2.1 节点角色与投票权规划复制集里每个成员都有两个关键属性votes投票权和 priority优先级。这两个参数决定了节点在选举中的话语权以及它有没有资格成为主节点。默认情况下每个节点 votes1、priority1。但在一个复制集里投票节点的总数是有硬性上限的最多 7 个投票节点。超过这个数量多余的节点想参与投票都投不了你必须把一些节点的 votes 设成 0。这里就牵扯到一个非常常见的扩容规划问题你想加到 10 个节点但只有 7 个能投票剩下 3 个只能当“数据备胎”这样设计是否合理我的经验是如果你的节点数超过 7通常说明你的架构有问题。复制集不等于无限横向扩展生产环境里更常见的做法是把读压力分散到一组专门用于读的副本节点上而不是一味添加投票节点。比如主节点 1 个、副本节点 4 个、隐藏节点 1 个、延迟节点 1 个分布到不同故障域这种设计比盲目凑 10 个节点科学得多。再说 priority。priority 为 0 的节点永远不可能被选举为主节点。如果你把某个节点的 priority 设为 0它的角色就是纯粹的副本。这个设置在做缩容时特别有用你想缩掉一个节点但还不想立即把它从配置里删除就可以先把它的 priority 改为 0让它退出选举竞争观察一段时间再决定是否彻底移除。2.2 数据同步、oplog 与磁盘容量的提前评估扩容最容易被低估的是数据同步时间。新节点加入复制集后会触发 initial sync初始同步这个过程要把主节点上的全量数据拷贝过来而且拷贝期间如果有新的写入需要通过 oplog 继续追平。如果数据量巨大比如几个 TB这个同步过程可能要跑很久期间会对主节点造成额外的 I/O 和网络压力。所以扩容之前我强烈建议先做三件事一是确认 oplog 的大小。oplog 是复制集同步的“流水账”它记录了对数据的所有写操作。如果 oplog 太小而新节点同步需要的时间太长oplog 覆盖窗口不够长新节点就可能追不上最终导致同步失败。生产环境里 oplog 至少要能覆盖几个小时甚至一天的写入量具体可以用 rs.printReplicationInfo() 查看当前 oplog 的日志窗口大小。二是评估磁盘空间。新节点要存一份完整副本磁盘占用跟主节点差不多。如果你的机器只有 500G 可用空间而主节点数据已经有 480G这个节点加进去大概率同步到一半就写满磁盘了。这种事故我见过不止一次都是因为扩容前没有认真核对磁盘空间。三是评估网络带宽。新增节点同步数据时主节点要往外传大量数据如果带宽本身就很紧张会影响线上业务。建议在业务低峰期做扩容操作或者在配置里限制同步占用的带宽可以通过流量控制工具实现MongoDB 本身没有直接的同步限速参数但你可以用操作系统层面的 tc 来限速。缩容则正好相反你需要确认的不是“能不能进去”而是“能不能安全出来”。数据节点被移除后它的数据要不要备份有没有可能以后还要用缩容前最好对节点做一次 mongodump 或者文件系统级别的快照备份宁可数据用不上也不能在用的时候发现没备。2.3 复制集规模的常规推荐配置结合我的实际经验不同规模的复制集配置可以参考下表。场景节点配置说明开发测试3 节点1 主 2 副成本低能体现多数派选举机制中小业务3 节点1 主 2 副标准高可用配置容错 1 个节点宕机读多写少5 节点1 主 3 副 1 仲裁读写分离读能力较强读写高并发分片集群 每片复制集单复制集横向扩展有限需要加分片备份需求311 隐藏节点做备份隐藏节点 priority0不参与选举表格里这个“仲裁节点”值得多说一句。仲裁者不存业务数据只参与投票它最大的作用是在偶数个数据节点情况下凑出一个多数派。仲裁节点很轻量但生产环境里我一般不推荐把仲裁节点和业务节点部署在同一台机器上否则这台机器一挂数据节点和数据节点加仲裁者一起没了集群照样可能选不出主节点。3. 扩容实操从零加入一个新副本节点3.1 配置 mongod 实例并加入复制集先强调一个前提新节点上需要安装 MongoDB版本最好和集群现有节点保持一致。跨版本扩容不是不可以但 MongoDB 官方对版本兼容有严格限制混版本集群在新版本特性、复制协议等方面都可能出问题能避免尽量避免。新节点的配置文件可以参考现有副本节点核心要保证两部分一是 replication.replSetName 必须和集群现有复制集名称一致二是 net.bindIp 和端口配置正确确保集群内其他节点能够访问。一个最小化的 mongod.conf 示例storage: dbPath: /data/mongo journal: enabled: true systemLog: destination: file logAppend: true path: /data/mongo/log/mongod.log net: bindIp: 0.0.0.0 port: 27017 replication: replSetName: rs0 processManagement: fork: true这里 bindIp 在生产环境不建议直接配置 0.0.0.0最好指定具体的内网 IP避免把 MongoDB 暴露到不安全的网络上。安全组和防火墙也要提前配好确保新节点和集群内已有节点之间的 27017 端口可以互通。配置写好以后启动 mongod 服务然后登入主节点执行 rs.add()。rs.add(192.168.1.101:27017)执行后可以用 rs.status() 观察新节点的状态刚加进去的时候 stateStr 一般是 STARTUP随后会进入 STARTUP2这是初始同步正在进行的状态。等它变成 SECONDARY就说明数据同步完成节点已经正常跟上集群节奏了。3.2 initial sync 过程中的关键观察点rs.add() 执行完之后千万别以为就万事大吉了。扩容过程中真正的风险都在 initial sync 阶段。整个 initial sync 的过程可以简单拆成几个步骤新节点从复制集的某个数据源节点获取全量数据快照。数据源节点会把快照期间产生的新 oplog 条目追加保存新节点一边拷贝数据一边追 oplog。全量拷贝完成后新节点继续应用未同步的 oplog 条目直到追上当前最新状态。追平后节点状态从 STARTUP2 切换为 SECONDARY开始正常参与后续的数据复制。这个过程中最常出问题的两个点一是数据拷贝时间过长二是发现追不上 oplog。我通常会在扩容期间做两个监控动作一个是观察同步是否有进展。用 db.currentOp() 可以看到正在进行的 initial sync 操作里面有进度信息。另外也能在日志里看到类似 “initial sync done” 的关键词。另一个是关注复制延迟replication lag。如果你发现新节点的 lag 数据一直涨说明它追不上写入速度这时候需要检查是不是数据源节点的 oplog 设置太小或者网络延迟太高。如果同步失败也不要慌可以先把节点从复制集配置里临时去掉修复问题后再重新加。需要注意的是重新加入会重新触发一次全量同步所以反复失败的成本很高排查问题的时候要有点耐心。3.3 优先级调整与切换演练节点成功加入集群并变成 SECONDARY 后扩容还没有真正结束。你还得考虑一个问题这个新节点的 priority 是多少如果新节点机器性能很强你想让它将来有能力成为主节点那 priority 可以设置成和当前主节点一样甚至更高。如果新节点只是一个读扩展节点不希望它参与主节点竞选就将 priority 设为 0除了投票权之外它永远只是个“干活的”。给节点设置 priority 的做法是先取出当前配置然后修改目标节点的 priority最后 rs.reconfig() 提交。cfg rs.conf() cfg.members[3].priority 0 rs.reconfig(cfg)这里有个非常重要的提醒rs.reconfig() 有时候会触发主节点切换。如果你不想让它切换可以在 reconfig 时加上 force 参数吗官方提供了 force 选项但要谨慎使用。force 会跳过一些校验在特殊情况下可以用来恢复集群。日常操作中如果你改了 priority 配置导致主节点变更这本身是正常的选举结果你不用太紧张。但如果你的业务不能接受主节点切换就要小心调整 priority 的时机。扩容完成后建议做一次主备切换演练新节点如果 priority 配置合理它应该能顺利接管主节点职责这能验证扩容后的集群确实是健康的。4. 缩容实操安全移除旧节点4.1 评估要缩容节点的角色与数据缩容比扩容更考验细心。因为扩容的时候新节点是“空”的怎么同步都行但缩容的时候节点上是有真实数据的而且它可能正在承担复制或者投票职责你不能说删就删。第一步是确认这个节点在复制集里扮演什么角色。用 rs.conf() 查看成员列表重点关注几个字段_id、host、votes、priority、hidden、secondaryDelaySecs。如果这个节点是 hidden 节点比如用做备份的隐藏节点它不参与业务读缩掉的影响就小。如果它是一个普通业务读副本缩掉后相关读流量会被分摊到其他副本上你要提前确认其他节点能扛住这些流量。如果它是主节点缩容必须先触发主节点切换把主节点角色让给其他节点然后再移除。直接 remove 一个主节点不是不可以但会导致集群重新选举引起短暂的业务抖动不如先主动切换把影响降到最低。4.2 执行 rs.remove() 与节点下线流程正式移除节点的命令很简单rs.remove(192.168.1.102:27017)执行之后这个节点会从复制集配置里被移除它自己也就不再参与复制和心跳了。但你还需要在机器上做两件事停掉 mongod 服务以及决定数据文件怎么处理。systemctl stop mongod如果你的缩容只是临时下线后面还要把这台机器加回来数据文件可以先保留重新加回来的时候可以省掉全量同步的时间。但如果你确定这台机器彻底退役建议把数据目录删掉或者格式化避免敏感数据泄露。这里还有一个容易忽略的点rs.remove() 只是在 MongoDB 层的配置中把这个节点移除了操作系统的进程还活着。如果你不手动停服务这台机器的 mongod 还会继续运行只是它已经不属于任何复制集了。如果它有写权限又有配置了独立的写路径就可能产生脏数据回头再想搞清楚数据都来不及。4.3 仲裁者与隐藏节点的特殊处理仲裁者节点没有数据但它参与投票是复制集可用性的关键组成。缩容仲裁者的场景一般是架构调整比如从“1 主 1 副 1 仲裁”变更为“1 主 2 副”这时候仲裁者就冗余了可以移除。移除仲裁者很简单它不涉及数据同步直接 rs.remove() 就行。但要注意仲裁者的移除会导致投票节点数量从 3 变为 2这时候复制集选举的多数派要求从“超过半数即 2/3”变成了“超过半数即 2/2”也就是说两个数据节点必须都活着才能选出主节点。如果其中一台挂了集群就无法自动恢复主节点可用性反而下降了。所以缩容仲裁者前一定要确认所有数据节点的健康状态并且要明确自己的可用性预期。如果你只是从三节点变成两节点实际上是放弃了故障自动恢复能力这在某些非核心系统里是可以接受的但要对业务方说清楚风险。隐藏节点的缩容则要稍微留意一下 hidden 属性。如果该节点配置了 hidden: true移除之前可以先通过修改配置把 hidden 去掉观察一下它和其他节点的同步状态。不过这并不是必须的如果缩容的目标就是彻底移除它直接 remove 也没有问题。5. 动态调整集群规模时的常见问题与排查实录5.1 扩容时 initial sync 一直追不上这是扩容最高频的坑。表现是新节点加入后一直处于 STARTUP2 状态replication lag 居高不下甚至越来越大。排查思路从两个方向入手。第一看数据源节点的 oplog 窗口是否足够大。执行 rs.printReplicationInfo()如果 configured oplog size 很小而时间窗口只有几十分钟那么只要新节点同步耗时超过这个窗口它永远追不上。解决办法是调整数据源节点的 oplog 大小比如把 --oplogSize 调大到 10G 甚至更高然后重启该节点。第二看数据源节点的 I/O 和网络是否已经过载。同步要从源节点读全量数据和 oplog如果源节点本身已经热得不行再给它加同步压力等于火上浇油。这时候可以考虑在新节点配置里用 replSetSyncFrom 将同步数据源临时指定到另一个负载较低的副本节点减轻主节点压力。具体命令如下db.adminCommand({ replSetSyncFrom: 192.168.1.103:27017 })这个命令可以让新节点从指定的节点同步而不是默认从主节点同步能有效缓解主节点压力。但要注意这只是临时调整新节点追平后会自动恢复正常同步关系。5.2 缩容后出现复制延迟或节点状态异常缩容后状态异常最常见的原因是残留配置。比如你在缩容了某个节点后其他有些节点的配置里还残留了对该节点的引用理论上 MongoDB 会自动清理但有时候网络分区或者操作顺序不对会导致残留。表现就是 rs.status() 里能看到已经移除的节点或者某些节点一直在尝试连接已下线的机器。处理方式很简单重新读取配置手动清理异常成员再次 reconfig。cfg rs.conf() cfg.members cfg.members.filter(function(m) { return m.host ! 192.168.1.102:27017 }) rs.reconfig(cfg, { force: true })force 参数在这里的作用是跳过某些配置校验适合修复已经处于异常状态的配置。但 force 之后要立刻检查新配置是否能满足复制集正常运行的要求不要带着一个很烂的配置就跑。5.3 投票权变化导致的选主异常复制集扩容后节点数量变化会直接影响多数派选举条件。比如说原先有 3 个投票节点故障容忍度是 1 个节点挂掉。扩容到 5 个投票节点后容忍度变成 2 个节点挂掉。这个提升是好事但要注意如果你只是“加到 5 个节点”但新节点没有正确设置投票权比如某几个新节点 votes0那实际投票节点数可能只有 3跟没扩容一样。反过来缩容时如果不小心把投票节点减得太多比如 7 个投票节点缩到 3 个选举多数派条件会从 4/7 变成 2/3容错能力相应下降。我建议每次调整完节点后都用 rs.status() 检查一下投票节点数和每个节点的 votes 值确保跟设计预期一致。另一个容易被忽略的点是如果副本集投票节点数为偶数比如 4 个投票节点选举时可能出现打平的局面导致无法选出主节点。所以生产环境一般建议投票节点总数保持奇数。当你缩容后得到偶数个投票节点时可以考虑加一个仲裁者来保证奇数。5.4 扩容缩容时的备份与回滚策略这是很多人忽略但在真实事故中救过命的操作。扩容前最好先对主节点做一次全量备份。因为扩容过程中如果出现数据文件损坏、误操作导致节点数据被覆盖等问题你还有机会恢复。备份方式一般用 mongodump 对指定库做逻辑备份或者用文件系统快照对 dbPath 做物理备份。根据数据量大小决定数据量小用 mongodump 简单直接数据量大建议用快照恢复速度更快。缩容前同样需要备份尤其是要缩容的节点可能是特殊角色比如原先的隐藏备份节点它的数据可能是你唯一的一份历史数据拷贝。把数据留下再下线这永远是安全的选择。回滚策略指的是你给集群做的配置修改要能快速恢复。比如你 rs.remove() 了一个节点后来发现这个节点还有需要的数据配置这时候只要数据文件还在重新 rs.add() 并且等待同步就能加回来。但如果你已经把数据目录清空了加回来就得重新全量同步耗时很久。所以我的习惯是缩容下来的机器先保留数据文件和 mongod 配置 24 小时以上确认业务完全没有异常后再清理。5.5 扩容缩容操作时机的选择最后说一下时机。MongoDB 复制集支持在线扩容缩容不要求停机但这不代表任何时候都能无感操作。扩容时全量同步会占用源节点的 I/O 和网络带宽如果业务高峰期执行可能影响线上读写性能。缩容时主节点切换会导致短暂的主节点不可用窗口如果业务没有配置自动重连或重试机制这个窗口内可能有报错。我一般建议把这类操作安排在凌晨或业务低峰期并且提前通知相关业务方。操作前在监控上划好线操作过程中随时盯住复制延迟、磁盘增长、CPU 和内存使用率这几个指标。出现异常就果断中止操作该回滚回滚该调整调整不要硬着头皮往下走。写在最后的个人经验在整个扩容缩容的实操里我自己踩过最大的一个坑就是“扩容前没有把 oplog 调大结果同步跑到半夜才追平”。从那次以后我给团队定了一个硬性检查清单扩容前必须先看 oplog 窗口必须先确认新节点磁盘空间必须在低峰期操作。看似都是小事但每一个都对应过真实的线上故障。另一个实用的习惯是在每次扩容缩容后把 rs.conf() 的最终配置导出存档。这样做的好处是后面排查问题的时候不用靠记忆去猜当时配置了哪些参数直接看存档就能定位。尤其是有多套环境的时候不同复制集的配置差异往往就是问题根源。复制集扩容缩容并没有想象中那么神秘只要理解了多数派、投票权、优先级和 oplog 这几个核心概念再掌握 rs.add、rs.remove、rs.reconfig 这几个基本操作你就能比较从容地应对集群规模调整的需求。真正决定操作质量的是对细节的敬畏和对风险的预案。希望这篇文章能帮你少走一些弯路。
