MongoDB 三节点副本集 + 第三方仲裁落地部署全流程

针对中小型业务，三节点副本集 + 第三方仲裁 是成本最低、运维最简单的生产级容灾方案。本文将从环境准备、节点部署、集群初始化、核心配置、验证测试、运维最佳实践全流程落地，确保部署后可直接承载业务。同时，为便于选型确认，先明确本方案与另外两个双机房容灾方案的核心差异，帮助业务锁定最优落地路径。

一、方案核心架构与规划

1. 方案1与方案2、方案3核心对比（选型关键）

结合双机房容灾的3套核心方案，从节点配置、成本、运维难度等维度对比，明确方案1（三节点+第三方仲裁）的适配场景，具体如下表所示：

对比维度	方案1：三节点副本集+第三方仲裁（本文落地方案）	方案2：五节点副本集（无第三方机房折中）	方案3：分片集群双机房（大型/海量数据）
节点配置	DC1（1主）+ DC2（1备）+ 第三方（1仲裁），共3节点，仲裁节点低配置（1核2G）	DC1（1主+1备）+ DC2（2备）+ 第三方边缘（1仲裁），共5节点，均为数据节点（2核4G及以上）	Config Server（3节点+仲裁）+ 多个Shard（每个Shard为方案1/2副本集）+ 双机房Mongos路由，节点数量随分片增加
成本	低（仅2个数据节点+1个低配置仲裁，无额外硬件/运维成本）	中（4个数据节点+1个仲裁，硬件成本比方案1高60%+）	高（多组副本集+路由节点，硬件、运维、部署成本均最高）
运维难度	极低（架构极简，仅需维护3个节点，副本集原生管理，无需额外组件）	中等（节点数量多，需维护5个节点，同步策略与故障排查复杂度略增）	极高（需维护分片、配置服务器、路由节点，涉及分片均衡、元数据管理等复杂操作）
容灾能力	满足机房级容灾，DC1宕机后10-30秒自动切换至DC2，开启w:majority可实现数据零丢失，可用性99.9%	容灾能力更强，任意单机房宕机均能自动选举主节点，数据冗余更高，可用性99.95%	容灾能力拉满，单分片/单机房故障不影响整个集群，支持水平扩展，可用性99.99%
适用场景	中小型业务、非核心系统，数据量GB级，并发量适中，追求成本与容灾的平衡（首选）	中型业务，无法提供第三方机房，对可用性要求较高，数据量GB-TB级	大型/核心业务，TB/PB级海量数据，高并发场景，需无限水平扩展能力
升级兼容性	极佳，后续业务扩容可直接升级为方案2或方案3，无需重构数据与架构	较好，可升级为分片集群，需新增路由与配置节点	无需升级，可通过新增分片实现扩容

小结：方案1是中小型业务的最优解，以最低成本实现机房级容灾，运维成本低、落地速度快，且具备良好的升级兼容性，完全满足中小业务的核心需求。

2. 方案1节点分布（核心原则：奇数节点+仲裁隔离）

机房	节点角色	服务器配置（中小型参考）	IP地址规划（示例）	核心作用
主机房DC1	Primary（主节点）	2核4G + 50G SSD	192.168.1.10	接收读写请求，负责数据写入
备机房DC2	Secondary（备节点）	2核4G + 50G SSD	192.168.2.10	实时同步数据，只读，备机切换
第三方机房	Arbiter（仲裁节点）	1核2G + 20G 普通磁盘	192.168.3.10	仅参与投票，不存数据，防脑裂

3. 关键前提

• 三节点网络互通 ：DC1与DC2通过光纤专线互联（延迟<5ms），第三方机房与两个机房内网连通；
• 操作系统统一：推荐 CentOS 7/8 或 Ubuntu 20.04（本文以CentOS 7为例）；
• 磁盘规划：数据盘使用SSD，备节点与主节点磁盘IO性能一致（保证同步效率）；
• 关闭防火墙/开放端口：统一关闭防火墙（生产建议仅开放必要端口），MongoDB默认端口 27017。

二、环境准备（所有节点统一操作）

1. 系统优化（生产必做）

# 1. 关闭SELinux
sed -i 's/^SELINUX=enforcing/SELINUX=disabled/' /etc/selinux/config
setenforce 0

# 2. 关闭Swap（MongoDB禁止使用Swap，影响性能）
swapoff -a
sed -i '/swap/s/^/#/' /etc/fstab

# 3. 优化内核参数（编辑/etc/sysctl.conf）
cat >> /etc/sysctl.conf << EOF
fs.file-max = 6553560
net.ipv4.tcp_syncookies = 1
net.core.somaxconn = 65535
vm.max_map_count = 262144
EOF
sysctl -p

