MongoDB分片配置

简单注解：

1. mongos 路由进程， 应用程序接入mongos再查询到具体分片,监听端口默认27017
2. config server 路由表服务， 每一台都具有全部chunk的路由信息 
3. shard为数据存储分片， 每一片都可以是复制集（replica set)

部署分片集群

#配置mongoDB shareding时，使用hosts域名代替IP地址好处非常多，可以在很多迁移的地方，直接更换迁移服务器，IP地址变了也没关系

#例如在迁移config服务器时，只需要在mongos服务器里面把配置的config服务器的hosts绑定修改一下即可

step 1 启动config server

/usr/bin/mongod --configsvr --dbpath /data/mongodb/config/  --logpath/data/mongodb/config/log/configdb.log --port 20000

#正式生产环境一般启动3个config server,启动3个是为了做热备,三个config server中有一个失败则三个config server集群变成只读群集

step 2 启动mongos

/usr/bin/mongos --configdb 192.168.10.1:20000,192.168.10.2:20000,192.168.10.3:20000 --logpath/data/mongodb/mongos/mongos.log

#把所有要加入到分片的mongo配置文件都加入进来

step3 启动分片mongod

/usr/bin/mongod --shardsvr --replSet rs1 --dbpath /data/mongodb/data/ --logpath /tmp/sharda.log  --port 10000

/usr/bin/mongod --shardsvr --replSet rs2 --dbpath /data/mongodb/data/ --logpath /tmp/sharda.log  --port 10000

/usr/bin/mongod --shardsvr --replSet rs3 --dbpath /data/mongodb/data/ --logpath /tmp/sharda.log  --port 10000  –directoryperdb

#分片是一个mongo副本集，--replSet rs1是副本集的名称，生产环境即使分片是单台服务器，也建议这么设置，方便以后扩展

#上面是在3台不同的服务器上启动的三个副本集，名称分别上rs1，rs2，rs3

#可以启用这个命令， –directoryperdb

/usr/bin/mongod --shardsvr --dbpath /data/mongodb/data/ --logpath /tmp/sharda.log  --port 10000

#分片是一个普通的mongo服务器

 

step4 在mongos添加分片

mongo 127.0.0.1/admin

#用mongo 连接上mongos，切换到admin库

sh.addShard("rs1/192.168.10.1:20000") 

sh.addShard("rs2/192.168.10.2:20000") 

sh.addShard("rs3/192.168.10.3:20000") 

sh.addShard("rs3/192.168.10.3:20000"，"allowLocal :1") 

sh.addShard("shared4/10.26.79.89:27017,10.26.165.157:27017,10.26.165.112:27017") 

db.runCommand( { addshard : "127.0.0.1:27020", allowLocal :1} )

#添加一个 replica set副本集作为一个分片

#上面是添加了三个副本集，每个副本集目前只有一个成员，做了三个分片

#实际上在分片情况下在一个副本集中可以只有一个或者两个成员，不一定至少三个

#添加本地的分片时可能需要参数“allowLocal :1”

sh.addShard("192.168.10.1:20000")

#添加非replica set作为分片： 

step5 对某个数据库启用分片

sh.enableSharding("test")

#这里只是标识这个test数据库可以启用分片，但实际上还并没有进行分片。

 

step6 对collection进行分片

sh.shardCollection("records.people", { "zipcode": 1, "name": 1 } )

sh.shardCollection("people.addresses", { "state": 1, "_id": 1 } )

sh.shardCollection("assets.chairs", { "type": 1, "_id": 1 } ) 

#对某个库的某个表进行分片，分片的key可以使用单个字段，也可以使用多个字段

#这里分片用的key，就自动变成该表的索引字段

#至于具体哪一行分到哪一片了，只有config配置文件知道

#不像atlas可以明确的知道那行在哪个表里面

#对一个已经有数据的表进行分片时需要先建立索引，再把索引字段当作分片key来进行分片

db.alerts.ensureIndex( { _id : "hashed"} )

