如果只能用一个词来概括我这些年使用 MongoDB 的最大体会我会选“复制集”。刚接手团队项目时所有读写都压在一台单实例 MongoDB 上虽然每周都有备份但一次磁盘故障直接让我清醒过来——备份恢复花了七个多小时业务停摆全公司都在盯着我。那次事故之后我把 MongoDB 复制集Replica Set列进了最高优先级目标很明确构建真正的高可用数据架构。很多人对复制集有误解以为它就是“多放几份数据”。实际上复制集是一组维护同一数据集的 MongoDB 进程它的核心价值是“故障自愈”在多数派节点存活的情况下主节点发生故障集群自动完成选举和切换应用感知不到主节点已经换人。这是单机加备份做不到的。我写这篇文章是想把复制集的工作原理拆开讲清楚然后带着大家从零搭一套三节点集群最后聊聊那些只有上线才会踩到的坑。不管你是准备在团队里引入 MongoDB 的架构师还是刚学 MongoDB、刚刚弄明白数据库database、集合collection、文档document这些基础概念的初学者这篇文章都值得往下看。复制集不是一个遥不可及的运维黑科技它是一套有清晰规则的协议集看懂了搭起来并不难。1. 复制集到底解决了什么问题先想清楚再动手1.1 单节点架构的隐患在哪里单节点 MongoDB 给人最大的错觉是“我的数据有备份不怕丢”。但备份解决的是“灾难恢复”解决不了“可用性”。磁盘损坏、进程被 OOM Killer 干掉、机房断电、网络故障任一种情况都会让单节点直接不可用。我遇到过最典型的一次事故业务高峰期主库所在磁盘满了mongod 开始疯狂报错最后进程退出。因为磁盘 I/O 已经异常连备份恢复都变得极其缓慢最终从远程拉出一份几天前的备份才勉强恢复。那几天里所有写操作全部丢失业务方只能手工补单。这就是单节点的真实日常——备份只保证你不会彻底归零但恢复时间完全不可控。复制集的价值在于它把“一份数据”变成了“同一份数据实时存在于多个节点”。主节点挂了只要还有多数派节点活着集群就能自动选出新主节点继续服务。客户端连接的地址不变写操作继续往新主节点打整个过程甚至不需要人介入。1.2 复制集不是“多副本自动备份”我必须先把一个误区纠正过来复制集不等于备份。它的多副本机制确实让数据有了冗余但如果你把复制集当成备份来用迟早会吃亏。原因很简单复制集里所有节点维护的是同一份数据集你在主节点上执行drop database这条操作会写进 oplog然后被所有从节点原样执行。误操作不会因为你有三副本而幸免反而会以更快的速度扩散到所有机器。备份和高可用是两个维度的东西。复制集解决的是“节点故障时服务不中断”备份解决的是“数据损坏或误操作时能回到过去某个时间点”。两条腿都要走路后面我会专门讲怎么把备份策略和复制集配合起来。1.3 三种角色Primary、Secondary 和 Arbiter复制集里的每个节点承担不同职责先从最基本的三种角色说起这张表建议收藏。角色是否存数据是否参与投票默认接受客户端读写Primary是是读写都接受Secondary是是不读不写需通过secondaryOk开启读Arbiter否是不接受你可以用生活类比来理解Primary 是正职员工所有正式业务都必须经过他Secondary 是副手平时不接客但正职出事马上顶上去Arbiter 更像一个只出席董事会投票的外部顾问不干活但关键时候那票很管用。关于 Arbiter 有一个最常见的疑问能不能用两个数据节点加一个仲裁节点来省一台机器可以但代价也要想清楚。仲裁节点不存数据一旦唯一的数据节点也挂了集群里就没数据可用了。仲裁节点适合“你有偶数个数据节点、想避免选举票数打平”的场景不适合作为“降低成本替代第三台数据机器”的手段。这一点后面会单独展开。2. 复制集核心机制心跳、选举与 oplog2.1 心跳机制与节点状态感知复制集里所有节点之间每 2 秒发送一次心跳包这是节点之间感知彼此存活的底层机制。如果主节点超过一定时间默认是 10 秒没有响应其他节点就会把它标记为不可达并触发新一轮选举。节点状态可以在rs.status()里看到常见的状态有PRIMARY、SECONDARY、ARBITER、RECOVERING、STARTUP。health字段表示节点是否可达1是健康0是失联。lastHeartbeat和lastHeartbeatRecv两个时间戳能帮你判断心跳是否正常收发。这里有个实际运维中很容易碰到的坑云环境网络抖动。如果主节点和从节点之间因为网络波动出现心跳超时从节点会发起选举导致主节点被“误杀”。网络恢复后旧主节点重新加入集群发现自己已经不是多数派又会发起新一轮选举。结果就是主节点反复切换业务读写抖动日志里全是 election 相关记录。遇到这类问题先别急着动配置第一步是确认是不是网络质量导致的。如果是跨可用区部署专线延迟和丢包率必须重点盯。如果只是偶发抖动频繁触发误判可以在复制集配置里适当调大electionTimeoutMillis默认值是 10000 毫秒可以调整到 15000 或更大给网络抖动多留一点容忍窗口。2.2 选举原理Raft 协议在 MongoDB 里的落地MongoDB 的选举机制脱胎于 Raft 协议核心规则可以浓缩成几句话每个节点都有投票权法定人数必须超过半数得票超过半数的节点成为主节点选举只在节点确认当前主节点不可达时触发。为什么要强调“超过半数”因为这是防止“脑裂”的关键。想象一个五节点集群被网络切成了两个分区一边三个节点一边两个节点。三个节点的分区内部票数可以达到多数它们可以选出新主节点继续工作两个节点的分区无论如何都凑不够三票即使它们内部以为自己是主也无法通过选举确认最终只能干瞪眼。这种设计保证了整个集群在任何网络分区情况下都不会同时出现两个被“合法确认”的主节点。客户端可以通过多数派视角始终知道谁是真正的主数据不会出现双主同时写入的混乱局面。priority参数在选举中也扮演重要角色。默认所有节点 priority 都是 1选举时机会均等。你可以把某个性能更好的节点 priority 调高让它更倾向于成为主节点也可以把节点 priority 设为 0表示该节点永不参与主节点竞选。这个参数经常被用来“指定主节点”比如把一台配置更高的机器作为首选主节点故障恢复后它会自动重新竞选为主。这里还有一个容易被忽略的限制一个复制集最多只能有 7 个投票节点。节点数量超过 7 个之后多余的节点必须设置votes: 0它们不参与选举只同步数据通常用来扩展读能力。记住这个上限设计大规模复制集时会用到。2.3 oplog复制数据的核心日志oplog 是复制集最核心的数据结构它本质上是一个 capped collection存放在每个节点的 local 数据库里。主节点上的每一次写操作——插入、更新、删除也就是你在日常开发里做的那些文档数据增删改查——都会被记录成一条 oplog 条目。oplog 条目里携带了时间戳ts、操作类型op、命名空间ns、操作详情o等信息。从节点做的非常简单定期从主节点拉取 oplog然后在自己本地重放这些操作实现数据同步。你可以理解成主节点写了一个操作流水账从节点拿着这本流水账一遍又一遍地在自己身上执行。oplog 大小是可配置的默认取磁盘可用空间的 5% 或者为一个固定下限值。问题是如果写入量很大默认大小可能只覆盖几个小时的写入一旦从节点离线时间超过这个窗口它就会因为找不到对应的 oplog 记录而无法续传只能触发全量同步。我见过很多团队在生产环境遇到的第一起复制集事故就是从这里开始的后面会有专门的章节讲这个坑。查看 oplog 状态用rs.printReplicationInfo()重点关注两个指标configured oplog size是当前大小log length表示 oplog 还能覆盖多长时间的历史写入。如果你的业务写入量大建议把log length维持在 24 小时以上给从节点离线恢复留足缓冲。2.4 网络分区、脑裂风险与回滚机制理解了选举和 oplog就能顺理成章推出回滚rollback机制存在的意义。假设三个节点 A、B、CA 是主节点。突然之间网络发生分区A 和 B、C 失去联系但 B 和 C 之间还能通信。此时 B、C 构成多数派它们会选 B 成为新主节点继续接收写操作。而 A 那边因为网络隔离它不知道 B 已经当选仍然以为自己还是主节点继续接收客户端写入。网络恢复后A 会发现 B 才是当前主节点自己只能降级为从节点。问题来了A 在自己的“孤立期”里接收的那些写操作B 上根本没有这些数据如何处理答案就是回滚。A 会把这些未被 B 复制过的操作从自己的数据中回滚掉回滚的数据会被写入 rollback 目录下的 BSON 文件里管理员可以手动恢复。回滚本质上是数据一致性机制不是“丢数据”但处理不当会造成业务侧困惑——客户端明明收到过“写入成功”事后数据却消失了。想要最大限度减少回滚发生的概率光靠复制集自身是不够的客户端写入时必须配合足够的写关注级别。这就是接下来要聊的 write concern 问题你会发现很多看似高深的机制最终都回到了“客户端如何确认写入成功”这个原点。3. 从零搭建三节点复制集完整实战过程3.1 环境规划与安装搭建复制集最少需要三台机器但如果你只是学习和验证原理本机模拟完全够用。在一台机器上启动三个 mongod 实例分别占用 27017、27018、27019 端口数据目录也分开效果上等价于三台独立服务器。安装方面根据你的操作系统选择对应方式Debian/Ubuntu 用 aptCentOS/RHEL 用 yummacOS 用 brew。需要留意的是 MongoDB 版本建议选择 4.4 以上的版本当前社区版稳定版本通常已经到 6.x 或 7.x功能差异不大。安装失败的场景我见过不少多半是端口被占用、依赖版本不匹配、磁盘路径没有创建按日志一步步排查即可。本机模拟的节点规划如下实际生产环境把 IP 换成内网地址即可。实例名IP端口数据目录角色mongodb-1127.0.0.127017/data/mongodb-1Primarymongodb-2127.0.0.127018/data/mongodb-2Secondarymongodb-3127.0.0.127019/data/mongodb-3Secondary在开始之前你至少需要知道 MongoDB 的基础数据模型数据库database是命名空间集合collection类似关系型数据库的表文档document则是一行一行的数据。复制集复制的是整个实例里所有数据库的数据所以安装好之后无论你在哪个库建集合所有节点都会跟着同步。3.2 配置文件怎么写每个 mongod 实例都需要一份配置文件下面这份是三节点通用模板只需修改端口、路径、bindIp。systemLog: destination: file path: /var/log/mongodb/mongod.log logAppend: true storage: dbPath: /var/lib/mongo journal: enabled: true processManagement: fork: true pidFilePath: /tmp/mongod.pid net: port: 27017 bindIp: 127.0.0.1 replication: replSetName: rs0三个节点的replSetName必须完全一致这是它们能够互相识别并组成同一个复制集的前提。bindIp在云服务器上要注意别只绑 127.0.0.1否则其他节点无法通过内网 IP 访问你也不要绑 0.0.0.0 直接暴露到公网安全风险太大。本机模拟时三份配置除了 dbPath、pidFilePath、port 不同其他都保持一致。启动命令如下。mongod -f /etc/mongod-1.conf mongod -f /etc/mongod-2.conf mongod -f /etc/mongod-3.conf启动成功后用ps aux | grep mongod确认三个进程都在然后进入下一步。3.3 初始化复制集用 mongosh 连接任意一个实例执行初始化命令。mongosh 是 MongoDB 官方推荐的新版 shell旧 mongo shell 在新版本里已经不再推荐使用。mongosh mongodb://127.0.0.1:27017,127.0.0.1:27018,127.0.0.1:27019/?replicaSetrs0 rs.initiate({ _id: rs0, members: [ { _id: 0, host: 127.0.0.1:27017 }, { _id: 1, host: 127.0.0.1:27018 }, { _id: 2, host: 127.0.0.1:27019 } ] })看到{ ok: 1 }说明初始化成功。接着执行rs.status()你会看到三个节点的 stateStr 分别为 PRIMARY 和 SECONDARY。再执行rs.isMaster()可以快速确认当前连接实例是不是主节点。有个细节容易绕晕从节点默认不接受客户端的读取请求连接从节点执行查询会报“not primary and secondaryOkfalse”之类的错误。需要执行rs.secondaryOk()才会开放从节点的读能力。这个设计是为了防止业务默认读从节点时拿到不一致的旧数据。应用侧的连接串也有讲究一次性把所有节点地址写上并带上 replicaSet 参数driver 才会感知复制集并自动切换。mongodb://127.0.0.1:27017,127.0.0.1:27018,127.0.0.1:27019/?replicaSetrs0很多新手只写一个地址导致主节点切换后应用全部报连接失败问题往往就出在连接串上。3.4 模拟主节点宕机验证自动切换复制集搭好之后不做故障演练等于白搭。这里演示一下最简单的主节点宕机模拟。第一步确定当前主节点。rs.isMaster().primary第二步直接给主节点进程发送 kill 信号模拟宕机。kill -9 主节点进程PID第三步等待大约 10 到 30 秒重新连接另一个节点执行rs.isMaster()你会发现 primary 已经变成了刚才的某个从节点。这是因为其他节点发现主节点心跳超时自动发起了选举。第四步重新启动刚才被 kill 掉的旧主节点。它会自动加入复制集变成 SECONDARY 状态并逐步从新主节点补齐这段时间的增量数据。整个过程不需要任何人工干预这就是复制集对业务最大的价值。正式环境里建议用rs.stepDown()来做优雅切换而不是 kill -9这个命令会让当前主节点主动让位同步过程更平滑。4. 上线前必须知道的四个坑我替你趟过了4.1 仲裁节点的误用仲裁节点最大的卖点是“不占存储、便宜”这导致很多人想出“两台数据节点加一个仲裁”的省成本方案。表面看起来票数凑够了但仔细推演一下容错能力就会发现差距。两个数据节点 A、B 加仲裁 C 的配置最多容忍一个节点故障。如果 A 挂了剩下 B 和 CB 拿到两票可以当选为主节点。但如果 A 挂了之后 C 也挂了整个集群就只剩 B 一个节点票数 1 不足半数直接无法选举出主节点集群不可写。对比三个数据节点的配置同样容忍一个节点故障但挂掉一台后还有两台数据节点同时承载读写容量没有折半。两台数据节点加仲裁的配置挂掉一台数据节点后只能靠唯一一台数据节点硬扛所有流量瓶颈非常明显。我的建议是能用三数据节点就用三数据节点仲裁节点只在你确实只有两个数据节点且不想增加存储成本时使用。别为了省一台机器的钱把高可用架构的容灾能力搭在刀尖上。另外仲裁节点也是一台真实存在的服务器也需要维护和监控它的宕机同样会改变投票格局。4.2 write concern 与 read preference 配置不当很多业务接入复制集后代码逻辑完全没变写入还是默认的w: 1也就是主节点确认写完就返回成功。这种配置在正常运行时没问题但一旦主节点发生故障问题就暴露了。举个例子客户端向主节点写入一条订单数据w:1模式下主节点返回成功。但这条数据还没来得及同步到从节点主节点突然宕机。复制集选出新主节点后新主节点根本没有这条订单数据旧主节点恢复连入后这条数据还会因为回滚机制被清理掉。客户端明明收到了写入成功数据却没了业务上这就是严重事故。解决方案是给核心业务设置w: majority让写入必须被多数派节点确认后才返回成功。这样即使某个节点宕机数据也已经存在于其他节点上不会因为选举被回滚。对应的读偏好read preference也需要根据业务场景谨慎选择默认的 primary 模式读数据一致性最好secondary 模式可能读到秒级延迟的旧数据适合报表、日志查询这类对实时性要求不高的场景。连接串里同时配置写关注和读偏好的写法如下。mongodb://host1:27017,host2:27017,host3:27017/?replicaSetrs0wmajorityreadPreferencesecondaryPreferred这里要特别提醒不要把所有业务一刀切都设成w: majority它带来更高一致性的同时也有性能开销尤其在高并发写入场景下延迟会上升。核心交易数据严格要求非核心数据可以适当放宽。4.3 oplog 太小引发的从节点同步灾难生产环境里最常见的复制集故障不是节点宕机而是从节点离线太久后“追不上”数据最终触发全量同步。全量同步意味着从零拷贝整个数据集期间从节点不可用网络带宽被占满整个复制集性能都会受影响。我之前有套集群主库每天产生大约 30GB 的 oplog 写入量默认 oplog 大小只够覆盖五六个小时。某个从节点因为机架维护离线了一天重新拉起来后直接进入 RECOVERING 状态日志里报找不到对应时间戳的 oplog只能做 initial sync 全量同步。那次全量同步拷了接近一整天期间业务延迟飙升。修复办法很简单调大 oplog 大小。MongoDB 提供了在线调整命令不需要重建节点。db.adminCommand({ replSetResizeOplog: 1, size: 40960 })单位是 MB上面这条命令把 oplog 调整为 40GB。调整后再执行rs.printReplicationInfo()会发现log length明显变长。经验值上我会让 oplog 至少能覆盖 24 小时的写入量写入密集的业务建议 48 小时以上给节点故障和人工介入留足时间。4.4 网络抖动、时钟漂移与认证安全复制集是强依赖网络健康状态的架构。心跳超时误判主节点故障、选举期间业务抖动、旧主节点恢复后反复切换这些现象背后的根源往往不是 MongoDB 本身而是底层网络质量不稳定。跨可用区部署时专线延迟和丢包率必须纳入监控指标。时钟漂移也是一个容易被忽视的问题。MongoDB 的 oplog 时间戳和选举逻辑都依赖系统时钟如果各节点时间不同步会导致复制顺序异常、监控误判。官方建议所有节点配置 NTP 统一时钟这是非常必要的基操别跳过。安全方面多说一句复制集节点之间传输的数据默认没有加密生产环境一定要启用 TLS 加密同时用防火墙限制 27017 端口只允许内网访问。这一点我会在下一节展开讲认证配置因为很多团队搭好了高可用却连最基本的数据库安全认证都没开等于把数据库敞在公网里裸奔。5. 复制集的日常运维与进阶认证、备份、监控与扩展5.1 开启认证高可用集群的及格线没有开启认证的 MongoDB 集群任何人只要网络能连通就可以直接连上来读写数据这种状态在任何生产环境里都是不合格的。复制集成型之后第一件事就是开启认证。推荐的顺序是先创建管理员用户再开启认证最后重启所有节点。创建管理员需要在未开启认证的实例上执行。use admin db.createUser({ user: admin, pwd: your_strong_password, roles: [root] })然后在 mongod.conf 里加两段配置。security: authorization: enabled keyFile: /etc/mongodb-keyfilekeyFile 是复制集节点之间的内部认证凭据所有节点必须使用内容完全一致的同一个文件权限建议设为 600。开启认证后业务连接串要带上用户名密码和 authSource。mongodb://admin:passwordhost1:27017,host2:27017,host3:27017/?replicaSetrs0authSourceadmin这里有个小提醒开启认证前先确认所有节点的 keyFile 都就位且一致否则节点之间会无法互相认证复制集直接失去同步能力。我曾经在一台节点上漏放了 keyFile重启后其他节点全部报认证失败排查了大半天才反应过来。5.2 备份策略复制集永远替代不了备份前面已经说过复制集会把误操作同步到所有节点所以备份必须独立于复制集存在。一个可靠的备份体系通常由三个部分构成定期全量备份、增量备份、定期恢复演练。日常备份最省力的方案是使用隐藏节点。你可以在复制集里加一个hidden: true的从节点它不接收客户端读请求专门用来做备份。备份时在这个隐藏节点上执行db.fsyncLock()冻结写入然后做文件系统快照或直接拷贝数据目录完成后执行db.fsyncUnlock()解锁。这样备份不会干扰主节点的业务负载。如果担心误操作找回数据可以再加一个延时节点配置slaveDelay: 3600让这个节点延迟一小时应用主节点的数据。某次误删集合后你在一小时内还能从延时节点找回数据。延时节点的配置参数如下。rs.add({ host: 192.168.1.14:27017, priority: 0, hidden: true, slaveDelay: 3600 })备份之后最重要的一个动作是恢复演练。我见过不止一个团队备份文件在物理机上躺了几个月从未验证等到真正需要恢复时才发现文件损坏或者恢复流程早已行不通。务必备份完就立即在测试环境做一次恢复验证这应该成为例行操作而不是救援时才发现的问题。5.3 关键监控指标和告警阈值复制集上线后监控是你的第二双眼睛。核心监控指标其实不多但每一条都对应一类典型故障信号。指标查看方法异常信号节点健康状态rs.status().members[].health0 表示节点失联节点角色rs.status().members[].stateStrRECOVERING 表示正在同步同步延迟rs.status().members[].optimeDate与主节点时间差持续增大心跳时间lastHeartbeat长时间未更新说明网络问题oplog 覆盖时长rs.printReplicationInfo()小于 24 小时需要扩容推荐的告警项包括主节点切换事件、任一节点 health 等于 0、从节点 oplog 同步延迟超过阈值、节点长时间处于 RECOVERING 状态。这些告警做到位大部分复制集故障都可以在影响业务之前被捕捉到。5.4 什么时候该升级到分片集群复制集解决的是高可用问题它解决不了单机容量和吞吐上限。当你的数据集涨到几个 TB单节点内存放不下热数据或者写入 QPS 已经逼近单机极限复制集再怎么调参数也顶不住这时候就该考虑分片集群。分片集群里每个 shard 本身依然是一个独立的复制集每个分片内部仍然依赖心跳、选举、oplog 这套机制来保证高可用。所以说复制集是 MongoDB 架构的地基先把地基打扎实后面上分片才不慌。这里也想给一个提醒不要为了“架构先进”而过早分片。分片带来的是路由节点、配置服务器、数据均衡等一整套额外运维复杂度如果业务数据量还在可控范围一个三节点复制集加合理索引和缓存往往比过早分片更可靠、更省心。什么时候上分片判断标准只有一个现有复制集是否明确压不住了。我自己在实际操作中最深的体会是复制集给你的是“少一次事故”的底气但它不是一个保险柜。误操作、配置错误、备份失效这些坑它统统盖不住。搭好复制集只是第一步把心跳、oplog、网络、认证这些细节都盯住定期做故障演练才是高可用架构真正落地的地方。如果你刚开始接触复制集建议先在本机用三实例模拟一遍把切换过程和数据流跑通再上生产会踏实很多。