2. 首页 > MongoDB教程 > 正文

MongoDB教程FG060-MongoDB异地多活架构实战

教程整理：风哥教程  |  更新时间：2026-01-30  |  教程分类：MongoDB教程  |  文档学习：32

本文主要介绍MongoDB数据库的异地多活架构设计和实施，包括跨数据中心部署、数据同步和故障切换等核心功能。风哥教程参考MongoDB官方文档Replication和High Availability相关章节。

目录大纲

Part01-基础概念与理论知识

Part02-生产环境规划与建议

Part03-生产环境项目实施方案

Part04-生产案例与实战讲解

Part05-风哥经验总结与分享

Part01-基础概念与理论知识

1.1 异地多活架构概述

异地多活架构是指在多个地理区域部署应用和数据库，使每个区域都能独立提供服务，同时保持数据同步。这种架构可以提高系统的可用性和容灾能力，当一个区域发生故障时，其他区域可以继续提供服务。

对于MongoDB来说，异地多活架构通常通过跨数据中心的副本集或分片集群实现。学习交流加群风哥微信: itpux-com

1.2 MongoDB异地多活方案

MongoDB支持的异地多活方案包括：

  • 跨数据中心副本集：在不同数据中心部署副本集节点
  • 分片集群跨数据中心：将分片分布在不同数据中心
  • 多活复制：使用MongoDB Atlas Global Clusters或自定义复制方案

不同的异地多活方案适用于不同的业务场景，需要根据业务需求和数据规模进行选择。更多视频教程www.fgedu.net.cn

Part02-生产环境规划与建议

2.1 异地多活架构规划

异地多活架构规划需要考虑以下因素：

  • 数据中心选择：地理位置、网络延迟、可用性
  • 数据同步策略：同步复制 vs 异步复制
  • 故障切换机制：自动 vs 手动
  • 应用层路由：智能DNS、负载均衡

风哥提示：异地多活架构设计应考虑网络延迟对性能的影响，以及数据一致性的保障。

2.2 网络与带宽规划

网络与带宽规划包括：

  • 跨数据中心网络：专线、VPN、CDN
  • 带宽需求：数据同步、应用访问
  • 网络延迟：影响读写性能和复制延迟
  • 网络安全：加密传输、访问控制

更多学习教程公众号风哥教程itpux_com

Part03-生产环境项目实施方案

3.1 跨数据中心副本集部署

部署跨数据中心副本集：

# 配置文件准备（北京数据中心节点）

vi /mongodb/app/mongod-beijing.conf

systemLog:
destination: file
path: /mongodb/logs/mongod-beijing.log
logAppend: true
storage:
dbPath: /mongodb/fgdata-beijing
journal:
enabled: true
processManagement:
fork: true
pidFilePath: /mongodb/run/mongod-beijing.pid
net:
port: 27017
bindIp: 10.0.0.10
replication:
replSetName: fgedu-multi-region

# 配置文件准备（上海数据中心节点）

vi /mongodb/app/mongod-shanghai.conf

systemLog:
destination: file
path: /mongodb/logs/mongod-shanghai.log
logAppend: true
storage:
dbPath: /mongodb/fgdata-shanghai
journal:
enabled: true
processManagement:
fork: true
pidFilePath: /mongodb/run/mongod-shanghai.pid
net:
port: 27017
bindIp: 10.0.1.10
replication:
replSetName: fgedu-multi-region

# 配置文件准备（广州数据中心节点）

vi /mongodb/app/mongod-guangzhou.conf

systemLog:
destination: file
path: /mongodb/logs/mongod-guangzhou.log
logAppend: true
storage:
dbPath: /mongodb/fgdata-guangzhou
journal:
enabled: true
processManagement:
fork: true
pidFilePath: /mongodb/run/mongod-guangzhou.pid
net:
port: 27017
bindIp: 10.0.2.10
replication:
replSetName: fgedu-multi-region

启动MongoDB实例：