sh.shardCollection("events.alerts", { "_id": "hashed"} )

db.t3.ensureIndex({age:1} , {backgroud:true})

#对alerts表进行建立索引操作，增加一个_id索引字段，并对该字段生成随机hash值，这样就可以根据这个hash sharded key进行分片了

#hash sharded key是为了解决某些情况下sharded key的 write scaling的问题。

#_id字段是mongodb默认每行都有的

分片的正确姿势

sh.enableSharding("mexueGrowth")

#先对数据库启用分片

db.growth_user_record.ensureIndex({ "userId" : 1, "recordId" : 1 }, { name : "_idx_userId_recordId" }, { "background" : true })

#对需要分片的空的collection建立分片索引

sh.shardCollection("mexueGrowth.growth_user_record", { "userId" : 1, "recordId" : 1 } )

#在空的collection上启用分片

#最后将数据导入

#这样就可以保证分片一定成功，不论数据量有多大

如何选择shard key

• shard key需要有高的cardinality，也就是shard key需要拥有很多不同的值， 便于数据的切分和迁移。
• 尽量与应用程序融合，让mongos面对查询时可以直接定位到某个shard
• 具有随机性，这是为了不会让某段时间内的insert请求全部集中到某个单独的分片上，造成单片的写速度成为整个集群的瓶颈
• 用objectId作为shard key时会发生随机性差情况，ObjectId实际上由进程ID+TIMESTAMP + 其他因素组成， 所以一段时间内的timestamp会相对集中
• 不过随机性高会有一个副作用，就是query isolation性比较差
• 可用hash key增加随机性

如何查看shard信息

登上mongos

sh.status()

sh.status({verbose:true})

#需要看的详细一点

Sharding Status ---

sharding version: { "_id": 1, "version": 3 }

shards:

{  "_id": "shard0000",  "host": " m0.example.net:30001"}

{  "_id": "shard0001",  "host": " m3.example2.net:50000"}

databases:

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

{  "_id": "contacts",  "partitioned": true,  "primary": "shard0000"}

foo.contacts

shard key: { "zip": 1 }

chunks:

shard0001    2

shard0002    3

shard0000    2

{ "zip": { "$minKey": 1 } } -->> { "zip": 56000 } on : shard0001 { "t": 2, "i": 0 }

{ "zip": 56000 } -->> { "zip": 56800 } on : shard0002 { "t": 3, "i": 4 }

{ "zip": 56800 } -->> { "zip": 57088 } on : shard0002 { "t": 4, "i": 2 }

{ "zip": 57088 } -->> { "zip": 57500 } on : shard0002 { "t": 4, "i": 3 }

{ "zip": 57500 } -->> { "zip": 58140 } on : shard0001 { "t": 4, "i": 0 }

{ "zip": 58140 } -->> { "zip": 59000 } on : shard0000 { "t": 4, "i": 1 }

{ "zip": 59000 } -->> { "zip": { "$maxKey": 1 } } on : shard0000 { "t": 3, "i": 3 }

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

 

 

 

备份cluster meta information

#mongoDB的Balance是指分片数据时存储在config数据库里的数据同步

#就是每个config server之间的数据同步

Step1 disable balance process. 

    sh.getBalancerState()

    #查看分片的Balancer复制状态

    sh.setBalancerState(false)

    #停止分片的Balancer复制

Step2 关闭config server 

Step3 备份数据文件夹 

Step4 重启config server 

Step5 enable balance process.

    sh.setBalancerState(true)

    #启动分片的Balancer复制

查看balance 状态

可以通过下面的命令来查看当前的balance进程状态。先连接到任意一台mongos

use config

db.locks.find( { _id : "balancer" } ).pretty()

{   "_id" : "balancer",

"process" : " mongos0.example.net:1292810611:1804289383",

  "state" : 2,

     "ts" : ObjectId("4d0f872630c42d1978be8a2e"),

   "when" : "Mon Dec 20 2010 11:41:10 GMT-0500 (EST)",

    "who" : " mongos0.example.net:1292810611:1804289383:Balancer:846930886",

    "why" : "doing balance round" }

 

