MongDB高可用可扩展架构验证方案（附实战命令）

1. 验证目标

• 验证MongoDB的高可用部署。
• 高可用部署条件下，MongoDB和MySQL的性能对比。
• MongoDB可扩展架构的性能损耗。
• 测试在可扩展架构下增加数据分区的影响。

2. 环境定义

2.1. MongoDB高可用环境

 

    如图，MongoDB的最小高可用环境由三个节点构成一个复制集(Replica Set)，三个节点可以是主、副节点和Arbiter节点。其中仅有主节点可写可读，副节点（配置后）可读。为了应对节点分区的问题，MongoDB规定复制集中的节点数大于50%（也称作Majority）时，才可以选举出可写的主节点，这样，两节点的复制集在一个节点故障时，就变为只读状态了。因此，可以在复制集中增加一个观察作用的Arbiter节点，帮助最小高可用环境选举出主节点，Arbiter节点不存储数据。

2.1.1. 启动mongo服务器节点

    启动mongo服务器器时增加--replSet参数，指定复制集。例如：

mongod --replSet myapp --dbpath ~/node1 --fork
mongod --replSet myapp --dbpath ~/node2 --fork
mongod --replSet myapp --dbpath ~/arbiter –fork

    如果是在一台服务器上模拟，需要指定--port以避免端口冲突。

2.1.2. 配置复制集

    使用mongo命令连接到规划的主节点，初始化复制集

> rs.initiate()

等待约1分钟，单节点复制集创建好以后，就可以添加节点了

> rs.add(“<hostname1>:<port1>”)
> rs.add(“<hostname2>:<port2>”, {arbiterOnly: true})

Mongo 2.0添加Arbiter的命令为

> rs.addArb(“<hostname2>:<port2>”)

2.1.3. 查看复制集状态

> rs.status()

2.1.4. 使用MongoDB Driver连接到复制集

    MongoDB Driver可以自动判断复制集中的主副节点。可以通过制定至少两个节点连接到复制集，例如：

MongoClient mongoClient = new MongoClient(
new MongoClientURI("mongodb://host1:27017,host2:27017,host3:27017"));

2.2. MongoDB可扩展环境

    MongoDB可扩展环境即分区集群环境中包括三个组件：一是存储数据的分区(Shard)，在生产环境建议每个分区都是一个复制集；二是mongos路由器(router)，供应用连接集群环境，将应用的请求路由到数据分区；三是配置服务器，存储了集群的元数据，包括分区存储了哪些数据子集的信息。

2.2.1. 创建数据复制集

    使用2.1.1和2.1.2中的方法创建两个复制集，在启动MongoDB服务器时增加参数--shardsvr参数，表明MongoDB是分区进程。

2.2.2. 创建配置服务器

    启动3个Monog服务器作为配置服务器，例如：

$ mongod --configsvr --dbpath /data/config-1 --logpath /data/config-1.log --fork --nojournal
$ mongod --configsvr --dbpath /data/config-2 --logpath /data/config-2.log --fork --nojournal
$ mongod --configsvr --dbpath /data/config-3 --logpath /data/config-2.log --fork –nojournal

    如果是在一台服务器上模拟启动，需要指定--port以避免端口冲突。

2.2.3. 启动mongos路由器服务

    在mongos路由器服务器上，执行mongos命令，启动服务，例如

$ mongos --configdb localhost:27019,localhost:27020,localhost:27021 --logpath /data/mongos.log –fork

2.2.4. 配置分区集群

    使用mongo命令连接到mongos路由服务器，向分区集群添加复制集作为分区，例如：

> sh.addShard("shard-a/localhost:30000,localhost:30001")
> sh.addShard("shard-b/localhost:30100,localhost:30101")

    命令中的shard-a替换为在2.2.1中创建的复制集名称，地址替换为的主副节点地址。
    可以使用以下命令查询分区集群中的集群：

> db.getSiblingDB("config").shards.find()

2.2.5. 配置集合(Collections)分区

    执行命令，允许对数据库上的集合分区，例如数据库命为cloud-docs：

> sh.enableSharding("cloud-docs")

    可以使用以下命令查询数据库是否已经允许分区：

> db.getSiblingDB("config").databases.find()
……
{ "_id" : "cloud-docs", "partitioned" : true, "primary" : "shard-a" }

    现在可以执行命令配置MongoDB集合分区了，例如集合名为spreadsheets，使用username和_id作为数据的联合分区键时：

> sh.shardCollection("cloud-docs.spreadsheets", {username: 1, _id: 1})

    可以使用以下的命令检查集合的分区配置情况：

> db.getSiblingDB("config").collections.findOne()

    在集合分区中插入数据以后，可以使用以下命令查看数据的分布情况：

> sh.status()

2.2.6. 通过MongoDB Driver连接到分区集群环境

    可通过在连接字符串中指定一个或多个mongos路由服务器的地址，连接到分区集群环境，例如：

MongoClient mongoClient = new MongoClient(
   new MongoClientURI("mongodb://host1:27017,host2:27017"));

2.3. 技术验证测试环境设计

    考虑到MongoDB高可用和可扩展的最小环境要求，以及功能测试和性能测试的需要，拟按照以下的方案部署技术验证测试环境： 

    服务器配置需求如下表所示：

服务器类型	硬件配置
性能测试客户机	4C/8G/50G
应用服务器	4C/8G/50G
Mongo路由器服务器	2C/4G/50G
Mongo数据分片服务器	2C/32G/500G

3. 测试案例

    关于测试的基础测试数据：按平均10万订单/天，存储5年的数据预估。系统需存储2亿条数据，作为基础测试数据。按每条数据1KB预估，需200GB的存储空间。

3.1. 案例一：验证MongoDB的高可用部署

 
    使用如图环境，测试用例读写比为10:1。测试：

1. 调节压力，保持MongoDB主节点CPU使用率为50%
2. kill主节点mongod进程，记录吞吐率，响应时间和错误率变化的情况
3. 重启原主节点mongod进程，记录吞吐率，响应时间和错误率变化的情况

3.2. 案例二：不同结构复制集性能对比

    MongDB复制集可以由一主两副，或者一主一副一观察者构成，使用如图的环境，和3.1的测试结果做比较。

 

3.3. 案例三：MongoDB、MySQL行存储和MySQL列存储的性能对比

    MongoDB测试使用3.1中的环境，MySQL同样使用高可用部署，测试用例读写比为10:1，测试前预加载1000w条数据。分别在主节点CPU使用率为50%条件下，测试1个小时的吞吐率和响应时间等性能数据做比较。 

3.4. 案例四：MongoDB可扩展架构的性能损耗

    使用如下图的环境做测试，测试结果和3.1的测试结果做比较。
 

3.5. 案例五：在可扩展架构下增加数据分区的影响

    使用2.3中定义的环境，测试用例读写比为10:1。测试：

1. 分区集群中只有复制集shard-a和shard-b调节压力，保持MongoDB主节点CPU使用率为50%
2. 将复制集加入分区集群shard-c，记录吞吐率，响应时间和错误率变化的情况