Mongodb 分片操作实战

由于生产环境中一般使用zoomkeeper做config节点的仲裁节点，zoomkeeper会在三个config节点中挑选出一台作为主config节点。且mongos节点一般是两个节点，必须做高可用，可以用keepalived实现（任何具有负载均衡能力的服务器节点都可以使用keepalived做高可用）

• 实际操作过程

1：准备四个节点mongodb1(mongos)、mongodb2(config)、mongodb3(shard1)、mongodb4(shard2)且保证可以通过主机名访问，且时间同步

 

2：配置mongodb2(config)节点，使得mongodb2为config节点，编辑配置文件/etc/mongod.conf

添加：configsvr = true

同时注释：#replSet=uplooking #replIndexPrefetch=_id_only #port=27017 这3个指令

（因为副本集与config节点不能同时工作）

 

4：启动config server，此时默认config server监听在27019端口

systemctl start mongod.service

 

 

5: 在mongodb1上操纵：mongodb1作为路由，使用mongos连接config server，先清空配置文件，再添加如下信息

logpath=/var/log/mongodb/mongod.log # 指明日志路径

pidfilepath=/var/run/mongodb/mongod.pid # 指明pid路径

logappend=true # 指明日志累加

fork=true # 指明运行于守护进程

port=27017 # 指明端口

configdb=192.168.43.11:27019 # 指明config server 的地址在哪里

 

6：指定配置文件，启动mongos，也可以使用systemctl启动，但是需要修改下启动脚本/etc/rc.d/init.d/mongod

mongos -f /etc/mongod.conf

 

7：将mongodb3和mongodb4配置文件中关于副本集的指令注释，然后直接启动

systemctl start mongod

 

8：mongodb3、mongodb4启动之后，在mongodb1上，通过mongo登入到mongos，将mongodb3、mongodb4作为shard添加到mongos的路由策略中

 

9：创建支持shard机制的数据库

sh.enableSharding("uplookingdb")

mongos> sh.status();

--- Sharding Status ---

sharding version: {

"_id" : 1,

"version" : 4,

"minCompatibleVersion" : 4,

"currentVersion" : 5,

"clusterId" : ObjectId("59f6caf5c93e5ff2a637a0cd")

}

shards:

{ "_id" : "shard0000", "host" : "192.168.43.13:27017" }

{ "_id" : "shard0001", "host" : "192.168.43.12:27017" }

databases: # 这里会显示支持shard的数据库，分片collection放置在各个shard，而没有分片的collection放置在主shard中

{ "_id" : "admin", "partitioned" : false, "primary" : "config" }

{ "_id" : "test", "partitioned" : false, "primary" : "shard0001" }

{ "_id" : "uplookingdb", "partitioned" : true, "primary" : "shard0001" }

 

10：在对应支持shard机制的数据库上创建支持shard的collection，{"age": 1}指明索引为age，升序排序，这样shard集群的功能就已经启动了，之后就可以调用mongodb1这个接口写数据了，但是写入mongodb1的数据不会保存在mongodb1，因为mongodb1是一个router节点，所有的数据都会保存至shard节点上。

sh.shardCollection("uplookingdb.students", {"age": 1})

 

11：此时mongodb1节点上会有uplookingdb库 和 students表了

mongos> show dbs;

admin (empty)

config 0.016GB

uplookingdb 0.078GB

mongos> use uplookingdb

switched to db uplookingdb

mongos> show collections;

students

system.indexes

 

12：给students表创建添加数据（可以使用js的循环语法插入数据）

mongos> for (i=1; i<1000000; i++){

db.students.insert({"name": "yhy"+i, "age": i%100, "student_id": i, "skill": "ok"+i, "salary": "$"+i%10000})

}

 

13：复制mongodb1窗口，先查看一下students表有多少行数据了，在看看此时的shard分片的状态

mongos>db.students.find().count(); # 查看students表中有多少行数据了

237751

mongos> sh.status() # 再查看一下shard的状态信息

--- Sharding Status ---

sharding version: {

"_id" : 1,

"version" : 4,

"minCompatibleVersion" : 4,

"currentVersion" : 5,

"clusterId" : ObjectId("59f6caf5c93e5ff2a637a0cd")

}

shards: # 只是shard节点列表

{ "_id" : "shard0000", "host" : "192.168.43.13:27017" }

{ "_id" : "shard0001", "host" : "192.168.43.12:27017" }

databases: # 这是支持shard机制的库

{ "_id" : "admin", "partitioned" : false, "primary" : "config" }

{ "_id" : "test", "partitioned" : false, "primary" : "shard0001" }

{ "_id" : "uplookingdb", "partitioned" : true, "primary" : "shard0001" }

uplookingdb.students 这是支持shard机制的表

shard key: { "age" : 1 } # 用表上的哪个索引作为shard的键

chunks: # 这里是显示chunk的发布情况

shard0000 2 # 发布两个chunk

shard0001 3 # 发布三个chunk

{ "age" : { "$minKey" : 1 } } -->> { "age" : 1 } on : shard0000 Timestamp(2, 0)

{ "age" : 1 } -->> { "age" : 47 } on : shard0000 Timestamp(3, 0)

{ "age" : 47 } -->> { "age" : 72 } on : shard0001 Timestamp(3, 2)

{ "age" : 72 } -->> { "age" : 99 } on : shard0001 Timestamp(3, 3)

{ "age" : 99 } -->> { "age" : { "$maxKey" : 1 } } on : shard0001 Timestamp(2, 3)

 

 

 

14：过一段时间之后，等数据在mongodb1节点插入完毕，在mongodb3，mongodb4上就会发现一部分年龄的人在mongodb3，而另外一部分在mongodb4上

db.students.find();

 

 

15：再添加一个新的节点进来，在mongodb1上设置它为shard节点，此时你会发现chunk就会自动迁移，无需我们手动管理，但是chunk在shard节点中自动迁移会消耗大量的带宽以及带来I/O压力，因此，一般是现在mongodb1节点将

 

16：如果创建一个库，且添加一张表，且并没有将库和表添加到shard机制中来，那么对于每一个shard节点实现副本集赋值功能，以及多个config节点，同学们一定要完成（我出去调研的时候发现，MongoDB的应用场景再某种程度上不比MySQL弱）