MongoDB 集群
MongoDB 集群
学习目标
- MongoDB的副本集：操作、主要概念、故障转移、选举规则
- MongoDB的分片集群：概念、优点、操作、分片策略、故障转移
副本集-Replica Sets
简介
MongoDB中的副本集（Replica Set）是一组维护相同数据集的mongod服务。 副本集可提供冗余和高可用性，是所有生产部署的基础。
也可以说，副本集类似于有自动故障恢复功能的主从集群。通俗的讲就是用多台机器进行同一数据的异 步同步，从而使多台机器拥有同一数据的多个副本，并且当主库当掉时在不需要用户干预的情况下自动 切换其他备份服务器做主库。而且还可以利用副本服务器做只读服务器，实现读写分离，提高负载。
- 冗余和数据可用性
复制提供冗余并提高数据可用性。 通过在不同数据库服务器上提供多个数据副本，复制可提供一定级别 的容错功能，以防止丢失单个数据库服务器。
在某些情况下，复制可以提供增加的读取性能，因为客户端可以将读取操作发送到不同的服务上， 在不 同数据中心维护数据副本可以增加分布式应用程序的数据位置和可用性。 您还可以为专用目的维护其他 副本，例如灾难恢复，报告或备份。
- MongoDB中的复制
副本集是一组维护相同数据集的mongod实例。 副本集包含多个数据承载节点和可选的一个仲裁节点。 在承载数据的节点中，一个且仅一个成员被视为主节点，而其他节点被视为次要（从）节点。
主节点接收所有写操作。 副本集只能有一个主要能够确认具有{w：“most”}写入关注的写入; 虽然在某些情况下，另一个mongod实例可能暂时认为自己也是主要的。主要记录其操作日志中的数据集的所有 更改，即oplog。
辅助(副本)节点复制主节点的oplog并将操作应用于其数据集，以使辅助节点的数据集反映主节点的数据集。 如果主要人员不在，则符合条件的中学将举行选举以选出新的主要人员。
- 主从复制和副本集区别
主从集群和副本集最大的区别就是副本集没有固定的“主节点”；整个集群会选出一个“主节点”，当其挂 掉后，又在剩下的从节点中选中其他节点为“主节点”，副本集总有一个活跃点(主、primary)和一个或多 个备份节点(从、secondary)。
副本集的三个角色
副本集有两种类型三种角色
两种类型：
- 主节点（Primary）类型：数据操作的主要连接点，可读写。
- 次要（辅助、从）节点（Secondaries）类型：数据冗余备份节点，可以读或选举。
三种角色：
主要成员（Primary）：主要接收所有写操作。就是主节点。
副本成员（Replicate）：从主节点通过复制操作以维护相同的数据集，即备份数据，不可写操作，但可 以读操作（但需要配置）。是默认的一种从节点类型。
仲裁者（Arbiter）：不保留任何数据的副本，只具有投票选举作用。当然也可以将仲裁服务器维护为副 本集的一部分，即副本成员同时也可以是仲裁者。也是一种从节点类型。
关于仲裁者的额外说明：
您可以将额外的mongod实例添加到副本集作为仲裁者。 仲裁者不维护数据集。 仲裁者的目的是通过 响应其他副本集成员的心跳和选举请求来维护副本集中的仲裁。 因为它们不存储数据集，所以仲裁器可 以是提供副本集仲裁功能的好方法，其资源成本比具有数据集的全功能副本集成员更便宜。
如果您的副本集具有偶数个成员，请添加仲裁者以获得主要选举中的“大多数”投票。 仲裁者不需要专用硬件。
仲裁者将永远是仲裁者，而主要人员可能会退出并成为次要人员，而次要人员可能成为选举期间的主要 人员。
如果你的副本+主节点的个数是偶数，建议加一个仲裁者，形成奇数，容易满足大多数的投票。
如果你的副本+主节点的个数是奇数，可以不加仲裁者。
副本集架构目标
搭建：一主一副本一仲裁
副本集的创建
第一步：创建主节点
建立存放数据和日志的目录
1 | #-----------myrs |
新建或修改配置文件
1 | vim /mongodb/replica_sets/myrs_27017/mongod.conf |
myrs_27017：
1 | systemLog: |
启动节点服务：
1 | /usr/local/mongodb/bin/mongod -f /mongodb/replica_sets/myrs_27017/mongod.conf |
第二步：创建副本节点
建立存放数据和日志的目录
1 | #-----------myrs |
新建或修改配置文件：
1 | mkdir /mongodb/replica_sets/myrs_27018/ |
或 vi编辑器中查找文本中的所有 27017 并将其替换为 27018。：
1 | :% s/27017/27018/g |
启动节点服务：
1 | /usr/local/mongodb/bin/mongod -f /mongodb/replica_sets/myrs_27018/mongod.conf |
第三步：创建仲裁节点
建立存放数据和日志的目录
1 | #-----------myrs |
仲裁节点：
新建或修改配置文件：
1 | mkdir /mongodb/replica_sets/myrs_27019/ |
启动节点服务：
1 | /usr/local/mongodb/bin/mongod -f /mongodb/replica_sets/myrs_27019/mongod.conf |
使用命令行查看mongo服务
1 | [root@master myrs_27019]# ps -ef | grep mongo |
第四步：初始化配置副本集和主节点
使用客户端命令连接任意一个节点，但这里尽量要连接主节点(27017节点)：
1 | /usr/local/mongodb/bin/mongo --host=192.168.72.200 --port=27017 |
结果，连接上之后，很多命令无法使用，比如 show dbs 等，必须初始化副本集才行
准备初始化新的副本集：
语法：
1 | rs.initiate(configuration) |
选项:
| Parameter | Type | Description |
|---|---|---|
configuration |
document | Optional. A document that specifies configuration for the new replica set. If a configuration is not specified,MongoDB uses a default replica set configuration. |
使用默认的配置来初始化副本集：
1 | rs.initiate() |
执行结果：
1 | > rs.initiate() |
提示：
- “ok”的值为1，说明创建成功。
- 命令行提示符发生变化，变成了一个从节点角色，此时默认不能读写。稍等片刻，回车，变成主节 点。
第五步：查看副本集的配置内容
说明：返回包含当前副本集配置的文档。
语法：
1 | rs.conf(configuration) |
提示：
rs.config() 是该方法的别名。
configuration：可选，如果没有配置，则使用默认主节点配置。
在27017上执行副本集中当前节点的默认节点配置
1 | myrs:PRIMARY> rs.conf() |
"_id" : "myrs"：副本集的配置数据存储的主键值，默认就是副本集的名字"members"：副本集成员数组，此时只有一个："host" : "180.76.159.126:27017"，该成员不是仲裁节点："arbiterOnly" : false，优先级（权重值）："priority" : 1"settings"：副本集的参数配置。
提示：副本集配置的查看命令，本质是查询的是 system.replset 的表中的数据：
1 | myrs:PRIMARY> use local |
第六步：查看副本集状态
返回包含状态信息的文档。此输出使用从副本集的其他成员发送的心跳包中获得的数据反映副本集的当前状态
1 | rs.status() |
在27017上查看副本集状态：
1 | myrs:PRIMARY> rs.status() |
说明：
- “set” : “myrs” ：副本集的名字
- “myState” : 1：说明状态正常
- “members” ：副本集成员数组，此时只有一个： “name” : “180.76.159.126:27017” ，该成员的角色是 “stateStr” : “PRIMARY”, 该节点是健康的： “health” : 1 。
添加副本节点
在主节点添加从节点，将其他成员加入到副本集
1 | rs.add(host, arbiterOnly) |
选项:
| Parameter | Type | Description |
|---|---|---|
| host | string or document | 要添加到副本集的新成员。指定为字符串或配置文档：1）如果是一个字符串，则需要指定新成员的主机名和可选的端口号；2）如果是一个文档，请指定在members数组中找到的副本集成员配置文档。您必须在成员配置文档中指定主机字段。有关文档配置字段的说明，详见下方文档：”主机成员的配置文档” |
| arbiterOnly | boolean | 可选的。仅在值为字符串时适用。如果为true，则添加的主机是仲裁者。 |
主机成员的配置文档：
1 | { |
示例：
将27018的副本节点加添加到副本集汇总：
1 | rs.add("localhost:27018") |
添加仲裁从节点
1 | rs.add(host,arbiterOnly) |
副本集的数据读写操作
副本节点 (SECONDARY) 默认不能 read , 更不可能 write 数据, 需要
1 | rs.slaveOk() // 同意加入作为从节点副本集 |
数据会自动同步, 但是会有延迟
仲裁者节点, 不存放任何数据 -> rs.slaveOk() 也看不到数据
主节点的选举原则
MongoDB在副本集中，会自动进行主节点的选举，主节点选举的触发条件
- 主节点故障
- 主节点网络不可达 (默认心跳信息为 10 秒)
- 人工干预
rs.stepDown(600)
一旦触发选举，就要根据一定规则来选主节点
选举规则是根据票数来决定谁获胜
- 票数最高，且获得了“大多数”成员的投票支持的节点获胜。
- “大多数”的定义为：假设复制集内投票成员数量为N，则大多数为 N/2 + 1。例如：3个投票成员， 则大多数的值是2。当复制集内存活成员数量不足大多数时，整个复制集将无法选举出Primary， 复制集将无法提供写服务，处于只读状态。
- 若票数相同，且都获得了“大多数”成员的投票支持的，数据新的节点获胜。
- 数据的新旧是通过操作日志 oplog 来对比的。
在获得票数的时候，优先级（priority）参数影响重大。
可以通过设置优先级（priority）来设置额外票数。优先级即权重，取值为0-1000，相当于可额外增加 0-1000的票数，优先级的值越大，就越可能获得多数成员的投票（votes）数。指定较高的值可使成员 更有资格成为主要成员，更低的值可使成员更不符合条件。
默认情况下，优先级的值是 1
故障测试
副本节点故障测试
关闭 27018 副本节点
- 主节点和仲裁节点对
27018的心跳失败。因为主节点还在，因此，没有触发投票选举。 - 如果此时，在主节点写入数据。再启动从节点，会发现，主节点写入的数据，会自动同步给从节点。
主节点故障测试
关闭27017节点
- 从节点和仲裁节点对27017的心跳失败，当失败超过10秒，此时因为没有主节点了，会自动发起投票。
- 而副本节点只有27018，因此，候选人只有一个就是27018，开始投票。
- 27019向27018投了一票，27018本身自带一票，因此共两票，超过了“大多数”
- 27019是仲裁节点，没有选举权，27018不向其投票，其票数是0.
最终结果，27018成为主节点。具备读写功能。 在27018写入数据查看。
仲裁节点和主节点故障
先关掉仲裁节点27019， 关掉现在的主节点27018 登录27017后
- 27017仍然是从节点，副本集中没有主节点了，导致此时，副本集是只读状态， 无法写入。
- 为啥不选举了？
- 因为27017的票数，没有获得大多数，即没有大于等于2，它只有默认的一票（优先级 是1）
- 如果要触发选举，随便加入一个成员即可。
- 如果只加入27019仲裁节点成员，则主节点一定是27017，因为没得选了，仲裁节点不参与选举， 但参与投票
- 如果只加入27018节点，会发起选举。因为27017和27018都是两票，则按照谁数据新，谁当主节点。
仲裁节点和从节点故障
先关掉仲裁节点 27019，关掉现在的副本节点 27018
10秒后，27017 主节点自动降级为副本节点。（服务降级）
副本集不可写数据了，已经故障了。
SpringDataMongoDB连接副本集
副本集语法：
1 | mongodb://host1,host2,host3/articledb?connect=replicaSet&slaveOk=true&replicaSet=副本集名字 |
其中：
- slaveOk=true：开启副本节点读的功能，可实现读写分离。
- connect=replicaSet：自动到副本集中选择读写的主机。如果slaveOk是打开的，则实现读写分离。
示例：
连接replica set三台服务器（端口27017，27018，27019），直接连接第一个服务器，无论是replica set一部分或者主服务器或者从服务器，写入操作应用在主服务器并且分布查询到从服务器。
修改配置文件application.yml
1 | spring: |
分片集群-Sharded Cluster
分片概念
分片（sharding）是一种跨多台机器分布数据的方法， MongoDB使用分片来支持具有非常大的数据集 和高吞吐量操作的部署。
换句话说：分片(sharding)是指将数据拆分，将其分散存在不同的机器上的过程。有时也用分区 (partitioning)来表示这个概念。将数据分散到不同的机器上，不需要功能强大的大型计算机就可以储存 更多的数据，处理更多的负载。
具有大型数据集或高吞吐量应用程序的数据库系统可以会挑战单个服务器的容量。例如，高查询率会耗 尽服务器的CPU容量。工作集大小大于系统的RAM会强调磁盘驱动器的I / O容量。
有两种解决系统增长的方法：垂直扩展和水平扩展。
垂直扩展意味着增加单个服务器的容量，例如使用更强大的CPU，添加更多RAM或增加存储空间量。可 用技术的局限性可能会限制单个机器对于给定工作负载而言足够强大。此外，基于云的提供商基于可用 的硬件配置具有硬性上限。结果，垂直缩放有实际的最大值。
水平扩展意味着划分系统数据集并加载多个服务器，添加其他服务器以根据需要增加容量。虽然单个机 器的总体速度或容量可能不高，但每台机器处理整个工作负载的子集，可能提供比单个高速大容量服务 器更高的效率。扩展部署容量只需要根据需要添加额外的服务器，这可能比单个机器的高端硬件的总体 成本更低。权衡是基础架构和部署维护的复杂性增加。
MongoDB支持通过分片进行水平扩展。
分片集群包含的组件
MongoDB分片群集包含以下组件：
- 分片（存储）：每个分片包含分片数据的子集。 每个分片都可以部署为副本集。
- mongos（路由）：mongos充当查询路由器，在客户端应用程序和分片集群之间提供接口。
- config servers（“调度”的配置）：配置服务器存储群集的元数据和配置设置。 从MongoDB 3.4开 始，必须将配置服务器部署为副本集（CSRS）。
下图描述了分片集群中组件的交互：
MongoDB在集合级别对数据进行分片，将集合数据分布在集群中的分片上。
分片集群架构搭建
两个分片节点副本集（3+3）+一个配置节点副本集（3）+两个路由节点（2），共11个服务节点。
其中分片副本集跟上面搭建的副本集操作基本一致。
副本集配置
mongos.conf
1 | systemLog: |
注意：
设置sharding.clusterRole需要mongod实例运行复制。 要将实例部署为副本集成员，请使用 replSetName设置并指定副本集的名称。
其中bindIp需要内网IP。
同一副本集配置基本一致，只需要修改port端口号和日志文件、数据文件路径。
不同副本集需要修改port端口号和日志文件、数据文件路径以及replSetName副本集名称
路由节点的创建和操作
路由节点配置和启动
mongos.conf
1 | systemLog: |
注意：路由节点配置主要为sharding.configDB指定配置节点副本集
启动mongos：
1 | /usr/local/mongodb/bin/mongos -f /mongodb/sharded_cluster/mymongos_27017/mongos.conf |
注意：启动的是bin目录下的mongos
路由节点操作
- 添加分片：
1 | sh.addShard("IP:Port") |
如：
1 | // 添加第一套分片集 |
开启分片功能：
sh.enableSharding("库名")、sh.shardCollection("库名.集合名",{"key":1})集合分片：
sh.shardCollection(namespace, key, unique)
参数：
| Parameter | Type | Description |
|---|---|---|
| namespace | string | 要（分片）共享的目标集合的命名空间，格式： 数据库名.集合名 |
| key | document | 用作分片键的索引规范文档。shard键决定MongoDB如何在 shard之间分发文档。除非集合为空，否则索引必须在shard collection命令之前存在。如果集合为空，则MongoDB在对集合 进行分片之前创建索引，前提是支持分片键的索引不存在。简单 的说：由包含字段和该字段的索引遍历方向的文档组成。 |
| unique | boolean | 当值为true情况下，片键字段上会限制为确保是唯一索引。哈希 策略片键不支持唯一索引。默认是false。 |
对集合进行分片时,你需要选择一个 片键（Shard Key），shard key 是每条记录都必须包含的，且建立了 索引的单个字段或复合字段，MongoDB按照片键将数据划分到不同的 数据块中,并将数据块 均衡地分布到所有分片中。为了按照片键划分数据块，MongoDB使用 基于哈希的分片方式（随机平均分配）或者基于范围的分片方式（数值大小分配） 。
分片规则一：哈希策略
- 对于基于哈希的分片，MongoDB计算一个字段的哈希值，并用这个哈希值来创建数据块。在使用基于哈希分片的系统中，拥有”相近”片键的文档很可能不会存储在同一个数据块中，因此数据的分离性更好一些
使用nickname作为片键，根据其值的哈希值进行数据分片：
1 | sh.shardCollection("articledb.comment",{"nickname":"hashed"}) |
分片规则二：范围策略
- 对于基于范围的分片，MongoDB按照片键的范围把数据分成不同部分。假设有一个数字的片键：想象一个 从负无穷到正无穷的直线，每一个片键的值都在直线上画了一个点。MongoDB把这条直线划分为更短的不 重叠的片段，并称之为数据块，每个数据块包含了片键在一定范围内的数据。在使用片键做范围划分的系统中，拥有”相近”片键的文档很可能存储在同一个数据块中，因此也会存储在同 一个分片中。
如使用作者年龄字段作为片键，按照点赞数的值进行分片：
1 | sh.shardCollection("articledb.author",{"age":1}) |
注意：
1）一个集合只能指定一个片键，否则报错。
2）一旦对一个集合分片，分片键和分片值就不可改变。 如：不能给集合选择不同的分片键、不能更新分片键的值。
3）根据age索引进行分配数据。
基于范围的分片方式与基于哈希的分片方式性能对比：
- 基于范围的分片：
- 优势：提供了高效的范围查询。通过片键的范围，可以轻松确定存储了请求数据的数据块并将请求路由到相应的分片。
- 弊端：可能导致数据分布不均衡。如果片键字段是线性增长的，大部分请求会集中到少数分片，限制了系统的扩展性。
- 基于哈希的分片：
- 优势：保证了数据的均衡分布。哈希值的随机性使数据随机分布在各个数据块和分片中。
- 弊端：牺牲了范围查询的性能。因为哈希的随机性，范围查询难以确定应该请求哪些分片，通常需要请求所有分片来获取结果。
- 推荐的分片策略：
- 一般推荐使用哈希分片。它保证了数据的均衡分布，但可能在范围查询时需要请求所有分片来获取结果。
- 使用
_id作为片键是一个不错的选择。它是必有的，可以使用数据文档_id的哈希作为片键，保证了读写的均匀分布和数据块的细化。
- 总结：
- 范围分片适用于范围查询性能，但可能导致数据分布不均。
- 哈希分片保证了数据均衡分布，但范围查询性能较差。
_id作为片键的哈希分片方案能够保证读写均匀分布，但对于多个文档的查询可能需要命中所有分片。
其他命令：
1 | // 显示集群的详细信息 |
SpringDataMongDB连接分片集群
Java客户端常用的是SpringDataMongoDB，其连接的是mongs路由，配置和单机mongod的配置是一 样的。
多个路由的时候的SpringDataMongoDB的客户端配置参考如下：
1 | spring: |
