1. 复制集到底是什么为什么要用它我刚接触MongoDB那会儿最常被问的问题就是MongoDB到底能不能扛住生产环境问的人多半在单机部署上栽过跟头——mongod进程一挂业务直接停摆数据恢复全靠备份运气不好丢个几小时数据都是常事。其实MongoDB早就给出了标准答案复制集Replica Set。它不是什么复杂的东西本质上就是一组mongod进程其中一个作为主节点Primary承担读写其余作为从节点Secondary持续同步主节点的数据一旦Primary发生故障集群会立刻在从节点中选举出新的Primary整个切换过程对应用层基本无感。这套机制解决的是三个最核心的痛点第一单点故障导致业务不可用第二服务器磁盘损坏或者误删除导致数据永久丢失第三读压力全部压在一个节点、扩容只能靠换更大的机器。复制集把所有问题一次性处理掉既做了高可用又做了读写分离还顺带简化了备份方案——你只要挑一个从节点做备份完全不影响线上业务。我建议的读者范围很宽刚装好MongoDB、准备上生产的后端开发被领导要求“搞个高可用数据库”的运维同学以及想彻底搞懂复制集内部原理的架构师。下文内容基于我自己在真实环境里搭建、压测、故障演练的完整过程会讲到不少文档里查不到的细节适合当作一份实战笔记来读。2. 复制集的整体设计与角色机制2.1 三个角色的分工与“奇数成员”原则先说清楚复制集里三种角色的实际分工这是理解一切后续机制的前提主节点Primary唯一允许执行写操作的节点所有写请求最终落到Primary的oplog操作日志中然后异步复制给从节点。Primary挂了整个复制集内部会重新发起选举。从节点Secondary持续拉取并应用Primary产生的oplog保持数据尽可能接近Primary。从节点默认不承担读请求但你可以通过设置readPreference读偏好把读流量分流到从节点。仲裁节点Arbiter不存数据、不参与oplog同步只参与选举投票。它的作用是在偶数成员时打破平局比如2个数据节点加1个仲裁节点既保证了故障切换时能选出Primary又不需要多维护一份全量数据副本。为什么官方推荐部署奇数个成员最好是3个而不是2个或4个因为复制集选举需要“大多数”majority可见。在一个3节点复制集中任何时刻只要至少2个节点互相能通信整个集群就能正常对外提供服务并完成选举。如果有2个数据节点加1个仲裁节点即使其中1个数据节点宕机剩下1个数据节点和仲裁节点也能凑齐2票选出新的Primary。反过来如果部署了2个数据节点但没有仲裁节点任何一台宕机都会导致剩下的节点只有1票不足半数而无法选举整个集群只能进入只读模式高可用等于零。4个节点更浪费——你比3个节点多花了硬件成本但容错能力一模一样同样是允许挂1台节点。这里有个不可忽视的运维细节仲裁节点虽然不存业务数据但它是整个选举机制里的关键票数来源。很多人把它部署在同一台物理机甚至同一个mongod容器里一旦机器整体宕机仲裁节点挂掉数据节点就失去了平票破局的能力复制集可能停止选举、拒绝写入。仲裁节点一定要跟两个数据节点放在不同的故障域比如不同机房、不同机架或至少不同云服务器。2.2 复制集的选举、单一Primary保证与多数派逻辑接下来讲复制集最核心的机制选举Election。MongoDB使用基于心跳heartbeat的选举协议来维持复制集的一致性。每个节点每隔2秒向复制集其他成员发送一次心跳包如果某个节点在10秒内默认electionTimeoutMillis参数没有收到Primary的响应它会认为Primary已经失联于是主动发起一次新的选举。但选举不是谁发起谁就自动当Primary。候选节点需要满足一个条件它的oplog必须足够新至少不能落后于它在选举时所能联系到的其他节点也就是“最优同步进度优先”。所有参与选举的节点都会广播自己的最新oplog时间戳拥有最新数据的节点最有可能成为新的Primary这样能最大限度地避免提交成功的数据丢失。选举结果的另一个约束是“最多只有一个Primary”。即使网络发生分区例如3节点复制集分裂成两个无法互通的小区只有一个区能凑齐2票包括原Primary或新发起选举的节点这个区才能选举出新的Primary并继续接受写入。另一个孤立的节点即使数据是最新的也因为没有多数派支持而自动降级为从节点只能对外报“当前节点不是Primary”的错误绝对不允许自己默默变成Primary写数据。这个机制就是典型的多数派majority策略它保证了任何一个时刻集群内只有一个节点在真正处理写请求从而防了“脑裂”后数据分叉。从实际运维角度我建议大家验证复制集状态时不要只看单节点而是用rs.status()查看复制集全局视角。当sts中出现PRIMARY节点且大多数成员都是SECONDARY或ARBITER时整个集群才算健康。一旦出现两个PRIMARY先别慌检查网络是不是刚恢复然后以oplog位置更新、拥有最多成员支持的节点为准手动干预解决异常状态。3. 从零搭建一个3节点复制集3.1 环境准备与配置文件详细说明我先说说我的实验环境方便你对照复现3台CentOS 7.9虚拟机每台机器2核4G分别开放27017端口MongoDB版本为4.4.6。我用的是RPM方式安装如果你用Docker思想也是一样的只是进程管理和网络映射要稍微调整。每台机器都安装同样版本的MongoDB并建立好数据目录、日志目录。安装完后最重要的就是配置文件下面是我在每台机器上使用的mongod.conf内容是经过实战调整后的最终版# mongod.conf for Replica Set systemLog: destination: file path: /data/mongodb/log/mongod.log # 日志目录需提前创建 logAppend: true # 追加写入不要每次启动覆盖 storage: dbPath: /data/mongodb/data # 数据存储目录需提前创建 wiredTiger: engineConfig: cacheSizeGB: 1 # 根据机器内存调整建议不超过内存的一半 net: port: 27017 bindIp: 0.0.0.0 # 生产环境建议绑定内网IP不要暴露公网 replication: replSetName: rs0 # 三个节点的复制集名称必须一致 processManagement: fork: true pidFilePath: /data/mongodb/log/mongod.pid有两个坑我必须提醒你。第一是replication.replSetName这个字段它是判断一台mongod是否属于某个复制集的核心标识。如果你在命令行启动时没加--replSet参数或者配置文件里没写那么之后执行复制集初始化命令时会直接报错提示你没有启动为复制集节点。第二是bindIp测试环境下很多人喜欢用127.0.0.1但3台机器分布在不同的服务器上后节点之间连不上心跳全不通复制集永远无法初始化成功。我的习惯是绑定内网IP或0.0.0.0同时用防火墙限制来源。3.2 初始化复制集与节点添加配置文件就绪后依次启动三台机器的mongod进程然后连上其中任意一台执行初始化。我通常连第一台机器用mongo shell执行以下命令rs.initiate({ _id: rs0, members: [ { _id: 0, host: 192.168.1.10:27017 }, { _id: 1, host: 192.168.1.11:27017 }, { _id: 2, host: 192.168.1.12:27017 } ] })注意members里的host字段主机的名称和IP解析必须对得上。MongoDB在初始化后会在local.system.replset集合里保存这份配置后续节点之间通信都会按这个配置里的host去找对方。如果host填的是无法解析的主机名初始化大概率卡住然后报host unreachable。我建议填IP或者确保所有机器/etc/hosts里都能互相解析。初始化完成后通过rs.status()观察输出。当members里出现一个状态为PRIMARY的节点另外两个是SECONDARY时整个复制集就已经开始工作了。你可以在主节点上插入一条数据然后连到某个从节点上执行db.getMongo().setReadPref(secondary)或者直接rs.slaveOk()旧版本命令再查询这条数据能看到它已经同步过来了。还有一种常见情况你有3台机器但其中一台的host填错了比如拼写错误。只要复制集还没初始化成功直接执行rs.reconfig()就能修正。如果复制集已经初始化完成并开始同步修正host要更谨慎操作前先确认主节点是谁按官方文档步骤走不要随意reconfig否则可能触发不必要的选举。4. 数据同步核心oplog的细节与原理4.1 oplog是什么大小如何估算理解复制集必须理解oplog操作日志。oplog是一个特殊的、有上限的 capped collection存储在local.oplog.rs里。每当Primary执行一条写操作insert、update、delete、createIndex等它就把这条操作记录按顺序追加到oplog里然后从节点通过拉取这个日志来重放操作。oplog有两个关键参数一个是大小另一个是里面的记录条目。大小决定了“历史同步窗口”能有多长。比如你把oplog设为5GB而业务每秒产生10MB的写日志理论上它能保留大约8分钟到15分钟的历史取决于基数。一旦某个从节点因网络闪断或其他原因落后超过这个窗口它的同步进度就超过了oplog保留的历史范围此时它无法再通过增量日志追上主节点只能做一次全量重新同步。这个过程会消耗大量带宽和磁盘IO而且导致该节点长时间处于RECOVERING状态。很多初学者完全忽略oplog大小的设置直接用默认配置。MongoDB 4.4在WiredTiger引擎下如果你不显式配置oplog大小有默认公式对于64位系统默认是磁盘剩余空间的5%最少1GB最多50GB。对大部分生产系统5%远远不够我见过一个高峰期每秒几千次写入的环境默认oplog只能撑半小时任何一个从节点重启一下就要重新全量同步。实际操作中你要先估算业务高峰期每分钟会产生多少oplog数据方法是在Primary上执行db.getSiblingDB(local).oplog.rs.stats().size db.getSiblingDB(local).oplog.rs.stats().maxSize然后计算平均写入速率再乘以你希望容忍的“从节点最长停机时间”得到目标大小。假设峰值产生日志量约1MB/s希望从节点能容忍停机2小时那oplog至少需要1MB × 7200秒 ≈ 7.2GB可以把oplog设为10GB。size设置得大一些不会明显增加写放大因为oplog只是顺序追加磁盘空间按需分配除非你写满到maxSize否则不会有严重的性能开销。4.2 同步机制初同步与增量拉取的完整流程如果从节点是全新节点或数据已经严重落后它会先进行初始同步Initial Sync。过程大概是从节点先选择一个同步源通常选择离自己最近、数据最新的节点并不一定是Primary在local库的startup集合里记录同步状态然后从同步源拷贝所有数据库文件实际上是做一次文件级拷贝或类似的数据快照同时捕获当前oplog时间点。文件拷贝完成后再从头开始重放从那个时间点以来的所有oplog条目最终跟上同步源的进度。这个过程相当耗时尤其是数据量几百GB以上时一定要在业务低峰期操作同时确保磁盘有足够剩余空间——拷贝不会删掉原有数据。增量同步则一直持续。同步源通常是Primary从节点定期向它发送一个find命令以时间戳大于自身同步点的条件查询oplog然后逐条应用。这里有个很值得留意的机制从节点应用写操作时不会原样照搬命令直接执行而是把它们转换成语义一致的操作再执行保证即使不同节点上的索引、内部结构有细微差异最终数据也一致。举个具体事故事例有次我对一个从节点做维护在维护完成后发现它一直显示SECONDARY但数据却追不上来查mongo日志发现一直报“sync source cannot keep up”意思是它选的同步源恰巧也是另一个从节点性能很差拉oplog的速度跟不上写入速度。解决办法是手动指定同步源在mongo shell里执行db.adminCommand({replSetSyncFrom: host:port})把它切到Primary那张更快的源上延迟很快就归零了。这个操作在日常运维里非常有用。5. 故障切换与脑裂防护的实战验证5.1 模拟Primary宕机的完整过程技术方案写再多没有实际故障演练你根本不知道真实环境下会出什么问题。我是这么做的在某次业务低峰期直接对Primary执行shutdown命令模拟物理宕机。按下回车的那一瞬间业务侧立刻开始报错写操作返回NotWritablePrimary之类错误这是因为客户端还没感知到Primary已经变更。按MongoDB驱动默认行为这种“临时性写失败”会被驱动重试所以只要不是极老版本的驱动业务短暂报错后就能自愈。大约5秒左右两个从节点之一被选举为新的Primary复制集状态恢复为PRIMARY/SECONDARY应用层重新恢复正常读写。我在备用节点上执行rs.status()看到这样一段输出截取关键部分{ members : [ { _id : 0, name : 192.168.1.10:27017, health : 0, stateStr : (not reachable/healthy), uptime : 12345 }, { _id : 1, name : 192.168.1.11:27017, stateStr : PRIMARY, electionTime : Timestamp(1678000000, 1) }, { _id : 2, name : 192.168.1.12:27017, stateStr : SECONDARY } ] }从执行shutdown到新Primary选出来整个过程用时大约6到8秒比官方文档声称的10秒超时时间略短。这里有个关键体验写操作在切换窗口内大概1~2秒可能收到错误之后的写操作自动路由到新Primary。如果你的业务写入量大建议在驱动连接串里配置retryWritestrue同时在应用层对写失败做一定的重试才能做到真正意义上的“无感切换”。5.2 网络分区脑裂场景的安全机制还有一种更隐蔽、更危险的故障是网络分区。比如两台机器在同一机房第三台在异地机房中间的网络抖动把第三台孤立出去。此时第三台节点觉得自己和Primary失联尝试发起选举但由于它无法联系到其他两台中任意一台永远凑不齐大多数票最终它会转为SECONDARY状态并且只能对外报告“与主节点失去连接”不能独自变成Primary。这就防止了“两边都认为自己可以继续写”的脑裂。但真实世界有更复杂的场景例如3个节点分布在3个机房一边机房A和B通B和C通但A和C不通。这种拓扑下各个节点对“大多数”的感知不一样选举可能变得胶着最后的解决办法还是回到网络层面保证复制集节点之间的网络是两两联通的否则一切协议层面的努力都会被网络坑掉。实战中我还遇到过一个分区恢复后的“抖动”现象旧Primary在分区期间被刷新为Secondary但当网络恢复正常后它试图追赶新的Primary由于网络刚恢复心跳频率可能还没恢复稳定节点状态会在SECONDARY和PRIMARY之间换来换去。此时我建议等心跳稳定几分钟再观察rs.status()不要一看到状态异常就立刻手动reconfig。急于干预反而会触发不必要的选举延长抖动窗口。6. 高可用架构中的读写偏好与一致性权衡6.1 readPreference的四种模式怎么选复制集天然支持读写分离但何时能读从节点、读到的数据是否最新完全取决于你设置的readPreference读偏好。MongoDB提供了几种核心模式primary默认值所有读请求都发给Primary。这是最一致的读但读压力无法分散。primaryPreferred优先读PrimaryPrimary故障时读请求才转发到从节点。适合主节点故障时读仍可用的场景。secondary只读从节点。适合报表类、离线分析类任务。secondaryPreferred优先读从节点从节点不可用时才读Primary。适合对最终一致性容忍度较高的读场景。nearest根据网络延迟自动选择延迟最低的节点不考虑主从角色。适合多机房读取就近。举个例子一个商品详情页商品库存是强一致数据必须读Primary而销售排行、统计报表这类数据允许短时延迟就可以走secondaryPreferred。如果所有读都不加区分地走从节点在数据复制延迟较大时会出现用户刚下单成功刷新页面却看不到订单的尴尬。这种情况下订单查询就必须强制走Primary。我自己的诉求很明确读写都走Primary等同步延迟稳定后把一些重计算类查询切到从节点。配置方式可以在连接串里加readPreferencesecondaryPreferred也可以在代码里针对单条query设置。服务器端统一配置容易省事但代码级设置更精确你可以按接口重要性区分策略。6.2 writeConcern级别与数据安全的关系谈高可用不能只关注故障切换还要关心数据提交的安全性。writeConcern决定了Primary要把写操作确认到哪一步才返回成功。基本级别包括w: 1Primary本地写入成功即返回。性能最好但一旦发生主备切换可能有已提交到旧Primary但没同步到新Primary的数据。w: majorityPrimary必须收到复制集大多数节点写入成功的确认后才向客户端返回。此时即使某个节点直接拔电源其余节点也保存了这条数据不会出现新Primary缺数据的情况。w: 0只发送命令不等待确认。适合日志类数据丢了也无所谓。很多人一开始用默认w:1测试环境一切都好直到一次真实的主备切换后发现有一批刚写入的订单丢了才追悔莫及。我建议金融、交易、订单类数据最低配到w: majority配合journaling开启才能安全度过任意一次节点宕机。代价是每次写都要等待所有从节点确认延迟会比w:1高一些但和你丢数据的损失比起来这点延迟完全可以接受。还有一个容易被忽视的细节w: majority只保证数据进入多数节点的内存并写入journal不保证一定已经刷盘并且从MongoDB 4.2开始默认开启了majority级别的读关注所以多数派提交基本代表了真正的持久化。如果你极端在意持久性可以把journal: true加上确保每条写都写入WiredTiger日志而不是只留在内存里。7. 性能优化与运维踩坑记录7.1 从节点同步延迟过大怎么办主从延迟是复制集最常见的运维电话。每当延迟超过几秒甚至几十秒业务查询从节点就会读到明显旧的数据。我通常按以下顺序排查确认从节点的oplog剩余空间。如果local.oplog.rs.stats()里的timeDiff已经接近oplog的最大保留时间说明从节点可能马上要进入全量同步这是最需要警惕的信号。如果空间足够继续往下查。检查从节点所在的机器资源CPU使用率、IO等待、磁盘读写速率。复制集同步本质上是写操作如果从节点磁盘性能比Primary差延迟就会被无限放大。我有一次给从节点配备了低性能云盘结果Primary写入压力一大从节点立刻落后20秒。看从节点日志里有没有NoProgress或slow oplog application的提示。如果有说明oplog应用阻塞常见原因是集合上建立了很多索引每次应用一条更新都要同时更新索引整体开销变大。可以考虑从节点上延迟创建索引或者降低索引数量。检查网络带宽。跨机房复制时主备间的专线带宽一旦打满oplog拉取速度会急剧下降延迟自然飙升。这种场景下还要注意TCP的buffer大小和MongoDB复制的并发参数。7.2 选错同步源、隐藏节点与延迟节点的妙用从节点默认自动选择最合适的同步源但它的选择策略不一定最优。如果Primary写压力极大它同时还要服务从节点的oplog拉取此时你会看到从节点整体延迟随着Primary的负载波动。你可以手动把某个从节点的同步源指向另一个同步进度较新的从节点让Primary少承担一些同步I/O。我一般在3节点复制集里不至于这么做因为只有2个数据节点必须有一个从Primary拉取但如果扩展到5节点完全可以指定某几个节点从“同步进度最优秀且离自己近的节点”拉取进一步分摊流量。再讲两个生产环境的高级玩法隐藏节点hidden和延迟节点delayed。隐藏节点的priority为0同时hidden: true客户端即使设置了secondaryPreferred也读不到它但数据仍然同步适合用来做备份、跑批处理、做数据分析。延迟节点则是用secondaryDelaySecs参数故意让数据停止追赶Primary比如设置为3600秒那么它始终保存着“1小时前”的数据一旦业务误删了collection或数据被恶意篡改你可以从延迟节点找回1小时前的数据这个能力是任何备份策略的有效补充。我在一个生产项目里同时启用了一个隐藏节点和一个延迟节点隐藏节点每天凌晨在业务低峰期做mongodump全量备份延迟节点则作为最后一道防误删的数据保险。这个组合被验证是非常有效的多次挽回过因开发人员误操作导致的批量delete。7.3 监控、备份与日常巡检的实用脚本高可用不等于躺平。你需要一套基本的监控和巡检手段。部署方式比较成熟我推荐使用Prometheus mongodb_exporter采集复制集状态配合Grafana展示主从状态、oplog时间差、心跳延迟、复制滞后时间等指标。核心告警项包括复制集成员数少于预期没有Primary任意节点状态不是PRIMARY/SECONDARY/ARBITER同步延迟超过设定阈值比如30秒oplog剩余时间低于1小时如果没有现成的监控平台一个简单的crontab脚本也可以做基础巡检。脚本思路是登录每台机器用mongo执行rs.status()检查返回里的health字段和stateStr字段如果发现状态异常就发邮件或企业微信通知。别小看这种简陋脚本我接手过的大多数项目都是靠这种最原始的方式第一时间发现问题比复杂的监控平台更可靠因为监控平台本身也可能挂。备份是复制集的高可用闭环里绝不能省的一环。复制集能防止节点故障但防不住代码bug误删数据。一定要有独立的备份策略我推荐至少保留两种每天的物理备份通过mongodump或文件快照以及延迟节点快照。备份文件最好定期恢复到一台临时实例上做校验避免“备份文件损坏了却不知道”的灾难。8. 总结几点个人实战经验整个复制集从原理到落地我走过不少弯路最深的体会是复制集最大的敌人不是单个节点故障而是脑裂、数据丢失和运维盲区。在搭建之前就把多数派选举、writeConcern和隐藏节点这套组合拳想清楚比事后遇到故障再临时补方案成本低得多。每次故障演练都相当于给系统打了一次预防针我强烈建议你在测试环境反复演练拔电源、断网、交换重启这几种场景并记录下每次切换的耗时和业务影响程度。最后分享一个小技巧在把复制集交付给业务方之前写一个“复制集体检清单”逐项检查。包括所有节点的mongod是否以--replSet启动、host是否能互相解析、磁盘空间是否满足oplog增长、oplog大小是否足够、writeConcern是否已设置为majority、是否配置了隐藏节点和延迟节点、监控告警是否生效、备份任务是否成功跑通。我每次按这个清单走一遍心里就有底了——真正出问题时大概率是被这个清单里的某一项拦下来的。