# 启动北京节点
/mongodb/app/bin/mongod –config /mongodb/app/mongod-beijing.conf

# 启动上海节点
/mongodb/app/bin/mongod –config /mongodb/app/mongod-shanghai.conf

# 启动广州节点
/mongodb/app/bin/mongod –config /mongodb/app/mongod-guangzhou.conf

初始化跨数据中心副本集：

# 连接到北京节点
/mongodb/app/bin/mongosh –host 10.0.0.10 –port 27017

# 初始化副本集
rs.initiate({
_id: “fgedu-multi-region”,
members: [
{ _id: 0, host: “10.0.0.10:27017”, priority: 2 }, // 北京主节点
{ _id: 1, host: “10.0.1.10:27017”, priority: 1 }, // 上海从节点
{ _id: 2, host: “10.0.2.10:27017”, priority: 1 } // 广州从节点
]
})

3.2 数据同步配置

配置复制参数：

# 连接到副本集
/mongodb/app/bin/mongosh –host 10.0.0.10 –port 27017

# 查看当前复制配置
rs.conf()

# 修改复制配置（调整心跳间隔和选举超时）
cfg = rs.conf()
cfg.settings.heartbeatIntervalMillis = 10000 // 10秒
cfg.settings.electionTimeoutMillis = 60000 // 60秒
rs.reconfig(cfg)

配置写入关注：

# 连接到副本集
/mongodb/app/bin/mongosh –host 10.0.0.10 –port 27017

# 设置默认写入关注（等待所有节点确认）
db.adminCommand({ setDefaultRWConcern: 1, defaultWriteConcern: { w: “majority” } })

Part04-生产案例与实战讲解

4.1 异地多活架构实战

查看副本集状态：

# 连接到副本集
/mongodb/app/bin/mongosh –host 10.0.0.10 –port 27017

# 查看副本集状态
rs.status()

