MongoDB 双活集群在运营商的实践

数据双向同步的挑战

在原有设计下，该订单中心的客户数据存在于两个 MongoDB 集群之间，需要实现数据的双向同步。然而，这种双向同步设计面临以下挑战：

1. 数据循环同步问题：数据的双向同步无法避免数据循环同步的问题，这会导致一条数据变更被无限次放大，最终导致数据的持续不稳定，并耗尽系统资源。

2. 数据一致性问题：在双向同步过程中，由于更新延迟等原因，可能会导致两个数据中心的数据不一致，进而影响业务的正常运作。

3. 系统性能问题：在高并发的业务场景下，数据的双向同步可能会增加系统的负载，影响系统的整体性能。

为此，订单中心的双活架构需要具备以下技术特性：

1. 高可用性：保证两个数据中心在任何一个出现故障时，另一个数据中心能够无缝接管，确保业务不中断。

2. 实时数据同步：实现数据在两个数据中心之间的实时同步，确保数据的一致性和及时性。

3. 循环同步避免机制：在双向同步过程中，必须设计有效的机制来避免数据循环同步的问题，确保数据同步的稳定性和可靠性。

4. 性能优化：在高并发场景下，保证系统性能的稳定，避免由于同步任务导致的系统资源耗尽。

• 应用按区域

  • A、B 两中心分别对外提供写入入口

  • 应用按区域向不同入口请求写入

• MongoDB 提供数据库高可用

  • MongoDB 分片集群每个分片节点采用副本集架构，作为数据库高可用解决方案

  • 同时在两中心各部署一套相同架构的 MongoDB 集群，确保每个中心数据库保持持续提供服务状态

• Tapdata 提供数据同步

  • 确保两数据中心，数据库数据一致性

  • Tapdata 部署在 A 中心

  • 保证 A 中心 <-> Tapdata <-> B 中心数据库访问通畅

双活部署架构

架构说明

• MongoDB（蓝色）：订单中心MongoDB数据库双活集群

• Tapdata Management：负责软件各模块调度和网页控制台展现。

• Tapdata Flow Engine：负责数据同步、清洗、多表关联、聚合计算等。

• MongoDB（绿色）：Tapdata 数据库，中间缓存结果。

工作模式

场景说明：

当 DC A 不可用时，Tapdata 集群也不可用

需要人工干预恢复：

1. 所有业务切到 DC B 写入

2. 恢复 DC A 服务器

3. 恢复 DC A MongoDB Cluster

4. 恢复 DC A tapdata

5. 重新启动 DC A tapdata 任务

风险：

• 当 DC A 发生不可用时，部分传输数据未写入 DC B Mongo

• 这部分数据会在 DB B 丢失，但在 DC A 中

所需资源

北京中心

TapData 实施方案

在构建该订单中心双活架构的过程中，TapData 作为核心的数据同步和管理工具，承担了跨数据中心的数据一致性维护任务。为了确保系统的高可用性与数据的一致性，以下将详细介绍该项目中的具体实施方案，包括各个关键步骤的具体操作与技术要点。

1. 数据源配置

• 配置充足的 Oplog 存储空间，至少需要容纳 24 * 7 小时的 Oplog。 具体操作，见修改 Oplog 大小。

• 根据权限管控需求选择下述步骤，创建用于数据同步/开发任务的账号并授予权限。

• 由于分片服务器不会向 config 数据库获取用户权限，因此，当源库为分片集群架构时，您需要在每个分片的主节点上创建相应的用户并授予权限。

  • 授予指定库的读权限

