MongoDB--分片(shard)和分块(chunk)

MongoDB–分片(shard)和分块(chunk)

一：开启MongoDB分片集群的步骤

• 各台机器都开始mongoconfig配置服务器
• 各台机器都开始shard1,shard2,shard3…服务
• 各台机器都开启mongos路由服务器
• 进入任意态mongos客户端

二：全局变量sh管理分片

• sh.status()：查看集群状态
• sh.help() ：查看可以使用的全局变量
• sh.enableSharding(“数据库名”)：指定数据库启动分片
• sh.shardCollection(“集合名”，{“片键”:1}) ：指定集合和片键，如果要作为片键的字段不存在，mongos会自动为该字段创建索引；如果字段存在，shardCollection()会返回错误，必须先给该字段创建索引。
• sh.addShard(shard1/172.16.0.65:22001,172.16.0.66:22001,172.16.0.67:22001) ：串联起来分片（在admin数据库下执行）

查看集群的状态信息，部分信息如下

{ "name" : { "$minKey" : 1 } } -->> { "name" : NumberLong("-6148914691236517204") } on : shard1 Timestamp(3, 2) 
{ "name" : NumberLong("-6148914691236517204") } -->> { "name" : NumberLong("-3074457345618258602") } on : shard1 Timestamp(3, 3) 
{ "name" : NumberLong("-3074457345618258602") } -->> { "name" : NumberLong(0) } on : shard2 Timestamp(3, 4) 
{ "name" : NumberLong(0) } -->> { "name" : NumberLong("3074457345618258602") } on : shard2 Timestamp(3, 5) 
{ "name" : NumberLong("3074457345618258602") } -->> { "name" : NumberLong("6148914691236517204") } on : shard3 Timestamp(3, 6) 
{ "name" : NumberLong("6148914691236517204") } -->> { "name" : { "$maxKey" : 1 } } on : shard3 Timestamp(3, 7) 

在分片之前可以人为集合是一个单一的数据块，从片键的最小值一直到最大值都是在这个块上，分片依据片键范围将集合拆分为多个数据块。，minKey~maxKey之间，minKey是负无穷，maxKey是正无穷大，然后数据被均匀的分到了三个切片上。

查询的时候包含片键的查询能够直接被发动到目标分片上，这样的查询叫做定向查询；

查询的时候不使用片键，mongos就会把查询分发到所有的分片上，这样的查询叫分散-聚集查询：mongos将查询分发到所有的分片上，然后在将各个分片的查询结果聚集起来。

三：何时分片

分片可以用来：

• 增加可用RAM
• 增加可用磁盘空间
• 减轻单台服务器的负载
• 处理单个mongod无法承受的吞吐量

综合考量自己的需求。

四：关于高可用集群角色的分工

首先了解下MongoDB的集群的角色

从图中可以看到有四个组件：mongos、config server、shard、replica set。

mongos（请求入口）

数据库集群请求的入口，所有的请求都通过mongos进行协调，不需要在应用程序添加一个路由选择器，mongos自己就是一个请求分发中心，它负责把对应的数据请求转发到对应的shard服务器上。在生产环境通常有多mongos作为请求的入口，防止其中一个挂掉所有的mongodb请求都没有办法操作。

config server（配置服务器）

顾名思义为配置服务器，存储所有数据库元信息（路由、分片）的配置。mongos本身没有物理存储分片服务器和数据路由信息，只是缓存在内存里，配置服务器则实际存储这些数据。mongos第一次启动或者关掉重启就会从 config server 加载配置信息，以后如果配置服务器信息变化会通知到所有的 mongos 更新自己的状态，这样 mongos 就能继续准确路由。在生产环境通常有多个 config server 配置服务器，因为它存储了分片路由的元数据，防止数据丢失！

shard，分片（sharding）

是指将数据库拆分，将其分散在不同的机器上的过程。将数据分散到不同的机器上，不需要功能强大的服务器就可以存储更多的数据和处理更大的负载。基本思想就是将集合切成小块，这些块分散到若干片里，每个片只负责总数据的一部分，最后通过一个均衡器来对各个分片进行均衡（数据迁移）。

replica set（副本集）

中文翻译副本集，其实就是shard的备份，防止shard挂掉之后数据丢失。复制提供了数据的冗余备份，并在多个服务器上存储数据副本，提高了数据的可用性， 并可以保证数据的安全性。

仲裁者（Arbiter）

是复制集中的一个MongoDB实例，它并不保存数据。仲裁节点使用最小的资源并且不要求硬件设备，不能将Arbiter部署在同一个数据集节点中，可以部署在其他应用服务器或者监视服务器中，也可部署在单独的虚拟机中。为了确保复制集中有奇数的投票成员（包括primary），需要添加仲裁节点做为投票，否则primary不能运行时不会自动切换primary。

简单了解之后，我们可以这样总结一下，应用请求mongos来操作mongodb的增删改查，配置服务器存储数据库元信息，并且和mongos做同步，数据最终存入在shard（分片）上，为了防止数据丢失同步在副本集中存储了一份，仲裁在数据存储到分片的时候决定存储到哪个节点。

