一.副本集
1.简介
MongoDB 中的副本集（Replica Set）是一组维护相同数据集的 mongod 服务。 副本集可提供冗余和高可用性，是所有生产部署的基础。
也可以说，副本集类似于有自动故障恢复功能的主从集群。通俗的讲就是用多台机器进行同一数据的异步同步，从而使多台机器拥有同一数据的多个副本，并且当主库当掉时在不需要用户干预的情况下自动切换其他备份服务器做主库。而且还可以利用副本服务器做只读服务器，实现读写分离，提高负载。
2.冗余和数据可用性
复制提供冗余并提高数据可用性。 通过在不同数据库服务器上提供多个数据副本，复制可提供一定级别的容错功能，以防止丢失单个数据库服务器。
在某些情况下，复制可以提供增加的读取性能，因为客户端可以将读取操作发送到不同的服务上， 在不同数据中心维护数据副本可以增加分布式应用程序的数据位置和可用性。 您还可以为专用目的维护其他副本，例如灾难恢复，报告或备份。
3.MongoDB 中的复制
副本集是一组维护相同数据集的 mongod 实例。 副本集包含多个数据承载节点和可选的一个仲裁节点。在承载数据的节点中，一个且仅一个成员被视为主节点，而其他节点被视为次要（从）节点。
主节点接收所有写操作。 副本集只能有一个主要能够确认具有{w：“most”}写入关注的写入; 虽然在某些情况下，另一个 mongod 实例可能暂时认为自己也是主要的。主要记录其操作日志中的数据集的所有更改，即 oplog。
4.主从复制和副本集区别
主从集群和副本集最大的区别就是副本集没有固定的“主节点”；整个集群会选出一个“主节点”，当其挂掉后，又在剩下的从节点中选中其他节点为“主节点”，副本集总有一个活跃点(主、primary)和一个或多个备份节点(从、secondary)。
5.架构图
辅助(副本)节点复制主节点的 oplog 并将操作应用于其数据集，以使辅助节点的数据集反映主节点的数据集。 如果主要人员不在，则符合条件的中学将举行选举以选出新的主要人员。
6.副本集的角色
副本集有两种类型三种角色两种类型:
- 主节点（Primary）类型：数据操作的主要连接点，可读写。
- 次要（辅助、从）节点（Secondaries）类型：数据冗余备份节点，可以读或选举。
三种角色:
- 主要成员（Primary）：主要接收所有写操作。就是主节点。
- 副本成员（Replicate）：从主节点通过复制操作以维护相同的数据集，即备份数据，不可写操作，但可以读操作（但需要配置）。是默认的一种从节点类型。
- 仲裁者（Arbiter）：不保留任何数据的副本，只具有投票选举作用。当然也可以将仲裁服务器维护为副本集的一部分，即副本成员同时也可以是仲裁者。也是一种从节点类型。
7.关于仲裁者的额外说明
您可以将额外的 mongod 实例添加到副本集作为仲裁者。 仲裁者不维护数据集。 仲裁者的目的是通过响应其他副本集成员的心跳和选举请求来维护副本集中的仲裁。 因为它们不存储数据集，所以仲裁器可以是提供副本集仲裁功能的好方法，其资源成本比具有数据集的全功能副本集成员更便宜。
如果您的副本集具有偶数个成员，请添加仲裁者以获得主要选举中的“大多数”投票。 仲裁者不需要专用硬件。仲裁者将永远是仲裁者，而主要人员可能会退出并成为次要人员，而次要人员可能成为选举期间的主要人员。
如果你的副本+主节点的个数是偶数，建议加一个仲裁者，形成奇数，容易满足大多数的投票。如果你的副本+主节点的个数是奇数，可以不加仲裁者。
二.副本集架构
1.架构目标
一主一副本一仲裁
2.创建主节点
建立存放数据和日志的目录
#主节点
mkdir -p /mongodb/replica_sets/myrs_27017/log \ &
mkdir -p /mongodb/replica_sets/myrs_27017/data/db
3.新建或修改配置文件
#新建或修改配置文件：
vim /mongodb/replica_sets/myrs_27017/mongod.conf
systemLog:
#MongoDB发送所有日志输出的目标指定为文件
destination: file
#mongod或mongos应向其发送所有诊断日志记录信息的日志文件的路径
path: "/mongodb/replica_sets/myrs_27017/log/mongod.log"
#当mongos或mongod实例重新启动时，mongos或mongod会将新条目附加到现有日志文件的末尾。
logAppend: true
storage:
#mongod实例存储其数据的目录。 storage.dbPath设置仅适用于mongod。
dbPath: "/mongodb/replica_sets/myrs_27017/data/db"
journal:
#启用或禁用持久性日志以确保数据文件保持有效和可恢复。
enabled: true
processManagement:
#启用在后台运行mongos或mongod进程的守护进程模式。
fork: true
#指定用于保存mongos或mongod进程的进程ID的文件位置，其中mongos或mongod将写入其PID
pidFilePath: "/mongodb/replica_sets/myrs_27017/log/mongod.pid"
net:
#服务实例绑定所有IP，有副作用，副本集初始化的时候，节点名字会自动设置为本地域名，而不是ip
#bindIpAll: true
#服务实例绑定的IP
bindIp: localhost,192.168.0.2
#bindIp #绑定的端口
port: 27017
replication:
#副本集的名称
replSetName: myrs
4.启动服务
/usr/local/mongodb/bin/mongod -f /mongodb/replica_sets/myrs_27017/mongod.conf
5.创建副本节点
建立存放数据和日志的目录
#副本节点
mkdir -p /mongodb/replica_sets/myrs_27018/log \ &
mkdir -p /mongodb/replica_sets/myrs_27018/data/db
6.配置文件
vim /mongodb/replica_sets/myrs_27018/mongod.conf
systemLog:
#MongoDB发送所有日志输出的目标指定为文件
destination: file
#mongod或mongos应向其发送所有诊断日志记录信息的日志文件的路径
path: "/mongodb/replica_sets/myrs_27018/log/mongod.log"
#当mongos或mongod实例重新启动时，mongos或mongod会将新条目附加到现有日志文件的末尾。
logAppend: true
storage:
#mongod实例存储其数据的目录。 storage.dbPath设置仅适用于mongod。
dbPath: "/mongodb/replica_sets/myrs_27018/data/db"
journal:
#启用或禁用持久性日志以确保数据文件保持有效和可恢复。
enabled: true
processManagement:
#启用在后台运行mongos或mongod进程的守护进程模式。
fork: true
#指定用于保存mongos或mongod进程的进程ID的文件位置，其中mongos或mongod将写入其PID
pidFilePath: "/mongodb/replica_sets/myrs_27018/log/mongod.pid"
net:
#服务实例绑定所有IP，有副作用，副本集初始化的时候，节点名字会自动设置为本地域名，而不是ip
#bindIpAll: true
#服务实例绑定的IP
bindIp: localhost,192.168.0.2
#bindIp #绑定的端口
port: 27018
replication:
#副本集的名称
replSetName: myrs
7.启动
/usr/local/mongodb/bin/mongod -f /mongodb/replica_sets/myrs_27018/mongod.conf
8.创建仲裁节点
建立存放数据和日志的目录
#副本节点
mkdir -p /mongodb/replica_sets/myrs_27019/log \ &
mkdir -p /mongodb/replica_sets/myrs_27019/data/db
9.配置文件
vim /mongodb/replica_sets/myrs_27019/mongod.conf
systemLog:
#MongoDB发送所有日志输出的目标指定为文件
destination: file
#mongod或mongos应向其发送所有诊断日志记录信息的日志文件的路径
path: "/mongodb/replica_sets/myrs_27019/log/mongod.log"
#当mongos或mongod实例重新启动时，mongos或mongod会将新条目附加到现有日志文件的末尾。
logAppend: true
storage:
#mongod实例存储其数据的目录。 storage.dbPath设置仅适用于mongod。
dbPath: "/mongodb/replica_sets/myrs_27019/data/db"
journal:
#启用或禁用持久性日志以确保数据文件保持有效和可恢复。
enabled: true
processManagement:
#启用在后台运行mongos或mongod进程的守护进程模式。
fork: true
#指定用于保存mongos或mongod进程的进程ID的文件位置，其中mongos或mongod将写入其PID
pidFilePath: "/mongodb/replica_sets/myrs_27019/log/mongod.pid"
net:
#服务实例绑定所有IP，有副作用，副本集初始化的时候，节点名字会自动设置为本地域名，而不是ip
#bindIpAll: true
#服务实例绑定的IP
bindIp: localhost,192.168.0.2
#bindIp #绑定的端口
port: 27019
replication:
#副本集的名称
replSetName: myrs
10.启动
/usr/local/mongodb/bin/mongod -f /mongodb/replica_sets/myrs_27018/mongod.conf
11.初始化副本集
#连接主节点
/usr/local/mongodb/bin/mongo --host=180.76.159.126 --port=27017
#初始化副本集
rs.initiate()
#查看节点配置
rs.conf()
#查看副本集状态
rs.status()
#添加副本从节点
rs.add("180.76.159.126:27018")
#添加仲裁节点
rs.addArb("180.76.159.126:27019")
12.副本集的读写情况
主节点:可进行读写,有读写权限
从节点:不能读取集合的数据。当前从节点只是一个备份，不是奴隶节点，无法读取数据，写当然更不行。因为默认情况下，从节点是没有读写权限的，可以增加读的权限，但需要进行设置。
设置权限:设置为奴隶节点，允许在从成员上运行读的操作
该命令是 db.getMongo().setSlaveOk() 的简化命令。
#在27018上执行
rs.slaveOk()
#或者
rs.slaveOk(true)
#取消称为奴隶节点
rs.slaveOk(false)
称为奴隶节点后,可以查询,但是不能插入.从而实现了读写分离
仲裁节点:不存放任务业务数据,只存放副本集配置等数据。
13.主节点的选举条件
MongoDB 在副本集中，会自动进行主节点的选举，主节点选举的触发条件:
- 主节点故障
- 主节点网络不可达（默认心跳信息为 10 秒）
- 人工干预（rs.stepDown(600))
14.主节点的选举原则
选举规则是根据票数来决定谁获胜：
- 票数最高，且获得了“大多数”成员的投票支持的节点获胜。“大多数”的定义为：假设复制集内投票成员数量为 N，则大多数为 N/2+1。例如：3 个投票成员，则大多数的值是 2。当复制集内存活成员数量不足大多数时，整个复制集将无法选举出 Primary，复制集将无法提供写服务，处于只读状态。
- 若票数相同，且都获得了“大多数”成员的投票支持的，数据新的节点获胜。数据的新旧是通过操作日志 oplog 来对比的。
在获得票数的时候，优先级（priority）参数影响重大。
可以通过设置优先级（priority）来设置额外票数。优先级即权重，取值为 0-1000，相当于可额外增加 0-1000 的票数，优先级的值越大，就越可能获得多数成员的投票（votes)数。指定较高的值可使成员更有资格成为主要成员，更低的值可使成员更不符合条件。
默认情况下，优先级的值是 1
可以看出，主节点和副本节点的优先级各为 1，即，默认可以认为都已经有了一票。但选举节点，优先级是 0，要注意是，官方说了，选举节点的优先级必须是 0，不能是别的值。即不具备选举权，但具有投票权.
15.修改优先级
#将配置导入cfg变量
cfg=rs.conf()
#修改值
cfg.members[1].priority=2
#重新加载配置
rs.reconfig(cfg)
16.故障测试
关闭从节点27018:因为主节点还在,所以读写没有影响,不会出发选举
关闭主节点27017:从节点和仲裁节点对 27017 的心跳失败，当失败超过 10 秒，此时因为没有主节点了，会自动发起投票。而副本节点只有 27018，因此，候选人只有一个就是 27018，开始投票。27019 向 27018 投了一票，27018 本身自带一票，因此共两票，超过了“大多数”.27019 是仲裁节点，没有选举权，27018 不向其投票，其票数是 0.最终结果，27018 成为主节点。具备读写功能。在 27018 写入数据查看。
再启动 27017 节点，发现 27017 变成了从节点，27018 仍保持主节点。登录 27017 节点，发现是从节点了，数据自动从 27018 同步。从而实现了高可用。
关闭仲裁,关闭主:登录 27017,发现还是从节点,没有变为主节点,是因为存活的副本数量少于一半+1,也就是小于 2,所以不能激活主节点投票,此时,只能提供读服务,不能提供写服务.加入一个节点即可实现读写.
关闭仲裁,关闭从:10 秒后,主节点变为从节点,服务降级,只能读数据,不能写数据.
17.spring 连接连接副本集
mongodb://host1,host2,host3/articledb?connect=replicaSet&slaveOk=true&replicaSet=副本集名字
其中:
- slaveOk=true：开启副本节点读的功能，可实现读写分离。
- connect=replicaSet：自动到副本集中选择读写的主机。如果 slaveOK 是打开的，则实现了读写分离
三.分片集群
1.分片的概念
分片(sharding)是一种跨多台机器分布数据的方法, MongoDB 使用分片来支持具有非常大的数据集和高吞吐量操作的部署。
换句话说:分片(sharding)是指将数据拆分,将其分散存在不同的机器上的过程。有时也用分区(partitioning)来表示这个概念。将数据分散到不同的机器上,不需要功能强大的大型计算机就可以储存更多的数据,处理更多的负载。
具有大型数据集或高吞吐量应用程序的数据库系统可以会挑战单个服务器的容量。例如,高查询率会耗尽服务器的 CPU 容量。工作集大小大于系统的 RAM 会强调磁盘驱动器的 I/O 容量。
2.分片存在的意义
有两种解决系统增长的方法：垂直扩展和水平扩展。
垂直扩展意味着增加单个服务器的容量,例如使用更强大的 CPU,添加更多 RAM 或增加存储空间量。可用技术的局限性可能会限制单个机器对于给定工作负载而言足够强大。此外,基于云的提供商基于可用的硬件配置具有硬性上限。结果,垂直缩放有实际的最大值。
水平扩展意味着划分系统数据集并加载多个服务器，添加其他服务器以根据需要增加容量。虽然单个机器的总体速度或容量可能不高，但每台机器处理整个工作负载的子集，可能提供比单个高速大容量服务器更高的效率。扩展部署容量只需要根据需要添加额外的服务器，这可能比单个机器的高端硬件的总体成本更低。权衡是基础架构和部署维护的复杂性增加。
MongoDB 支持通过分片进行水平扩展。
3.分片组件
MongoDB 分片群集包含以下组件:
- 分片(存储):每个分片包含分片数据的子集。每个分片都可以部署为副本集。
- mongos(路由):mongos 充当查询路由器，在客户端应用程序和分片集群之间提供接口。
- config servers(“调度”的配置):配置服务器存储群集的元数据和配置设置。从 MongoDB3.4 开始，必须将配置服务器部署为副本集(CSRS).
下图描述了分片集群中组件的交互:
MongoDB 在集合级别对数据进行分片，将集合数据分布在集群中的分片上。
4.分片架构目标
两个分片节点副本集（3+3）+一个配置节点副本集（3）+两个路由节点（2），共 11 个服务节点。
5.初始化副本集
#登录分片主节点
/usr/local/mongodb/bin/mongo --host 180.76.159.126 --port 27318
#初始化副本集
rs.initiate()
#查看状态
rs.status()
#查看配置
rs.conf()
#添加副节点
rs.add("180.76.159.126:27418")
#添加仲裁节点
rs.addArb("180.76.159.126:27518")
#再次查看
rs.status()
rs.conf()
6.模拟路由读写数据
#登录路由节点
/usr/local/mongodb/bin/mongo --host 180.76.159.126 --port 27017
#添加分片节点
sh.addShard("myshardrs01/192.168.0.2:27018,180.76.159.126:27118,180.76.159.126:2 7218")
sh.addShard("myshardrs02/192.168.0.2:27318,180.76.159.126:27418,180.76.159.126:2 7518")
#开启分片功能
sh.enableSharding("articledb")
#查看集群详细信息
db.printShardingStatus()
#查看均衡器的状态
sh.getBalancerState()
#查看单个集合的完整情况
db.comment.stats()
#移除分片
use admin
db.runCommand( { removeShard: "myshardrs02" } )
7.分片规则
#哈希策略
sh.shardCollection("articledb.comment",{"nickname":"hashed"})
#范围策略
sh.shardCollection("articledb.author",{"age":1})
四.安全认证
1.开启安全认证
默认情况下，MongoDB 实例启动运行时是没有启用用户访问权限控制的，也就是说，在实例本机服务器上都可以随意连接到实例进行各种操作，MongoDB 不会对连接客户端进行用户验证，这是非常危险的。mongodb 官网上说，为了能保障 mongodb 的安全可以做以下几个步骤:
- 使用新的端口，默认的 27017 端口如果一旦知道了 ip 就能连接上，不太安全。
- 设置 mongodb 的网络环境，最好将 mongodb 部署到公司服务器内网，这样外网是访问不到的。公司内部访问使用 vpn 等。
- 开启安全认证。认证要同时设置服务器之间的内部认证方式,同时要设置客户端连接到集群的账号密码认证方式。
为了强制开启用户访问控制(用户验证)，则需要在 MongoDB 实例启动时使用选项 --auth 或在指定启动配置文件中添加选项 auth=true.
2.查询角色权限
#查询所有角色权限(仅用户自定义角色)
db.runCommand({ rolesInfo: 1 })
#查询所有角色权限(包含内置角色)
db.runCommand({ rolesInfo: 1, showBuiltinRoles: true })
#查询当前数据库中的某角色的权限
db.runCommand({ rolesInfo: "<rolename>" })
3.角色说明
常用的内置角色:
- 数据库用户角色: read、readWrite;
- 所有数据库用户角色: readAnyDatabase、readWriteAnyDatabase、userAdminAnyDatabase、 dbAdminAnyDatabase
- 数据库管理角色: dbAdmin、dbOwner、userAdmin;
- 集群管理角色: clusterAdmin、clusterlManager、clusterlMonitor、hostManager;
- 备份恢复角色: backup、restore;
- 超级用户角色: root
- 内部角色: system
4.赋权
#登录
/usr/local/mongodb/bin/mongo --host 180.76.159.126 --port 27017
#切换到admin库
use admin
#创建用户,创建系统超级用户 myroot,设置密码123456，设置角色root
db.createUser({user:"myroot",pwd:"123456",roles:["root"]})
#创建专门用来管理admin库的账号myadmin，只用来作为用户权限的管理
db.createUser({user:"myadmin",pwd:"123456"
,roles[{role:"userAdminAnyDatabase",db:"admin"}]})
#查看已经创建了的用户的情况
db.system.users.find()
#删除用户
db.dropUser("myadmin")
#查找用户
db.system.users.find()
#修改密码
db.changeUserPassword("myroot", "123456")
创建普通用户:
#创建(切换)将来要操作的数据库articledb
use articledb
#创建用户，拥有articledb数据库的读写权限readWrite，密码是123456
db.createUser({user: "bobo", pwd: "123456", roles: [{ role: "readWrite", db: "articledb" }]})
5.测试
#切换到admin
useadmin
#密码输错
db.auth("myroot","12345")
Error:Authenticationfailed.
#密码正确
db.auth("myroot","123456")
1
