Sharding结构

转载自https://www.it610.com/article/5487366.htm
在这里插入图片描述
从图中可以看出，MongoDB sharding 主要分为 3 大部分。shard 节点、config 节点和 mongos节点。对客户端来说，直接访问的是图中绿色的 mongos 节点。背后的 config 节点和 shard 节点是客户端不能直接访问的。mongos 的主要作用是数据路由。从元数据中定位数据位置，合并查询结果。另外，mongos 节点还负责数据迁移和数据自动平衡，并作为 sharding 集群的管理节点。它对外的接口就和普通的 mongodb 一样。因此，可以使用标准 mongodb 客户端和驱动进行访问。mongos 节点是无状态的，本身不保存任何数据和元数据，因此可以任意水平扩展，这样任意一个节点发生故障都可以很容易的进行故障转移，不会造成严重影响。

其中蓝色的 shard 节点就是实际存放数据的数据节点。每个 shard 节点可以是单个 mongodb 实例，也可以是一个 replica set 。通常在使用 sharding 的时候，都会同时使用 replica set 来实现高可用，以免集群内有单个节点出故障的时候影响服务，造成数据丢失。同时，可以进一步通过读写分离来分担负载。对于每个开启 sharding 的 db 来说，都会有一个默认 shard 。初始时，第一个 chunk 就会在那里建立。新数据也就会先插入到那个 shard 节点中去。

图中紫色的 config 节点存储了元数据，包括数据的位置，即哪些数据位于哪些节点，以及集群配置信息。config 节点也是普通的 mongod 。如图所示，一组 config 节点由 3 个组成。这 3 个 config 节点并非是一个 replica set。它们的数据同步是由 mongos 执行两阶段提交来保证的。这样是为了避免复制延迟造成的元数据不同步。config 节点一定程度上实现了高可用。在一个或两个节点发生故障时，config 集群会变成只读。但此时，整个 sharding 集群仍然可以正常读写数据。只是无法进行数据迁移和自动均衡而已。

replica set

在sharding结构中shard节点一般是replica set集群
图片来自https://www.cnblogs.com/baizhanshi/p/10098011.html

replica set是MongoDB的一种集群，有Primary、Secondary和arbiter，Primary是集群中的主节点，处理读写操作，secondary通过oplog同步primary 的数据，arbiter只参与投票。当主节点故障后，secondary节点和arbiter通过选举机制选出新的primary，Replica Set中的成员个数为偶数个时，就需要添加一个Arbiter用于投票选举哪个可以升级为Primary，不能在Primary或者Secondary主机上运行Arbiter。

mmap

mongdb的数据使用BSON结构存储在磁盘文档中，通过调用系统函数mmap将使用的数据加载到内存，保持热点数据在内存，加快了数据的读写速度。
mmap类似共享内存，是一种内存映射技术。是在用户态和内核态分配一块共用的内存，用户程序可以直接访问内核空间的缓冲区，这样数据无需再从内核空间复制到用户空间。

Chunk的分裂和迁移

Chunk是shard存储数据时所分的数据块，使用逻辑划分，位置数据保存在config的元数据中，Chunk size默认大小64M。

Chunk的分裂

mongoDB 的自动 chunk 分裂只会发生在写入数据时，当写入的数据超过一定量时，就会触发 chunk 的分裂，具体规则如下。

int ChunkManager::getCurrentDesiredChunkSize() const {
    // split faster in early chunks helps spread out an initial load better
    const int minChunkSize = 1 << 20;  // 1 MBytes

    int splitThreshold = Chunk::MaxChunkSize;  // default 64MB

    int nc = numChunks();

    if (nc <= 1) {
        return 1024;
    } else if (nc < 3) {
        return minChunkSize / 2;
    } else if (nc < 10) {
        splitThreshold = max(splitThreshold / 4, minChunkSize);
    } else if (nc < 20) {
        splitThreshold = max(splitThreshold / 2, minChunkSize);
    }

    return splitThreshold;
}

bool Chunk::splitIfShould(OperationContext* txn, long dataWritten) const {
    dassert(ShouldAutoSplit);
    LastError::Disabled d(&LastError::get(cc()));

    try {
        _dataWritten += dataWritten;
        int splitThreshold = getManager()->getCurrentDesiredChunkSize();
        if (_minIsInf() || _maxIsInf()) {
            splitThreshold = (int)((double)splitThreshold * .9);
        }

        if (_dataWritten < splitThreshold / ChunkManager::SplitHeuristics::splitTestFactor)
            return false;

        if (!getManager()->_splitHeuristics._splitTickets.tryAcquire()) {
            LOG(1) << "won't auto split because not enough tickets: " << getManager()->getns();
            return false;
        }
        ......
}

Chunk的迁移

转自：https://wenku.baidu.com/view/45e599fdbaf3f90f76c66137ee06eff9aff8495c.html

当chunk数最多的shard节点和chunk数最少的shard节点的个数差大于设定的阈值时，会触发数据迁移。
chunk的迁移分为7个步骤：
1、balancer进程将moveChunk的命令发送到源shard中
2、源shard使用内部removeChunk命令开始移动，迁移过程中，该Chunk的操作依旧在源shard上进行，源shard依旧负责该chunk的写入操作
3、目标shard开始创建所需索引
4、目标shard开始请求chunk中的文档并开始接受数据的复制
5、接受完源shard的最后一个文档之后，目标shard启动一个同步进程，这个进程会拉取迁移期间的日志，将迁移期间对该Chunk的操作更新到目标chunk中
6、当完全同步时，源shard连接到config数据库并更新chunk的位置元数据
7、完成数据更新后，一旦在源shard上没有对该chunk的操作，源shard会异步删除chunk