五：块范围和块的拆分

1.块范围

MongoDB将文档分组为块，每个块由给定片键特定范围内的文档组成，一个块只存在一个分片上。在进行写入和删除的操作的时候，块内的文档数量和大小可能会发生变化，某个块增长到一定程度，MongoDB会自动将其拆分为两个较小的块。chunk默认的大小是64M，范围在1-1024M,块的范围为左闭又开即 [start,end)

可以在config数据库的chunks集合中查看块信息

mongos> db.chunks.find().pretty()
{
        "_id" : "config.system.sessions-_id_MinKey",
        "ns" : "config.system.sessions",
        "min" : {
                "_id" : { "$minKey" : 1 }
        },
        "max" : {
                "_id" : { "$maxKey" : 1 }
        },
        "shard" : "shard1",
        "lastmod" : Timestamp(1, 0),
        "lastmodEpoch" : ObjectId("5de8faa194cec5221991da0d")
}
.........
{
        "_id" : "testdb.table1-name_6148914691236517204",
        "lastmod" : Timestamp(3, 7),
        "lastmodEpoch" : ObjectId("5de9b17e94cec52219a24c02"),
        "ns" : "testdb.table1",
        "min" : {
                "name" : NumberLong("6148914691236517204")
        },
        "max" : {
                "name" : { "$maxKey" : 1 }
        },
        "shard" : "shard3"
}

2.块的拆分

mongos 会记录每个块中有多少数据，一旦达到了阈值就会检查是否需要对其进行拆分，如果确实需要拆分则可以在配置服务器上更新这个块的相关元信息。

chunk 的拆分过程如下：

1. mongos 接收到客户端发起的写请求后会检查当前块的拆分阈值点
2. 如果需要拆分，mongos 则会向分片服务器发起一个拆分请求
3. 分片服务器会做拆分工作，然后将信息返回 mongos

注意，相同的片键只能保存在相同的块中，如果一个相同的片键过多，则会导致一个块过大，成为 jumbo chunk，所以具有不同值的片键很重要。

在启动mongos时，可以通过指定–nosplit选项，从而关闭块的拆分

六：均衡器

均衡器负责数据的迁移，它会周期性的检查分片间是否存在不均衡，如果存在则会开始块的迁移。每隔几秒，mongos就会尝试变身为均衡器，如果没有其他可以使用的均衡器，mongos就会对整个集群加锁，以防止配置服务器对集群加锁，然后做一次均衡。均衡不会影响mongos正常的路由操作。（从 3.6 版本开始，均衡器不再需要 balancer lock ）

mongos> db.locks.findOne()
{
        "_id" : "config-movePrimary",   //_id是balancer的文档就是均衡器
        "state" : 0,   //0:非活动状态，2：正在均衡，1：尝试得到锁
        "process" : "ConfigServer",
        "ts" : ObjectId("5de8faa194cec5221991d9d3"), //时间戳
        "when" : ISODate("2019-12-05T12:40:01.382Z"),  //均衡时间
        "who" : "ConfigServer:LogicalSessionCacheRefresh", //表示当前或者曾经作为均衡器的mongos是哪一个
        "why" : "shardCollection"
}

均衡器的动态管理

均衡器可以动态的开启和关闭，也可以针对指定的集合开启和关闭，还可以手动控制均衡器迁移 chunk 的时间，避免在业务高峰期的时候迁移 chunk 从而影响集群性能。以下命令将均衡器的迁移 chunk 时间控制在凌晨 02 点至凌晨 06 点：

use config
db.settings.update(
{ _id: "balancer" },
{ $set: { activeWindow : { start : "02:00", stop : "06:00" } } },
{ upsert: true })

Chunk 的迁移

chunk 在以下情况会发生迁移：

• chunk 数位于 [1,20)，阈值为 2。
• chunk 数位于 [20,80)，阈值为 4。
• chunk 数位于 [80,max)，阈值为 8。

chunk 的迁移过程如下：

1. 均衡器进程发送 moveChunk 命令到源分片。
2. 源分片使用内部 moveChunk 命令，在迁移过程，对该块的操作还是会路由到源分片。
3. 目标分片构建索引。
4. 目标分片开始进行数据复制。
5. 复制完成后会同步在迁移过程中该块的更改。
6. 同步完成后源分片会连接到配置服务器，使用块的新位置更新集群元数据。
7. 源分片完成元数据更新后，一旦块上没有打开的游标，源分片将删除其文档副本。

迁移过程可确保一致性，并在平衡期间最大化块的可用性。

修改 chunk 大小的注意事项

修改 chunk 大小需要注意以下几点：

1. chunk 的自动拆分操作仅发生在插入或更新的时候。
2. 如果减少 chunk size，将会耗费一些时间将原有的 chunk 拆分到新 chunk，并且此操作不可逆。
3. 如果新增 chunk size，已存在的 chunk 只会等到新的插入或更新操作将其扩充至新的大小。
4. chunk size 的可调整范围为 1-1024MB。

注意：由于配置服务器不可用导致mongos无法获取块的新位置，会向客户端返回错误，所有尽可能保证配置服务器处于可用状态。