# 4. 优化文件句柄（编辑/etc/security/limits.conf）
cat >> /etc/security/limits.conf << EOF
mongod  soft  nofile  65535
mongod  hard  nofile  65535
EOF

# 5. 创建运行用户与目录
useradd -m mongod
mkdir -p /data/mongodb/{db,log,run}
chown -R mongod:mongod /data/mongodb

2. 安装MongoDB（稳定版推荐）

以MongoDB 7.0（当前稳定版）为例，所有节点执行：

# 1. 配置yum源
cat > /etc/yum.repos.d/mongodb-org-7.0.repo << EOF
[mongodb-org-7.0]
name=MongoDB Repository
baseurl=https://repo.mongodb.org/yum/redhat/7/mongodb-org/7.0/x86_64/
gpgcheck=1
enabled=1
gpgkey=https://www.mongodb.org/static/pgp/server-7.0.asc
EOF

# 2. 安装MongoDB
yum install -y mongodb-org

# 3. 锁定版本（避免自动升级）
yum install -y yum-versionlock
yum versionlock add mongodb-org

# 4. 启动并设置开机自启
systemctl start mongod
systemctl enable mongod

# 5. 验证安装
mongod --version  # 输出7.0.x即为成功

三、核心配置修改（分节点配置）

1. 主节点（DC1：192.168.1.10）配置

编辑 /etc/mongod.conf，替换原有内容：

# 数据存储路径
storage:
  dbPath: /data/mongodb/db
  journal:
    enabled: true  # 开启日志，保证数据一致性
  wiredTiger:
    collectionBlock:
      compressor: snappy  # 开启压缩，节省磁盘空间

# 网络配置
net:
  port: 27017
  bindIp: 0.0.0.0  # 允许所有IP访问（生产可指定内网IP）

# 副本集配置
replication:
  replSetName: rs0  # 副本集名称，所有节点必须一致
  oplogSizeMB: 1024  #  oplog大小，建议根据磁盘分配（1-5GB）

# 系统日志
systemLog:
  destination: file
  path: /data/mongodb/log/mongod.log
  logAppend: true
  level: info  # 生产建议info级别，故障时可调整为debug

# 进程管理
processManagement:
  fork: true
  pidFilePath: /data/mongodb/run/mongod.pid

2. 备节点（DC2：192.168.2.10）配置

与主节点配置完全一致（直接复制主节点配置文件即可）：

scp root@192.168.1.10:/etc/mongod.conf /etc/mongod.conf

3. 仲裁节点（第三方机房：192.168.3.10）配置

仲裁节点无需数据目录，核心配置如下：

编辑 /etc/mongod.conf：

# 核心差异：仅保留必要配置，关闭数据存储
storage:
  dbPath: /var/lib/mongo  # 临时目录，无需持久化数据
  journal:
    enabled: false  # 仲裁节点无需日志

net:
  port: 27017
  bindIp: 0.0.0.0

replication:
  replSetName: rs0  # 与副本集名称一致

systemLog:
  destination: file
  path: /var/log/mongodb/mongod.log
  logAppend: true

processManagement:
  fork: true
  pidFilePath: /var/run/mongodb/mongod.pid

# 关键配置：仅作为仲裁节点，不参与数据同步
replication:
  replSetName: rs0
  arbiterOnly: true  # 核心标识，必须开启

4. 重启所有节点使配置生效

# 主节点、备节点、仲裁节点均执行
systemctl restart mongod

四、初始化副本集（仅在主节点操作）

1. 登录MongoDB Shell

mongosh  # 或 mongo（旧版）

2. 初始化副本集

执行以下初始化命令，定义三个节点的角色：

// 初始化副本集配置
rs.initiate({
  _id: "rs0",  // 与配置文件中replSetName一致
  members: [
    { _id: 0, host: "192.168.1.10:27017", priority: 1 },  // 主节点，优先级1
    { _id: 1, host: "192.168.2.10:27017", priority: 1 },  // 备节点，优先级1
    { _id: 2, host: "192.168.3.10:27017", arbiterOnly: true }  // 仲裁节点
  ]
})

3. 验证初始化结果

执行 rs.status()，输出以下信息即为成功：

• myState: 1（主节点状态）；

• members数组中：

  • 192.168.1.10：stateStr: "PRIMARY"；
  • 192.168.2.10：stateStr: "SECONDARY"；
  • 192.168.3.10：stateStr: "ARBITER"。