state=2 表示正在进行balance, 在2.0版本之前这个值是1

配置balance时间窗口

可以通过balance时间窗口指定在一天之内的某段时间之内可以进行balance， 其他时间不得进行balance。

先连接到任意一台mongos

use config

db.settings.update({ _id : "balancer" }, { $set : { activeWindow : { start : "23:00", stop : "6:00" } } }, true )

这个设置让只有从23:00到6:00之间可以进行balance

也可以取消时间窗口设置:

use config

db.settings.update({ _id : "balancer" }, { $unset : { activeWindow : true } })

修改chunk size

这是一个全局的参数。 默认是64MB。

小的chunk会让不同的shard数据量更均衡。 但会导致更多的Migration。

大的chunk会减少migration。不同的shard数据量不均衡。

这样修改chunk size。先连接上任意mongos

db.settings.save( { _id:"chunksize", value: "256" } )

单位是MB

何时会自动balance

每个mongos进程都可能发动balance。

一次只会有一个balance跑。 这是因为需要竞争这个锁:

db.locks.find( { _id : "balancer" } )

balance一次只会迁移一个chunk。

 

设置分片上最大的存储容量

有两种方式，第一种在添加分片时候用maxSize参数指定:

db.runCommand( { addshard : " example.net:34008", maxSize : 125 } )

第二种方式可以在运行中修改设定：

use config

db.shards.update( { _id : "shard0000" }, { $set : { maxSize : 250 } } )

删除分片

连接上任意一台mongos

STEP1 确认balancer已经打开

STEP2 运行命令:

db.runCommand( { removeShard: "mongodb0" } )

#mongodb0是需要删除的分片的名字。这时balancer进程会开始把要删除掉的分片上的数据往别的分片上迁移。

 

STEP3 查看是否删除完

还是运行上面那条removeShard命令

db.runCommand( { removeShard: "mongodb0" } ) 

如果还未删除完数据则返回：

{ msg: "draining ongoing" , state: "ongoing" , remaining: { chunks: NumberLong(42), dbs : NumberLong(1) }, ok: 1 }

STEP4 删除unsharded data

有一些分片上保存上一些unsharded data， 需要迁移到其他分片上：

 

可以用sh.status()查看分片上是否有unsharded data。

如果有则显示：

{ "_id" : "products", "partitioned" : true, "primary" : "mongodb0" }

用下面的命令迁移：

db.runCommand( { movePrimary: "products", to: "mongodb1" })

只有全部迁移完上面的命令才会返回：

{ "primary" : "mongodb1", "ok" : 1 }

#实际上上面命令是重新设置某张表的初始primary

STEP5 最后运行命令

db.runCommand( { removeShard: "mongodb0" } )

##在迁移完一个分片后，在mongs里面查看movePrimary的show collections/show tables时会报错，此时需要重新启动一下mongos服务器

删除在sharding中删除复制集replica set的成员

假设sharding的分片是复制集，需要删除某个复制集的某个成员。

只要在复制集的设置中删除该成员即可，不需要在mongos中删除。mongos会自动同步这个配置。

例如 sharding cluster中有这个分片:

 

{  "_id" : "rs3",  "host" : "rs3/192.168.1.5:30003,192.168.1.6:30003" }

 

需要删除192.168.1.6:30003这个成员。

只需要:

step 1: 在192.168.1.6:30003上运行db.shutdownServer()关闭mongod

step 2:在rs3的primary的成员192.168.1.5:30003上执行

rs.remove("192.168.1.6:30003")

常见问题：

新添加的分片始终不进行数据同步的问题

 

1 如果sharding cluster中新添加的分片始终不进行数据migration, 并出现类似日志:

 

migrate commit waiting for 2 slaves for

 

则需要重启该分片的mongod进程。

 

