mongodb 系列 ~ 集群分片管理详解

最新推荐文章于 2024-06-28 14:57:20 发布

weixin_34059951

最新推荐文章于 2024-06-28 14:57:20 发布

阅读量347

点赞数

文章标签：数据库运维

原文链接：http://www.cnblogs.com/danhuangpai/p/10881901.html

版权

简介 mongo分片集群相关管理

0 定义基本单位chunk

1 数据集被拆分成数据块（chunk），每个数据块包含多个doc，数据块分布式存储在分片集群中

2 一个数据块默认64MB，当数据块达到64MB时就会创建新的块（默认值是64M)，然后进行不停的分裂，块越来越多

3 如果一个chunk只包含一个分片键值，mongodb 就不会split这个chunk,即使这个chunk超过了 chunk需要split时的大小。所以分片键的选择非常重要。如果一旦出现move chunk is big 就可以确定,选择的片键太大了

4 当分片集的chunk数量不均匀时,会触发move chunk

1 如何开启分片
db启动分片->分片加索引->collection启动分片
2 开启分片测试
1 库开启分片功能
use admin && db.runCommand( { enablesharding : "test" } )
2 集合片键加索引
use test &&　db.vast.ensureIndex( { id: 1 } )
３创建片键
use admin && db.runCommand( { shardcollection : "test.vast1",key : {id: 1,name:1} } )
4 数据插入测试
for(i=0;20000<i<40000;i++){ db.vast1.insert({"id":i,"name":"clsn","age":70,"date":new Date()}); }
db.vast.stats()
3 分片键目标
1将插入数据均匀分布到各个分片上；保证CRUD操作能够利用局部性；有足够的粒度进行块拆分。
2增加可用的RAM，增加可用磁盘空间，减轻单台服务器的负载，处理单个mongod无法承受的吞吐量
4 分片方法
1 范围分片
eg:id,date等带有明显顺序的
优势如果使用升序片键，那么数据物理上会是连续的，有利于基于范围的查询
场景适用于范围查询
启用命令类似 {date:1}
2 Hash 分片
eg:是用户名邮件地址 udid(唯一设备标识符) md5散列值或者是数据集中其他一些没有规律的键
优势能非常好的平均分配到各个shard上
场景适用于等值查询
启用命令 {date:"hashed"}
3 联合分片
随机值+范围值组成的联合索引
4 注意:
1 采用hash分片的策略chunk总数远远小于升序分片的个数
2 无论采用什么分片策略都要考虑业务本身,业务快是唯一的条件
5 分片键相关问题
1 片键一旦经过指定就不能进行更新和在线变更,而且本身必须为单列或者联合唯一索引
2 执行单文档 update,remove,delete 必须带上share-key
3 对于count(*)不准或者要执行group by操作的语句,可以采用aggreagte操作实现
4 不支持使用geoSearch查看地理位置
5 对于分片片键chunk分布问题可以通过sh.status()查看结果
5 谈谈move chunk
1 触发条件
1 removeShard操作
2 当数据量增加到超过分裂阈值,会触发chunk分裂,当各个分片的chunk分部不均匀时,会触发移动过程,保证各个节点chunk个数的平衡
3 设置窗口期,指定时间内触发
4 用户手动进行move chunk
2 变量
MongoDB 默认的 chunkSize 为64MB，如无特殊需求，建议保持默认值；chunkSize 会直接影响到 chunk 分裂、迁移的行为。

1 手动调整chunSize

chunksize默认的大小是64M,用mongos连接到config数据库，通过查看config.settings可以看到这个值：

2 更改块大小可能造成的印象

自动拆分仅在插入或更新时发生。
如果降低块大小，则所有块可能需要一段时间才能拆分为新大小。
分裂无法撤消。
如果增加块大小，现有块只会通过插入或更新而增长，直到达到新大小。
允许的块大小范围在1到1024兆字节之间，包括1和1024兆字节。

3 减小分裂及迁移的影响
1 创建窗口期,平时关闭balance,在业务低峰期开启(move chunk的消耗资源很大,建议这样做)
use config
db.settings.update({ _id : "balancer" }, { $set : { activeWindow : { start : "23:00", stop : "6:00" } } }, true )
取消时间窗口设置:
db.settings.update({ _id : "balancer" }, { $unset : { activeWindow : true } })

2 预先针对 collection分配一定数据量的chunk，这样在数据量用完之前,应该不会发生move chunk
4 迁移过程
1 原分片开始启动moveChunk命令，在移动的过程中，所有的操作还会指向原来的分片
2 目标分片开始创建所需要的索引，在3.0以后，moveChunk需要在移动之前，目标分片中存在所有的索引，可以理解为先在目标分片中创建这个索引。
3 目标分片开始向原分片请求数据，并复制数据
4 当数据全部写入到目标分片中，目标分片连接并更新config数据库对应的块信息
5 最后，原分片将这部分块删除。
5 维护命令
sh.status()
1 平衡器状态 0：非活动状态，1：正在获取，但还没有执行，2：正在均衡，迁移，有锁
2 last error move chunk触发的错误
6 相关错误
1 chunk too big to move
分析原因这是由于chunk太大的缘故,默认是64M,这通常是由于片键设置不合理造成的,造成了chunk太大,这时候balance已经无法自动拆分
解决方式
手动进行拆分
1 sh.stopBalancer()
2 查找大块
use config
db.chunks.find({jumbo:true})
3 进行拆分
sh.splitAt("db.collection", {shardkey:"拆分的临界值"})
4. 手动挪动块(可选步骤)->也可以等待自动迁移
sh.moveChunk("db.collection", {shardkey:"shardkey所在的块"}, "需要移动的目标分片ID");
5 sh.startBalancer()