# 输出日志
{
“set”: “fgedu-multi-region”,
“date”: ISODate(“2026-04-08T10:00:00Z”),
“myState”: 1,
“term”: NumberLong(1),
“syncingTo”: “”,
“syncSourceHost”: “”,
“syncSourceId”: -1,
“heartbeatIntervalMillis”: NumberLong(10000),
“majorityVoteCount”: 2,
“writeMajorityCount”: 2,
“optimes”: {
“lastCommittedOpTime”: {
“ts”: Timestamp(1712544000, 1),
“t”: NumberLong(1)
},
“lastCommittedWallTime”: ISODate(“2026-04-08T10:00:00Z”),
“readConcernMajorityOpTime”: {
“ts”: Timestamp(1712544000, 1),
“t”: NumberLong(1)
},
“readConcernMajorityWallTime”: ISODate(“2026-04-08T10:00:00Z”),
“appliedOpTime”: {
“ts”: Timestamp(1712544000, 1),
“t”: NumberLong(1)
},
“durableOpTime”: {
“ts”: Timestamp(1712544000, 1),
“t”: NumberLong(1)
},
“lastAppliedWallTime”: ISODate(“2026-04-08T10:00:00Z”),
“lastDurableWallTime”: ISODate(“2026-04-08T10:00:00Z”)
},
“lastStableRecoveryTimestamp”: Timestamp(1712544000, 1),
“electionCandidateMetrics”: {
“lastElectionReason”: “electionTimeout”,
“lastElectionDate”: ISODate(“2026-04-08T09:50:00Z”),
“electionTerm”: NumberLong(1),
“lastCommittedOpTimeAtElection”: {
“ts”: Timestamp(0, 0),
“t”: NumberLong(-1)
},
“lastSeenOpTimeAtElection”: {
“ts”: Timestamp(1712543400, 1),
“t”: NumberLong(-1)
},
“numVotesNeeded”: 2,
“priorityAtElection”: 2,
“electionTimeoutMillis”: NumberLong(60000),
“newTermStartDate”: ISODate(“2026-04-08T09:50:00Z”),
“wMajorityWriteAvailabilityDate”: ISODate(“2026-04-08T09:50:00Z”)
},
“members”: [
{
“_id”: 0,
“name”: “10.0.0.10:27017”,
“health”: 1,
“state”: 1,
“stateStr”: “PRIMARY”,
“uptime”: 3600,
“optime”: {
“ts”: Timestamp(1712544000, 1),
“t”: NumberLong(1)
},
“optimeDate”: ISODate(“2026-04-08T10:00:00Z”),
“syncingTo”: “”,
“syncSourceHost”: “”,
“syncSourceId”: -1,
“infoMessage”: “”,
“electionTime”: Timestamp(1712543400, 1),
“electionDate”: ISODate(“2026-04-08T09:50:00Z”),
“configVersion”: 2,
“configTerm”: 1,
“self”: true,
“lastHeartbeatMessage”: “”
},
{
“_id”: 1,
“name”: “10.0.1.10:27017”,
“health”: 1,
“state”: 2,
“stateStr”: “SECONDARY”,
“uptime”: 3540,
“optime”: {
“ts”: Timestamp(1712544000, 1),
“t”: NumberLong(1)
},
“optimeDurable”: {
“ts”: Timestamp(1712544000, 1),
“t”: NumberLong(1)
},
“optimeDate”: ISODate(“2026-04-08T10:00:00Z”),
“optimeDurableDate”: ISODate(“2026-04-08T10:00:00Z”),
“lastHeartbeat”: ISODate(“2026-04-08T10:00:00Z”),
“lastHeartbeatRecv”: ISODate(“2026-04-08T10:00:00Z”),
“pingMs”: NumberLong(30),
“lastHeartbeatMessage”: “”,
“syncingTo”: “10.0.0.10:27017”,
“syncSourceHost”: “10.0.0.10:27017”,
“syncSourceId”: 0,
“infoMessage”: “”,
“configVersion”: 2,
“configTerm”: 1
},
{
“_id”: 2,
“name”: “10.0.2.10:27017”,
“health”: 1,
“state”: 2,
“stateStr”: “SECONDARY”,
“uptime”: 3540,
“optime”: {
“ts”: Timestamp(1712544000, 1),
“t”: NumberLong(1)
},
“optimeDurable”: {
“ts”: Timestamp(1712544000, 1),
“t”: NumberLong(1)
},
“optimeDate”: ISODate(“2026-04-08T10:00:00Z”),
“optimeDurableDate”: ISODate(“2026-04-08T10:00:00Z”),
“lastHeartbeat”: ISODate(“2026-04-08T10:00:00Z”),
“lastHeartbeatRecv”: ISODate(“2026-04-08T10:00:00Z”),
“pingMs”: NumberLong(50),
“lastHeartbeatMessage”: “”,
“syncingTo”: “10.0.0.10:27017”,
“syncSourceHost”: “10.0.0.10:27017”,
“syncSourceId”: 0,
“infoMessage”: “”,
“configVersion”: 2,
“configTerm”: 1
}
],
“ok”: 1,
“$clusterTime”: {
“clusterTime”: Timestamp(1712544000, 1),
“signature”: {
“hash”: BinData(0, “AAAAAAAAAAAAAAAAAAAAAAAAAAA=”),
“keyId”: 0
}
},
“operationTime”: Timestamp(1712544000, 1)
}

测试数据同步：

# 在主节点插入数据
db.fgedu_users.insertOne({ “name”: “Test User”, “age”: 30, “email”: “test@fgedu.net.cn” })

# 连接到上海节点
/mongodb/app/bin/mongosh –host 10.0.1.10 –port 27017

# 查看数据是否同步
db.fgedu_users.find({ “name”: “Test User” })

# 输出日志
[
{ _id: ObjectId(“60a7b8c9d0e1f2a3b4c5d6e7”), name: “Test User”, age: 30, email: “test@fgedu.net.cn” }
]

from MongoDB视频:www.itpux.com

4.2 故障切换实战

模拟北京数据中心故障：

