1. 副本集-Replica Sets
1.1 简介
MongoDB中的副本集（Replica Set）是一组维护相同数据集的mongod服务。 副本集可提供冗余和高可用性，是所有生产部署的基础。也可以说，副本集类似于有自动故障恢复功能的主从集群。通俗的讲就是用多台机器进行同一数据的异步同步，从而使多台机器拥有同一数据的多个副本，并且当主库当掉时在不需要用户干预的情况下自动切换其他备份服务器做主库。而且还可以利用副本服务器做只读服务器，实现读写分离，提高负载。
（1）冗余和数据可用性
复制提供冗余并提高数据可用性。 通过在不同数据库服务器上提供多个数据副本，复制可提供一定级别的容错功能，以防止丢失单个数据库服务器。在某些情况下，复制可以提供增加的读取性能，因为客户端可以将读取操作发送到不同的服务上， 在不同数据中心维护数据副本可以增加分布式应用程序的数据位置和可用性。 还可以为专用目的维护其他副本，例如灾难恢复，备份。
（2）MongoDB中的复制
副本集是一组维护相同数据集的mongod实例。 副本集包含多个数据承载节点和可选的一个仲裁节点。在承载数据的节点中，一个且仅一个成员被视为主节点，而其他节点被视为次要（从）节点。主节点接收所有写操作。 副本集只能有一个主要能够确认具有写入权限; 虽然在某些情况下，另一个mongod实例可能暂时认为自己也是主要的。主要记录其操作日志中的数据集的所有更改，即oplog。辅助(副本)节点复制主节点的oplog并将操作应用于其数据集，以使辅助节点的数据集反映主节点的数据集。 如果主节点不存在，则从符合条件的从节点将举行选举以选出新的主节点。
（3）主从复制和副本集区别
主从集群和副本集最大的区别就是副本集没有固定的“主节点”；整个集群会选出一个“主节点”，当其挂掉后，又在剩下的从节点中选中其他节点为“主节点”，副本集总有一个活跃点(主、primary)和一个或多个备份节点(从、secondary)。
1.2 副本集的三个角色
副本集有两种类型三种角色
两种类型：
主节点（Primary）类型：数据操作的主要连接点，可读写。
次要（辅助、从）节点（Secondaries）类型：数据冗余备份节点，可以读或选举。
三种角色：
主要成员（Primary）：主要接收所有写操作。就是主节点。
副本成员（Replicate）：从主节点通过复制操作以维护相同的数据集，即备份数据，不可写操作，但可以读操作（但需要配置）。是默认的一种从节点类型。
仲裁者（Arbiter）：不保留任何数据的副本，只具有投票选举作用。当然也可以将仲裁服务器维护为副本集的一部分，即副本成员同时也可以是仲裁者。也是一种从节点类型。
关于仲裁者的额外说明：
您可以将额外的mongod实例添加到副本集作为仲裁者。 仲裁者不维护数据集。 仲裁者的目的是通过响应其他副本集成员的心跳和选举请求来维护副本集中的仲裁。 因为它们不存储数据集，所以仲裁器可以是提供副本集仲裁功能的好方法，其资源成本比具有数据集的全功能副本集成员更便宜。如果您的副本集具有偶数个成员，请添加仲裁者以获得主要选举中的“大多数”投票。 仲裁者不需要专用硬件。仲裁者将永远是仲裁者，而主要人员可能会退出并成为次要人员，而次要人员可能成为选举期间的主要人员。
如果你的副本+主节点的个数是偶数，建议加一个仲裁者，形成奇数，容易满足大多数的投票。
如果你的副本+主节点的个数是奇数，可以不加仲裁者。
1.3 副本集架构
1.4 副本集架构搭建
1、创建存放数据和日志的目录 data、log
2、新建或修改配置文件mongod.conf
3、启动服务节点 mongod -f mongod.conf
4、rs.initiate() 初始化副本集和主结点，rs.conf() 副本集配置的查看命令，本质是查询的是system.replset 的表中的数据。rs.status()查看副本集状态
5、rs.add(host, arbiterOnly) 添加副本从节点
6、rs.addArb(host) 添加一个仲裁节点
7、从结点（默认是没有读权限的）执行rs.slaveOk() 设置从节点可读 rs.slaveOk(false) 取消读
1.5 主节点的选举原则
MongoDB在副本集中，会自动进行主节点的选举，主节点选举的触发条件：
1） 主节点故障
2） 主节点网络不可达（默认心跳信息为10秒）
3） 人工干预（rs.stepDown(600)）
一旦触发选举，就要根据一定规则来选主节点。
选举规则是根据票数来决定谁获胜：
票数最高，且获得了“大多数”成员的投票支持的节点获胜。“大多数”的定义为：假设复制集内投票成员数量为N，则大多数为 N/2 + 1。例如：3个投票成员，则大多数的值是2。当复制集内存活成员数量不足大多数时，整个复制集将无法选举出Primary，复制集将无法提供写服务，处于只读状态。若票数相同，且都获得了“大多数”成员的投票支持的，数据新的节点获胜。数据的新旧是通过操作日志oplog来对比的。在获得票数的时候，优先级（priority）参数影响重大。可以通过设置优先级（priority）来设置额外票数。优先级即权重，取值为0-1000，相当于可额外增加0-1000的票数，优先级的值越大，就越可能获得多数成员的投票（votes）数。指定较高的值可使成员更有资格成为主要成员，更低的值可使成员更不符合条件。
1.5 故障测试-一主一副本-仲裁
主节点故障，副本成为主节点。
主节点-仲裁点故障，副本选举不了，只有1/3成员。
副本和仲裁点故障，主会服务降级。只具备读权限。
2. 分片集群-Sharded Cluster
2.1 分片概念
分片（sharding）是一种跨多台机器分布数据的方法， MongoDB使用分片来支持具有非常大的数据集和高吞吐量操作的部署。换句话说：分片(sharding)是指将数据拆分，将其分散存在不同的机器上的过程。有时也用分区(partitioning)来表示这个概念。将数据分散到不同的机器上，不需要功能强大的大型计算机就可以储存更多的数据，处理更多的负载。具有大型数据集或高吞吐量应用程序的数据库系统可以会挑战单个服务器的容量。例如，高查询率会耗尽服务器的CPU容量。工作集大小大于系统的RAM会强调磁盘驱动器的I / O容量。
MongoDB分片群集包含以下组件：
分片（存储）：每个分片包含分片数据的子集。 每个分片都可以部署为副本集。
mongos（路由）：mongos充当查询路由器，在客户端应用程序和分片集群之间提供接口。
config servers（“调度”的配置）：配置服务器存储群集的元数据和配置设置。 从MongoDB 3.4开始，必须将配置服务器部署为副本集（CSRS）。
路由结点：sh.addShard(“IP:Port”)
移出分片db.runCommand( { removeShard: “myshardrs02” } )
开启分片功能：sh.enableSharding(“库名”)、sh.shardCollection(“库名.集合名”,{“key”:1})
对集合分片，你必须使用 sh.shardCollection() 方法指定集合和分片键。
sh.shardCollection(namespace, key, unique)
分片规则一：哈希策略
对于 基于哈希的分片 ,MongoDB计算一个字段的哈希值,并用这个哈希值来创建数据块.在使用基于哈希分片的系统中,拥有”相近”片键的文档 很可能不会 存储在同一个数据块中,因此数据的分离性更好一些.
分片规则二：范围策略
对于 基于范围的分片 ,MongoDB按照片键的范围把数据分成不同部分.假设有一个数字的片键:想象一个从负无穷到正无穷的直线,每一个片键的值都在直线上画了一个点.MongoDB把这条直线划分为更短的不重叠的片段,并称之为 数据块 ,每个数据块包含了片键在一定范围内的数据.
注意的是：
1）一个集合只能指定一个片键，否则报错。
2）一旦对一个集合分片，分片键和分片值就不可改变。 如：不能给集合选择不同的分片键、不能更新分片键的值。
基于范围的分片方式与基于哈希的分片方式性能对比：
基于范围的分片方式提供了更高效的范围查询,给定一个片键的范围,分发路由可以很简单地确定哪个数据块存储了请求需要的数据,并将请求转发到相应的分片中.不过,基于范围的分片会导致数据在不同分片上的不均衡,有时候,带来的消极作用会大于查询性能的积极作用.比如,如果片键所在的字段是线性增长的,一定时间内的所有请求都会落到某个固定的数据块中,最终导致分布在同一个分片中.在这种情况下,一小部分分片承载了集群大部分的数据,系统并不能很好地进行扩展.
与此相比,基于哈希的分片方式以范围查询性能的损失为代价,保证了集群中数据的均衡.哈希值的随机性使数据随机分布在每个数据块中,因此也随机分布在不同分片中.但是也正由于随机性,一个范围查询很难确定应该请求哪些分片,通常为了返回需要的结果,需要请求所有分片.
如无特殊情况，一般推荐使用 Hash Sharding。而使用_id 作为片键是一个不错的选择，因为它是必有的，你可以使用数据文档_id 的哈希作为片键。这个方案能够是的读和写都能够平均分布，并且它能够保证每个文档都有不同的片键所以数据块能够很精细。似乎还是不够完美，因为这样的话对多个文档的查询必将命中所有的分片。虽说如此，这也是一种比较好的方案了。理想化的 shard key 可以让 documents 均匀地在集群中分布：
3. 安全认证
3.1 MongoDB的用户和角色权限简介
mongodb官网上说，为了能保障mongodb的安全可以做以下几个步骤：
1）使用新的端口，默认的27017端口如果一旦知道了ip就能连接上，不太安全。
2）设置mongodb的网络环境，最好将mongodb部署到公司服务器内网，这样外网是访问不到的。公司内部访问使用vpn等。
3）开启安全认证。认证要同时设置服务器之间的内部认证方式，同时要设置客户端连接到集群的账号密码认证方式。为了强制开启用户访问控制(用户验证)，则需要在MongoDB实例启动时使用选项—auth 或在指定启动配置文件中添加选项auth=true 。
在开始之前需要了解一下概念
1）启用访问控制：
MongoDB使用的是基于角色的访问控制(Role-Based Access Control,RBAC)来管理用户对实例的访问。通过对用户授予一个或多个角色来控制用户访问数据库资源的权限和数据库操作的权限，在对用户分配角色之前，用户无法访问实例。在实例启动时添加选项—auth 或指定启动配置文件中添加选项auth=true 。
2）角色：
在MongoDB中通过角色对用户授予相应数据库资源的操作权限，每个角色当中的权限可以显式指定，也可以通过继承其他角色的权限，或者两都都存在的权限。
3）权限：
权限由指定的数据库资源(resource)以及允许在指定资源上进行的操作(action)组成。
1. 资源(resource)包括：数据库、集合、部分集合和集群；
2. 操作(action)包括：对资源进行的增、删、改、查(CRUD)操作。
在角色定义时可以包含一个或多个已存在的角色，新创建的角色会继承包含的角色所有的权限。在同一个数据库中，新创建角色可以继承其他角色的权限，在admin 数据库中创建的角色可以继承在其它任意数据库中角色的权限。
// 查询所有角色权限(仅用户自定义角色)
> db.runCommand({ rolesInfo: 1 })
常用的内置角色：
数据库用户角色：read、readWrite;
所有数据库用户角色：readAnyDatabase、readWriteAnyDatabase、
userAdminAnyDatabase、dbAdminAnyDatabase
数据库管理角色：dbAdmin、dbOwner、userAdmin；
集群管理角色：clusterAdmin、clusterManager、clusterMonitor、hostManager；
备份恢复角色：backup、restore；
超级用户角色：root
内部角色：system
3.2 权限验证
1）参数方式
在启动时指定参数—auth ，如：/usr/local/mongodb/bin/mongod -f /mongodb/single/mongod.conf —auth
2）配置文件方式
在mongod.conf配置文件中加入：
vim /mongodb/single/mongod.conf
security:
#开启授权认证
authorization: enabled
启动时可不加—auth 参数：
/usr/local/mongodb/bin/mongod -f /mongodb/single/mongod.conf
对副本集执行访问控制需要配置两个方面:
1）副本集和共享集群的各个节点成员之间使用内部身份验证，可以使用密钥文件或x.509证书。密钥文件比较简单，本文使用密钥文件，官方推荐如果是测试环境可以使用密钥文件，但是正式环境，官方推荐x.509证书。原理就是，集群中每一个实例彼此连接的时候都检验彼此使用的证书的内容是否相同。只有证书相同的实例彼此才可以访问
2）使用客户端连接到mongodb集群时，开启访问授权。对于集群外部的访问。如通过可视化客户端，或者通过代码连接的时候，需要开启授权。在keyfile身份验证中，副本集中的每个mongod实例都使用keyfile的内容作为共享密码，只有具有正确密钥文件的mongod或者mongos实例可以连接到副本集。密钥文件的内容必须在6到1024个字符之间，并且在unix/linux系统中文件所有者必须有对文件至少有读的权限。
1、创建副本集认证的key文件
第一步：生成一个key文件到当前文件夹中。可以使用任何方法生成密钥文件。例如，使用openssl生成密码文件，然后使用chmod来更改文件权限，仅为文件所有者提供读取权限
2、修改配置文件指定keyfile
分别编辑几个服务的mongod.conf文件，添加相关内容：mongod.conf
security:
#KeyFile鉴权文件
keyFile: /mongodb/replica_sets/xxx/mongo.keyfile
#开启认证方式运行
authorization: enabled
注意事项：
在分片集群中配置mongos比mongod少了authorization：enabled的配置。原因是，副本集加分片的安全认证需要配置两方面的，副本集各个节点之间使用内部身份验证，用于内部各个mongo实例的通信，只有相同keyfile才能相互访问。所以都要开启keyFile。
然而对于所有的mongod，才是真正的保存数据的分片。mongos只做路由，不保存数据。所以所有的mongod开启访问数据的授权authorization:enabled。这样用户只有账号密码正确才能访问到数据。
若有收获，就点个赞吧
0 人点赞
