一、副本集为何总"罢工"？

副本集就像一支足球队，每个节点都需要明确自己的定位才能配合默契。但实际部署时，经常出现守门员跑去当前锋、边后卫忘记站位的情况。最近处理过这样一个案例：某电商平台在促销活动前调整集群配置，结果导致整个订单系统瘫痪3小时。后来发现竟是某个节点的priority值设成了0，这个节点直接"摆烂"不再参与选举。

二、那些年我们踩过的配置坑

2.1 网络配置的隐形杀手

# 错误示例：mongod.conf配置片段
net:
  port: 27017
  bindIp: 127.0.0.1  # 只绑定本地回环地址，其他节点无法访问

replication:
  replSetName: rs0

这个配置会导致除本机外的其他节点根本无法建立连接。某金融公司生产环境就因此导致跨机房同步失败，监控系统显示节点间延迟持续超过15秒。

正确做法应该是：

net:
  port: 27017
  bindIp: 0.0.0.0  # 允许所有网络接口通信
  # 生产环境建议指定具体IP地址，如192.168.1.100,10.0.0.2

2.2 优先级设置的玄学问题

// 错误的主节点配置
rs.initiate({
  _id: "rs0",
  members: [
    { _id: 0, host: "node1:27017", priority: 0 },
    { _id: 1, host: "node2:27017", priority: 1 },
    { _id: 2, host: "node3:27017", priority: 1 }
  ]
})

这个配置让node1直接失去选举权，当主节点node2宕机时，集群将无法自动切换。某物流系统曾因此导致分拣系统中断，堆积上万件包裹无法处理。

2.3 主机名解析的致命玩笑

# 错误的主机名配置示例
$ mongo --host rs0/node1,node2,node3

当DNS解析不稳定时，这种配置可能导致节点间通信时断时续。某视频网站就因此出现播放记录不同步的问题，用户投诉量暴增。

推荐使用全限定域名：

rs.conf().members.forEach(member => {
  print(`正在检查 ${member.host} 的连接状态...`);
  // 输出示例：检查 node1.example.com:27017 的连通性
})

三、故障排查三板斧

3.1 日志分析的黄金十分钟

$ tail -n 100 /var/log/mongodb/mongod.log | grep -E 'error|warning'

重点关注以下日志特征：

  • "cannot resolve hostname"（主机解析失败）
  • "heartbeat failed"（心跳检测中断）
  • "not electing self"（选举异常）

3.2 配置验证的六个必查项

通过admin库执行：

// 查看副本集状态
rs.status().members.forEach(m => {
  printjson({
    name: m.name,
    stateStr: m.stateStr,
    pingMs: m.pingMs,
    lastHeartbeat: new Date(m.lastHeartbeat)
  })
})

3.3 网络诊断的几个关键命令

# 测试节点间连通性
$ mongo --host node2 --eval "db.adminCommand({ping:1})"

# 查看TCP连接状态
$ netstat -tulnp | grep 27017

# 测量网络延迟
$ tcpping node3:27017 -c 10

四、特殊场景生存指南

4.1 混合版本集群的兼容陷阱

当存在3.6和4.0版本节点混用时，某些配置参数会导致不可预知的错误。某游戏公司升级时就遇到oplog格式不兼容的问题，表现为副本集同步延迟持续增长。

4.2 云环境下的安全组陷阱

AWS EC2实例的安全组配置需要特别注意：

{
  "Inbound Rules": [
    {
      "Port Range": 27017-27019,
      "Source": "sg-xxxxxx"  // 必须包含所有节点所在安全组
    }
  ]
}

五、最佳实践手册

5.1 配置模板推荐

# production-replicaset.conf
storage:
  engine: wiredTiger
  journal:
    enabled: true

net:
  port: 27017
  bindIp: 192.168.1.100,10.0.0.2  # 双网卡配置
  maxIncomingConnections: 5000

replication:
  oplogSizeMB: 20480
  replSetName: rs-prod
  enableMajorityReadConcern: true

5.2 监控指标清单

  • 副本集健康状态（1分钟检测间隔）
  • Oplog窗口时间（保持大于72小时）
  • 节点延迟差异（不超过500ms）
  • 心跳丢失次数（每小时<3次）

六、技术全景分析

应用场景

适合需要高可用的在线交易系统，如电商订单、金融交易等对数据一致性要求较高的场景。某银行核心系统采用7节点副本集，实现跨三地容灾。

技术优缺点

优势在于自动故障转移和数据冗余，但维护成本较高。相比单节点部署，资源消耗增加2-3倍，适合日均请求量超百万的系统。

注意事项

  1. 预生产环境必须做全量故障演练
  2. 跨版本升级前需验证配置兼容性
  3. 定期检查oplog使用情况
  4. 避免在业务高峰期调整配置

七、文章总结

正确的副本集配置如同精密的瑞士手表，每个齿轮都必须严丝合缝。通过本文的实战案例和排查方案，我们系统性地梳理了五大典型配置错误及其解决方法。记住，配置变更后的48小时是观察黄金期，需要密切监控选举次数、同步延迟等关键指标。良好的配置管理习惯，才是保障数据库高可用的终极武器。