# 停止北京节点
systemctl stop mongod-beijing

# 连接到上海节点
/mongodb/app/bin/mongosh –host 10.0.1.10 –port 27017

# 查看副本集状态（等待选举完成）
rs.status()

# 输出日志（上海节点成为新的主节点）
{
“set”: “fgedu-multi-region”,
“date”: ISODate(“2026-04-08T10:10:00Z”),
“myState”: 1,
“term”: NumberLong(2),
“syncingTo”: “”,
“syncSourceHost”: “”,
“syncSourceId”: -1,
“heartbeatIntervalMillis”: NumberLong(10000),
“majorityVoteCount”: 2,
“writeMajorityCount”: 2,
“optimes”: {
“lastCommittedOpTime”: {
“ts”: Timestamp(1712544600, 1),
“t”: NumberLong(2)
},
“lastCommittedWallTime”: ISODate(“2026-04-08T10:10:00Z”),
“readConcernMajorityOpTime”: {
“ts”: Timestamp(1712544600, 1),
“t”: NumberLong(2)
},
“readConcernMajorityWallTime”: ISODate(“2026-04-08T10:10:00Z”),
“appliedOpTime”: {
“ts”: Timestamp(1712544600, 1),
“t”: NumberLong(2)
},
“durableOpTime”: {
“ts”: Timestamp(1712544600, 1),
“t”: NumberLong(2)
},
“lastAppliedWallTime”: ISODate(“2026-04-08T10:10:00Z”),
“lastDurableWallTime”: ISODate(“2026-04-08T10:10:00Z”)
},
“lastStableRecoveryTimestamp”: Timestamp(1712544600, 1),
“electionCandidateMetrics”: {
“lastElectionReason”: “stepUpRequestSkipDryRun”,
“lastElectionDate”: ISODate(“2026-04-08T10:10:00Z”),
“electionTerm”: NumberLong(2),
“lastCommittedOpTimeAtElection”: {
“ts”: Timestamp(1712544000, 1),
“t”: NumberLong(1)
},
“lastSeenOpTimeAtElection”: {
“ts”: Timestamp(1712544000, 1),
“t”: NumberLong(1)
},
“numVotesNeeded”: 2,
“priorityAtElection”: 1,
“electionTimeoutMillis”: NumberLong(60000),
“newTermStartDate”: ISODate(“2026-04-08T10:10:00Z”),
“wMajorityWriteAvailabilityDate”: ISODate(“2026-04-08T10:10:00Z”)
},
“members”: [
{
“_id”: 0,
“name”: “10.0.0.10:27017”,
“health”: 0,
“state”: 8,
“stateStr”: “(not reachable/healthy)”,
“uptime”: 0,
“optime”: {
“ts”: Timestamp(0, 0),
“t”: NumberLong(-1)
},
“optimeDurable”: {
“ts”: Timestamp(0, 0),
“t”: NumberLong(-1)
},
“optimeDate”: ISODate(“1970-01-01T00:00:00Z”),
“optimeDurableDate”: ISODate(“1970-01-01T00:00:00Z”),
“lastHeartbeat”: ISODate(“2026-04-08T10:10:00Z”),
“lastHeartbeatRecv”: ISODate(“2026-04-08T10:00:00Z”),
“pingMs”: NumberLong(0),
“lastHeartbeatMessage”: “Connection refused”,
“syncingTo”: “”,
“syncSourceHost”: “”,
“syncSourceId”: -1,
“infoMessage”: “”,
“configVersion”: -1,
“configTerm”: -1
},
{
“_id”: 1,
“name”: “10.0.1.10:27017”,
“health”: 1,
“state”: 1,
“stateStr”: “PRIMARY”,
“uptime”: 3900,
“optime”: {
“ts”: Timestamp(1712544600, 1),
“t”: NumberLong(2)
},
“optimeDurable”: {
“ts”: Timestamp(1712544600, 1),
“t”: NumberLong(2)
},
“optimeDate”: ISODate(“2026-04-08T10:10:00Z”),
“optimeDurableDate”: ISODate(“2026-04-08T10:10:00Z”),
“lastHeartbeat”: ISODate(“2026-04-08T10:10:00Z”),
“lastHeartbeatRecv”: ISODate(“2026-04-08T10:10:00Z”),
“pingMs”: NumberLong(0),
“lastHeartbeatMessage”: “”,
“syncingTo”: “”,
“syncSourceHost”: “”,
“syncSourceId”: -1,
“infoMessage”: “”,
“electionTime”: Timestamp(1712544600, 1),
“electionDate”: ISODate(“2026-04-08T10:10:00Z”),
“configVersion”: 2,
“configTerm”: 2,
“self”: true,
“lastHeartbeatMessage”: “”
},
{
“_id”: 2,
“name”: “10.0.2.10:27017”,
“health”: 1,
“state”: 2,
“stateStr”: “SECONDARY”,
“uptime”: 3900,
“optime”: {
“ts”: Timestamp(1712544600, 1),
“t”: NumberLong(2)
},
“optimeDurable”: {
“ts”: Timestamp(1712544600, 1),
“t”: NumberLong(2)
},
“optimeDate”: ISODate(“2026-04-08T10:10:00Z”),
“optimeDurableDate”: ISODate(“2026-04-08T10:10:00Z”),
“lastHeartbeat”: ISODate(“2026-04-08T10:10:00Z”),
“lastHeartbeatRecv”: ISODate(“2026-04-08T10:10:00Z”),
“pingMs”: NumberLong(45),
“lastHeartbeatMessage”: “”,
“syncingTo”: “10.0.1.10:27017”,
“syncSourceHost”: “10.0.1.10:27017”,
“syncSourceId”: 1,
“infoMessage”: “”,
“configVersion”: 2,
“configTerm”: 2
}
],
“ok”: 1,
“$clusterTime”: {
“clusterTime”: Timestamp(1712544600, 1),
“signature”: {
“hash”: BinData(0, “AAAAAAAAAAAAAAAAAAAAAAAAAAA=”),
“keyId”: 0
}
},
“operationTime”: Timestamp(1712544600, 1)
}