特别需要注意的是，如果某mongod进程是一个replica set的primary， 并且该replica set上只有一个mongod， 那么不能用db.shutdownServer()的方法关闭。 会报下面的错误:

 

no secondary is within 10 seconds of the primary,

 

需要用下面的命令关闭：

 

db.adminCommand({shutdown : 1, force : true})

一个新的分片始终不进行更新的问题

 

日志里出现这样的错误：

 

secondaryThrottle on, but doc insert timed out after 60 seconds, continuing

 

通过1 将所有分片的secondary和arbitary删除掉，2 重启同步的分片解决。

 

mongod的日志出现

moveChunk cannot start migration with zero version

 

解决方法，在mongos上运行

mongos> use admin

switched to db admin

mongos> db.runCommand("flushRouterConfig");

{ "flushed" : true, "ok" : 1 }

PS:额外补充

MongoDB持续灌入大数据遇到的一些问题

首先这类NoSQL数据库的设计宗旨基本是“读多写少”。

而我们的需求是：有一大批数据（5亿条记录，每条100B左右,按此计算，一亿行数据大概10G空间，5亿条记录有50G,有命令查看平均一条数据大小的，这里说的不准）。需要灌入MongoDB。

考虑到数据规模，事先已经做好了Sharding，10台机器。

1、并发12进程，持续灌入数据。

一开始速度很快，基本10W/s，到了1亿6千万左右，开始变成龟速。经过仔细检查，mongos中报大量如下错误：

Wed Jun  6 16:56:41 [conn33] warning: splitChunk failed - cmd: { splitChunk: "trec.doc", keyPattern: { id: 1.0 }, min: { id: MinKey }, max: { id: "00029610933" }, from: "172.22.0.16:27018", splitKeys: [ { id: "00000000000" } ], shardId: "trec.doc-id_MinKey", configdb: "172.22.0.11:27019" } result: { who: { _id: "trec.doc", process: "node5:27018:1338970017:616299555", state: 2, ts: ObjectId('4fcf1a425ac42b3930c16116'), when: new Date(1338972738056), who: "node5:27018:1338970017:616299555:conn14:1486636348", why: "migrate-{ id: "01032438609" }" }, errmsg: "the collection's metadata lock is taken", ok: 0.0 }

其实很很容易理解，灌入速度太暴力，导致很多后台进程如分片、迁移Shard的任务一直拿不到锁。

 

最后导致Shard1上面有130个Chunk，其他上面就是3~5个。 ###不论是否先启用分片，插入数据是都会先插入到primary shareding中

杀掉进程后，Mongo开始逐渐均衡，但考虑到时间会很长，遂删除数据。

 

2、灌数据建索引。

 

我们对灌入的数据需要建一些索引，之前没有经验，在配置好Shard后就ensureIndex了，导致到达1亿条后速度明显变慢。

其实这种先写后读的需求，完全可以等全部插入后再建索引，防止大量的锁竞争。

 

3、关于数据分块大小

 

默认的64MB，对于千万级别是可以的。像我们这种，就要适当调大，不然反复的split会导致性能下降。如果再加上持续插入数据，很可能导致一直无法split，当分片过大后就无法再进行迁移了。

 

4、关于自动Balance及我们的策略

 

经过仔细阅读文档，我发现MongoDB的Balance做的非常好，是后台自动完成的。但有一个缺陷：就是前面提到的，前台数据插入优先级更高，Balance只能在空闲时候做。

因此，我把5亿条数据分为10部分，每部分插入完成后，等待Balance平衡后，再插入下一部分。一般来说平衡的过程是非常快的，等一会再插入，能保证持续不断的性能。

关于查看各个Shard上的Chunk数量：

db.printShardingStatus()

此外，还修改了Chunk Size为256MB

常用查看命令：

db.printShardingStatus()

#查看整个mongdb服务器所有数据库是否启用分片的信息

use db

db.collection.stats()

#查看某个集合的状态，包括是否启用了分片,需要先切换到该DB下面