五、核心安全与性能优化

1. 开启身份认证（生产必做）

默认情况下MongoDB无需认证，存在安全风险，需手动创建管理员用户：

// 1. 切换到admin数据库
use admin

// 2. 创建root管理员用户（仅主节点执行，备节点会自动同步）
db.createUser({
  user: "mongoadmin",
  pwd: "你的强密码（建议16位以上，含大小写+数字+特殊字符）",
  roles: ["root"]  #  root权限，生产可根据需求分配最小权限（如dbAdminAnyDatabase）
})

// 3. 验证用户创建
db.auth("mongoadmin", "你的强密码")  // 输出1即为成功

修改所有节点的配置文件，开启认证：

# 在/etc/mongod.conf中添加
security:
  authorization: enabled  # 开启认证

重启所有节点：systemctl restart mongod

2. 配置读写分离（业务侧）

备节点仅支持只读请求，业务端需配置读偏好，减轻主节点压力：

示例：Java驱动配置（Spring Boot）

spring:
  data:
    mongodb:
      uri: mongodb://mongoadmin:你的强密码@192.168.1.10:27017,192.168.2.10:27017/admin?replicaSet=rs0&readPreference=secondaryPreferred&w=majority

• readPreference=secondaryPreferred：优先读备节点，备节点不可用时读主节点；
• w=majority：写操作需多数派节点确认，保证数据零丢失。

3. oplog与备份配置

• oplog大小：根据磁盘空间分配，建议1-5GB，过小会导致同步频繁失败；
• 备份策略：每日全量备份 + 每小时增量备份（基于oplog），备份工具推荐 mongodump 或云厂商托管备份。

六、容灾验证与故障演练

1. 基础功能验证

// 1. 主节点写入数据
use test
db.user.insert({name: "test", age: 20})

// 2. 备节点读取数据（需先登录，执行auth）
use test
db.user.find()  // 输出与主节点一致，说明同步成功

2. 故障切换演练（核心：验证容灾有效性）

场景1：主节点宕机

# 在主节点（192.168.1.10）执行，模拟宕机
systemctl stop mongod

在备节点执行 rs.status()，观察10-30秒内：

• 备节点（192.168.2.10）自动变为 PRIMARY；
• 仲裁节点仍为 ARBITER；
• 业务端重新连接后可正常写入数据。

场景2：主节点恢复（切换回原主）

# 恢复主节点服务
systemctl start mongod

执行 rs.status() 观察：

• 原主节点自动变为 SECONDARY，并同步备节点数据；
• 主节点仍为当前活跃的备节点（无需手动切换）。

3. 网络割裂验证（防脑裂）

模拟DC1与DC2网络中断：

# 在DC1节点执行，阻断与DC2/第三方机房通信
iptables -A OUTPUT -d 192.168.2.0/24 -j DROP
iptables -A OUTPUT -d 192.168.3.0/24 -j DROP

验证：

• 仲裁节点仍在线，主节点不会分裂为双主；
• 恢复网络后，节点自动同步数据，无数据丢失。

七、中小型业务运维最佳实践

1. 日常监控（必做）

推荐使用 Prometheus + Grafana + MongoDB Exporter，核心监控指标：

指标名称	阈值	告警策略
节点状态	非UP/ARBITER	立即告警
复制延迟（lag）	>1s	1分钟内未恢复则告警
磁盘使用率	>85%	立即扩容
写成功率（w:majority）	<99%	排查数据同步问题

2. 定期维护

• 月度：执行一次故障切换演练，验证容灾有效性；
• 季度：升级MongoDB小版本（避免安全漏洞）；
• 年度：检查服务器硬件状态（磁盘、内存、网络）。

3. 常见问题排查

• 备节点同步失败：检查 rs.status() 中 errmsg，常见原因是磁盘满、网络不通、权限不足；
• 仲裁节点离线：立即恢复，否则会导致脑裂风险；
• 副本集选举失败：确认节点数为奇数，且所有节点网络互通。

八、总结

本方案是中小型业务MongoDB容灾的最优解，核心优势在于：

1. 架构极简：仅3个有效节点+1个仲裁，运维成本低；
2. 成本可控：服务器配置要求低，无需超高性能硬件；
3. 容灾可靠：多数派选举+仲裁隔离，避免脑裂，数据零丢失；
4. 业务无感：故障切换时间10-30s，业务端仅需配置副本集连接串。

部署完成后，可直接承载中小型业务的核心数据，同时满足机房级容灾需求。若后续业务规模扩大，可直接升级为方案2（五节点副本集）或方案3（分片集群），无需重构架构。