故障恢复后重新加入：

# 启动北京节点
systemctl start mongod-beijing

# 查看副本集状态（北京节点重新加入）
rs.status()

风哥提示：异地多活架构的故障切换需要考虑网络延迟和数据一致性，建议在测试环境中进行充分的故障演练。

Part05-风哥经验总结与分享

5.1 异地多活最佳实践

风哥建议的异地多活最佳实践：

  • 选择地理位置合适的数据中心，平衡距离和网络延迟
  • 使用专线或高质量的网络连接，确保跨数据中心通信的可靠性
  • 合理配置副本集优先级，控制主节点的位置
  • 调整心跳间隔和选举超时时间，适应跨数据中心的网络延迟
  • 实现智能路由，根据用户位置和健康状态选择最佳数据中心

学习交流加群风哥QQ113257174

5.2 性能优化建议

异地多活架构的性能优化建议：

  • 使用就近访问策略，减少跨数据中心的网络延迟
  • 合理设置写入关注级别，平衡数据一致性和性能
  • 监控复制延迟，及时发现和解决同步问题
  • 使用缓存减少对数据库的直接访问
  • 考虑使用MongoDB Atlas Global Clusters等托管服务

更多视频教程www.fgedu.net.cn

注意事项

  • 异地多活架构会增加部署和维护的复杂性
  • 跨数据中心的网络延迟会影响复制性能
  • 需要考虑数据一致性和冲突解决策略
  • 定期进行故障演练，确保系统能够正确处理故障
  • 监控系统的健康状态，及时发现和解决问题

本文由风哥教程整理发布,仅用于学习测试使用,转载注明出处:http://www.fgedu.net.cn/10327.html

相关推荐

联系我们

在线咨询：点击这里给我发消息

微信号：itpux-com

工作日：9:30-18:30，节假日休息