1 use admin
2 db.createUser({
3    "user" : "tapdata",
4    "pwd"   : "my_password",
5    "roles" : [
6        {
7            "role" : "clusterMonitor",
8            "db" : "admin"
9        },
10        {
11            "role" : "read",
12            "db" : "order"
13        }，
14        {
15            "role" : "read",
16            "db" : "local"
17        },
18        {
19            "role" : "read",
20            "db" : "config"
21        }
22    ]
23 }

1 use admin
2 db.createUser({
3    "user" : "tapdata",
4    "pwd"   : "my_password",
5    "roles" : [
6        {
7            "role" : "clusterMonitor",
8            "db" : "admin"
9        },
10        {
11            "role" : "readAnyDatabase",
12            "db" : "admin"
13        }
14    ]
15 }

1 use admin
2 > db.createUser({
3   "user" : "tapdata",
4   "pwd"   : "my_password",
5   "roles" : [
6      {
7          "role" : "clusterMonitor",
8          "db" : "admin"
9      },
10      {
11          "role" : "readWrite",
12          "db" : "order"
13      },
14      {
15          "role" : "read",
16          "db" : "local"
17      }
18   ]
19 }

2. 初始化同步

1   /home/mongodb/app/mongodb-linux-x86_64-3.4.24/bin/mongo --host 10.173.2.115:20000   
2 use order
3 db.dropDatabase()

2. [陕西]创建集合及其相应的片键索引

1   use order
2   // 表order.oc_order创建索引
3   db.oc_order.createIndex({ "ORDER_ID" : "hashed"})
4   // 表order.oc_order_dispatch创建索引
5   db.oc_order_dispatch.createIndex({ "ORDER_ID" : "hashed"})
6   // 表order.oc_order_low_efficientcy创建索引
7   db.oc_order_low_efficientcy.createIndex({ "ORDER_ID" : "hashed"})
8   // 表order.oc_order_pic创建索引
9   db.oc_order_pic.createIndex({ "PIC_KEY" : "hashed"})
10 // 表order.oc_order_activate创建索引
11 db.oc_order_activate.createIndex({ "ORDER_ID" : "hashed"})

1   use order
2   // 实现数据库order分片功能
3   mongos> sh.enableSharding("order")
4   // 以"ORDER_ID"作为分片键对集合oc_order进行分片
5   mongos> sh.shardCollection("order.oc_order",{"ORDER_ID":"hashed"})
6   // 以"ORDER_ID"作为分片键对集合oc_order_low_efficientcy进行分片
7   mongos> sh.shardCollection("order.oc_order_low_efficientcy",{"ORDER_ID":"hashed"})
8   // 以"PIC_KEY"作为分片键对集合oc_order_pic进行分片
9   mongos> sh.shardCollection("order.oc_order_pic",{"PIC_KEY":"hashed"})
10 // 以"ORDER_ID"作为分片键对集合oc_order_activate进行分片
11 mongos> sh.shardCollection("order.oc_order_activate",{"ORDER_ID":"hashed"})
12 // 以"ORDER_ID"作为分片键对集合oc_order_dispatch进行分片
13 mongos> sh.shardCollection("order.oc_order_dispatch",{"ORDER_ID":"hashed"})

4. [北京][陕西]关闭均衡器

1 /home/mongodb/app/mongodb-linux-x86_64-enterprise-rhel70-3.4.24/bin/mongo --host 10.191.241.218:20000
2
3 sh.stopBalancer()
4 sh.isBalancerRunning()
5 sh.getBalancerState()

1 /home/mongodb/app/mongodb-linux-x86_64-3.4.24/bin/mongo --host 10.173.2.115:20000
2
3 sh.stopBalancer()
4 sh.isBalancerRunning()
5 sh.getBalancerState()

5. [陕西]检查集群状态

1 sh.status()

1 use order
2 db.dropDatabase(

1 nohup /home/mongodb/app/mongodb-linux-x86_64-3.4.24/bin/mongodump --host 10.191.241.128:20000 -u monit -p 'Monit#3' --db order -c oc_order --authenticationDatabase admin -q '{"CREATE_DATE": {"$lt":"2021-09-01"}}' --readPreference='{mode: "secondary", tagSets: [ { "type": "ssd" } ]}' -o /data/oc_order/ > dumpbf0901.log &

1 nohup /home/mongodb/app/mongodb-linux-x86_64-3.4.24/bin/mongodump --host 10.191.241.128:20000 -u monit -p 'Monit#3' --db order -c oc_order --authenticationDatabase admin -q '{"CREATE_DATE": {"$gte":"2021-09-01"},"CREATE_DATE": {"$lt":"2022-02-01"}}' --readPreference='{mode: "secondary", tagSets: [ { "type": "ssd" } ]}' -o /data/oc_order/ > dumpbf220201.log &

1 nohup /home/mongodb/app/mongodb-linux-x86_64-3.4.24/bin/mongodump --host 10.191.241.128:20000 -u monit -p 'Monit#3' --db order -c oc_order --authenticationDatabase admin -q '{"CREATE_DATE": {"$gte":"2022-02-01"},"CREATE_DATE": {"$lt":"2022-08-01"}}' --readPreference='{mode: "secondary", tagSets: [ { "type": "ssd" } ]}' -o /data/oc_order/ > dumpbf20220801.log &

1 nohup /home/mongodb/app/mongodb-linux-x86_64-3.4.24/bin/mongodump --host 10.191.241.128:20000 -u monit -p 'Monit#3' --db order -c oc_order --authenticationDatabase admin -q '{"CREATE_DATE": {"$gte":"2022-08-01"},"CREATE_DATE": {"$lt":"2023-02-01"}}' --readPreference='{mode: "secondary", tagSets: [ { "type": "ssd" } ]}' -o /data/oc_order/ > dumpbf230201.log &

1 nohup /home/mongodb/app/mongodb-linux-x86_64-3.4.24/bin/mongodump --host 10.191.241.128:20000 -u monit -p 'Monit#3' --db order -c oc_order --authenticationDatabase admin -q '{"CREATE_DATE": {"$gte":"2023-02-01"}}' --readPreference='{mode: "secondary", tagSets: [ { "type": "ssd" } ]}' -o /data/oc_order/ > dumpaf230201.log &

1 nohup /home/mongodb/app/mongodb-linux-x86_64-3.4.24/bin/mongorestore --host 10.173.2.115:20000 --numInsertionWorkersPerCollection=8 -u monit -p 'Monit#3' --db order -c oc_order --authenticationDatabase admin /data/oc_order/order/oc_order.bson > restorebf210901.log 2>&1 &

1 nohup /home/mongodb/app/mongodb-linux-x86_64-3.4.24/bin/mongorestore --host 10.173.2.115:20000 --numInsertionWorkersPerCollection=8 -u monit -p 'Monit#3' --db order -c oc_order --authenticationDatabase admin /data/oc_order/order/oc_order.bson > restorebf220201.log 2>&1 &

1 nohup /home/mongodb/app/mongodb-linux-x86_64-3.4.24/bin/mongorestore --host 10.173.2.115:20000 --numInsertionWorkersPerCollection=8 -u monit -p 'Monit#3' --db order -c oc_order --authenticationDatabase admin /data/oc_order/order/oc_order.bson > restorebf220801.log 2>&1 &

1 nohup /home/mongodb/app/mongodb-linux-x86_64-3.4.24/bin/mongorestore --host 10.173.2.115:20000 --numInsertionWorkersPerCollection=8 -u monit -p 'Monit#3' --db order -c oc_order --authenticationDatabase admin /data/oc_order/order/oc_order.bson > restorebf230201.log 2>&1 &

1 nohup /home/mongodb/app/mongodb-linux-x86_64-3.4.24/bin/mongorestore --host 10.173.2.115:20000 --numInsertionWorkersPerCollection=8 -u monit -p 'Monit#3' --db order -c oc_order --authenticationDatabase admin /data/oc_order/order/oc_order.bson > restoreaf230201.log 2>&1 &

1 sh.status()
2 db.printSlaveReplicationInfo(

1 use order
2 db.dropDatabase()

流量过大处理

1 #登录到服务器查看状态
2 cd /data/tapdata_v1.51.1 
3 ./tapdata status
4 #强制停止所有服务
5 ./tapdata stop -f
6 ./tapdata status

1 登录到tapdata服务器
2 ps -ef|grep tapdata
3 kill -9 $pid

基于此，该运营商成功实现了订单中心的高可用、高性能双活架构，确保业务的连续性和数据的一致性，为客户提供更加稳定和高效的服务。

双活场景演练

双活架构在确保系统高可用性和数据一致性方面扮演着关键角色，但在实际运行中，可能会遇到各种数据同步和写入的挑战。为了验证和优化双活架构的稳定性，必须进行多种场景演练。这些测试不仅有助于发现潜在的问题，还可以通过配置和功能调整来优化系统的响应和恢复能力。

下面将通过对多种典型场景的分析和演练，帮助团队识别潜在问题，并通过合理的配置和机制优化，确保系统在不同情况下都能保持业务的连续性和数据的一致性。

1. 业务成功写入数据库，TapData 未正确同步到目标

2. 正常双活运行情况下