1. 副本集-Replica Sets
1.1 简介
MongoDB中的副本集（Replica Set）是一组维护相同数据集的mongod服务。 副本集可提供冗余和高可用性，是所有生产部署的基础。
也可以说，副本集类似于有自动故障恢复功能的主从集群。通俗的讲就是用多台机器进行同一数据的异步同步，从而使多台机器拥有同一数据的多个副本，并且当主库当掉时在不需要用户干预的情况下自动切换其他备份服务器做主库。而且还可以利用副本服务器做只读服务器，实现读写分离，提高负载。
（1）冗余和数据可用性
复制提供冗余并提高数据可用性。 通过在不同数据库服务器上提供多个数据副本，复制可提供一定级别的容错功能，以防止丢失单个数据库服务器。
在某些情况下，复制可以提供增加的读取性能，因为客户端可以将读取操作发送到不同的服务上， 在不同数据中心维护数据副本可以增加分布式应用程序的数据位置和可用性。 您还可以为专用目的维护其他副本，例如灾难恢复，报告或备份。
（2）MongoDB中的复制
副本集是一组维护相同数据集的mongod实例。 副本集包含多个数据承载节点和可选的一个仲裁节点。在承载数据的节点中，一个且仅一个成员被视为主节点，而其他节点被视为次要（从）节点。
主节点接收所有写操作。 副本集只能有一个主要能够确认具有{w：“most”}写入关注的写入; 虽然在某些情况下，另一个mongod实例可能暂时认为自己也是主要的。主要记录其操作日志中的数据集的所有更改，即oplog。
辅助(副本)节点复制主节点的oplog并将操作应用于其数据集，以使辅助节点的数据集反映主节点的数据集。 如果主要人员不在，则符合条件的中学将举行选举以选出新的主要人员。
（3）主从复制和副本集区别
主从集群和副本集最大的区别就是副本集没有固定的“主节点”；整个集群会选出一个“主节点”，当其挂掉后，又在剩下的从节点中选中其他节点为“主节点”，副本集总有一个活跃点(主、primary)和一个或多个备份节点(从、secondary)。
1.2 副本集的三个角色
副本集有两种类型三种角色
两种类型：
- 主节点（ Primary）类型：数据操作的主要连接点，可读写。
- 次要（辅助、从）节点（ Secondaries）类型：数据冗余备份节点，可以读或选举。
三种角色：
- 主要成员（Primary）：主要接收所有写操作。就是主节点。
- 副本成员（Replicate）：从主节点通过复制操作以维护相同的数据集，即备份数据，不可写操作，但可以读操作（但需要配置）。是默认的一种从节点类型。
- 仲裁者（ Arbiter）：不保留任何数据的副本，只具有投票选举作用。当然也可以将仲裁服务器维护为副本集的一部分，即副本成员同时也可以是仲裁者。也是一种从节点类型。
关于仲裁者的额外说明：
您可以将额外的mongod实例添加到副本集作为仲裁者。 仲裁者不维护数据集。 仲裁者的目的是通过响应其他副本集成员的心跳和选举请求来维护副本集中的仲裁。 因为它们不存储数据集，所以仲裁器可以是提供副本集仲裁功能的好方法，其资源成本比具有数据集的全功能副本集成员更便宜。
如果您的副本集具有偶数个成员，请添加仲裁者以获得主要选举中的“大多数”投票。 仲裁者不需要专用硬件。
仲裁者将永远是仲裁者，而主要人员可能会退出并成为次要人员，而次要人员可能成为选举期间的主要人员。
如果你的副本+主节点的个数是偶数，建议加一个仲裁者，形成奇数，容易满足大多数的投票。
如果你的副本+主节点的个数是奇数，可以不加仲裁者。
1.3 副本集架构目标
一主一副本一仲裁
1.4 副本集的创建
1.4.1 第一步：创建主节点
建立存放数据和日志的目录
1 | #-----------myrs |
新建或修改配置文件：
1 | vim /mongodb/replica_sets/myrs_27017/mongod.conf |
myrs_27017 ：
1 | systemLog: |
启动节点服务：
1 | [root@bobohost replica_sets]# /usr/local/mongodb/bin/mongod -f /mongodb/replica_sets/myrs_27017/mongod.conf |
1.4.2 第二步：创建副本节点
建立存放数据和日志的目录
1 | #-----------myrs |
新建或修改配置文件：
1 | vim /mongodb/replica_sets/myrs_27018/mongod.conf |
myrs_27018 ：
1 | systemLog: |
启动节点服务：
1 | [root@bobohost replica_sets]# /usr/local/mongodb/bin/mongod -f /mongodb/replica_sets/myrs_27018/mongod.conf |
1.4.3 第三步：创建仲裁节点
建立存放数据和日志的目录
1 | #-----------myrs |
新建或修改配置文件：
1 | vim /mongodb/replica_sets/myrs_27019/mongod.conf |
myrs_27019 ：
1 | systemLog: |
启动节点服务：
1 | [root@bobohost replica_sets]# /usr/local/mongodb/bin/mongod -f /mongodb/replica_sets/myrs_27019/mongod.conf |
1.4.4 第四步：初始化配置副本集和主节点
使用客户端命令连接任意一个节点，但这里尽量要连接主节点(27017节点)：
1 | /usr/local/mongodb/bin/mongo --host=180.76.159.126 --port=27017 |
结果，连接上之后，很多命令无法使用，，比如 show dbs 等，必须初始化副本集才行
准备初始化新的副本集：
语法：
1 | rs.initiate(configuration) |
【示例】
使用默认的配置来初始化副本集：
1 | rs.initiate() |
执行结果：
1 | > rs.initiate() |
提示：
- “ok”的值为1，说明创建成功。
- 命令行提示符发生变化，变成了一个从节点角色，此时默认不能读写。稍等片刻，回车，变成主节点。
1.4.5 第五步：查看副本集的配置内容
返回包含当前副本集配置的文档。
语法：
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.4.6 第六步：查看副本集状态
检查副本集状态。
说明：
返回包含状态信息的文档。此输出使用从副本集的其他成员发送的心跳包中获得的数据反映副本集的当前状态。
语法：
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.4.7 第七步：添加副本从节点
在主节点添加从节点，将其他成员加入到副本集
语法：
1 | rs.add(host, arbiterOnly) |
选项：
| Parameter | Type | Description |
|---|---|---|
| host | string or document | 要添加到副本集的新成员。 指定为字符串或配置文档：1）如果是一个字符串，则需要指定新成员的主机名和可选的端口号；2）如果是一个文档，请指定在members数组中找到的副本集成员配置文档。 您必须在成员配置文档中指定主机字段。有关文档配置字段的说明，详见下方文档：“主机成员的配置文档” |
| arbiterOnly | boolean | 可选的。 仅在 |
主机成员的配置文档：
1 | { |
【示例】
将27018的副本节点添加到副本集中：
1 | myrs:PRIMARY> rs.add("180.76.159.126:27018") |
说明：
- “ok” : 1 ：说明添加成功。
查看副本集状态：
1 | myrs:PRIMARY> rs.status() |
说明：
"name" : "180.76.159.126:27018"是第二个节点的名字，其角色是"stateStr" : "SECONDARY"
1.4.8 第八步：添加仲裁从节点
添加一个仲裁节点到副本集
语法：
1 | rs.addArb(host) |
将27019的仲裁节点添加到副本集中：
1 | myrs:PRIMARY> rs.addArb("180.76.159.126:27019") |
说明：
"ok" : 1：说明添加成功。
查看副本集状态：
1 | myrs:PRIMARY> rs.status() |
说明：
"name" : "180.76.159.126:27019"是第二个节点的名字，其角色是"stateStr" : "ARBITER"
1.5 副本集的数据读写操作
目标：测试三个不同角色的节点的数据读写情况
登录主节点27017，写入和读取数据：
1 | [root@bobohost ~]# /usr/local/mongodb/bin/mongo --host 180.76.159.126 --port 27017 |
登录从节点27018
1 | [root@bobohost ~]# /usr/local/mongodb/bin/mongo --host 180.76.159.126 --port 27018 |
发现，不能读取集合的数据。当前从节点只是一个备份，不是奴隶节点，无法读取数据，写当然更不行。
因为默认情况下，从节点是没有读写权限的，可以增加读的权限，但需要进行设置
设置读操作权限：
说明：
设置为奴隶节点，允许在从成员上运行读的操作
语法：
1 | rs.slaveOk() |
提示：
该命令是 db.getMongo().setSlaveOk() 的简化命令。
【示例】
在27018上设置作为奴隶节点权限，具备读权限：
1 | rs:SECONDARY> rs.slaveOk() |
此时，在执行查询命令，运行成功！
但仍然不允许插入。
1 | myrs:SECONDARY> rs.slaveOk() |
现在可实现了读写分离，让主插入数据，让从来读取数据。
如果要取消作为奴隶节点的读权限：
1 | myrs:SECONDARY> rs.slaveOk(false) |
仲裁者节点，不存放任何业务数据的，可以登录查看
1 | [root@bobohost ~]# /usr/local/mongodb/bin/mongo --host 180.76.159.126 --port 27019 |
发现，只存放副本集配置等数据。
1.6 主节点的选举原则
MongoDB在副本集中，会自动进行主节点的选举，主节点选举的触发条件：
- 主节点故障
- 主节点网络不可达（默认心跳信息为10秒）
- 人工干预（rs.stepDown(600)）
一旦触发选举，就要根据一定规则来选主节点。
选举规则是根据票数来决定谁获胜：
票数最高，且获得了 “大多数”成员的投票支持的节点获胜。
“大多数”的定义为：假设复制集内投票成员数量为N，则大多数为 N/2 + 1。例如：3个投票成员，则大多数的值是2。当复制集内存活成员数量不足大多数时，整个复制集将无法选举出Primary，复制集将无法提供写服务，处于只读状态。
若票数相同，且都获得了 “大多数”成员的投票支持的，数据新的节点获胜。
数据的新旧是通过操作日志oplog来对比的。
在获得票数的时候，优先级（priority）参数影响重大。
可以通过设置优先级（priority）来设置额外票数。优先级即权重，取值为0-1000，相当于可额外增加0-1000的票数，优先级的值越大，就越可能获得多数成员的投票（votes）数。指定较高的值可使成员更有资格成为主要成员，更低的值可使成员更不符合条件。
默认情况下，优先级的值是1
1 | myrs:PRIMARY> rs.conf() |
可以看出，主节点和副本节点的优先级各为 1，即，默认可以认为都已经有了一票。但选举节点，优先级是0，（要注意是，官方说了，选举节点的优先级必须是0，不能是别的值。即不具备选举权，但具有投票权）
【了解】修改优先级
比如，下面提升从节点的优先级：
1）先将配置导入cfg变量
1 | myrs:SECONDARY> cfg=rs.conf() |
2 ）然后修改值（ID号默认从0开始）
1 | myrs:SECONDARY> cfg.members[1].priority=2 |
3 ）重新加载配置
1 | myrs:SECONDARY> rs.reconfig(cfg) |
稍等片刻会重新开始选举。
1.7 故障测试
1.7.1 副本节点故障测试
关闭27018副本节点：
发现，主节点和仲裁节点对27018的心跳失败。因为主节点还在，因此，没有触发投票选举。
如果此时，在主节点写入数据。
1 | db.comment.insert({"_id":"1","articleid":"100001","content":"我们不应该把清晨浪费在手机上，健康很重要，一杯温水幸福你我他。","userid":"1002","nickname":"相忘于江湖","createdatetime":new Date("2019-08-05T22:08:15.522Z"),"likenum":NumberInt(1000),"state":"1"}) |
再启动从节点，会发现，主节点写入的数据，会自动同步给从节点。
1.7.2 主节点故障测试
关闭27017节点
发现，从节点和仲裁节点对27017的心跳失败，当失败超过10秒，此时因为没有主节点了，会自动发起投票。
而副本节点只有27018，因此，候选人只有一个就是27018，开始投票。
27019向27018投了一票，27018本身自带一票，因此共两票，超过了“大多数”
27019是仲裁节点，没有选举权，27018不向其投票，其票数是0.
最终结果，27018成为主节点。具备读写功能。
在27018写入数据查看。
1 | db.comment.insert({"_id":"2","articleid":"100001","content":"我夏天空腹喝凉开水，冬天喝温开水","userid":"1005","nickname":"伊人憔悴","createdatetime":new Date("2019-08-05T23:58:51.485Z"),"likenum":NumberInt(888),"state":"1"}) |
再启动 27017节点，发现27017变成了从节点，27018仍保持主节点。
登录27017节点，发现是从节点了，数据自动从27018同步。
从而实现了高可用。
1.7.3 仲裁节点和主节点故障
先关掉仲裁节点27019，
关掉现在的主节点27018
登录27017后，发现，27017仍然是从节点，副本集中没有主节点了，导致此时，副本集是只读状态，无法写入。
为啥不选举了？因为27017的票数，没有获得大多数，即没有大于等于2，它只有默认的一票（优先级是1）
如果要触发选举，随便加入一个成员即可。
- 如果只加入 27019仲裁节点成员，则主节点一定是27017，因为没得选了，仲裁节点不参与选举，但参与投票。（不演示）
- 如果只加入 27018节点，会发起选举。因为27017和27018都是两票，则按照谁数据新，谁当主节点。
1.7.4 仲裁节点和从节点故障
先关掉仲裁节点27019，
关掉现在的副本节点27018
10秒后，27017主节点自动降级为副本节点。（服务降级）
副本集不可写数据了，已经故障了。
1.8 Compass 连接副本集
compass连接：
1.9 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: |
注意：
主机必须是副本集中所有的主机，包括主节点、副本节点、仲裁节点。
SpringDataMongoDB自动实现了读写分离：
写操作时，只打开主节点连接；读操作是，同时打开主节点和从节点连接，但使用从节点获取数据。
完整的连接字符串的参考（了解）：
MongoDB客户端连接语法：
1 | mongodb://[username:password@]host1[:port1][,host2[:port2],...[,hostN[:portN]]][/[database][?options]] |
- mongodb:// 这是固定的格式，必须要指定。
- username:password@ 可选项，如果设置，在连接数据库服务器之后，驱动都会尝试登陆这个数据库
- host1 必须的指定至少一个host, host1 是这个URI唯一要填写的。它指定了要连接服务器的地址。如果要连接复制集，请指定多个主机地址。
- portX 可选的指定端口，如果不填，默认为27017
- /database 如果指定username:password@，连接并验证登陆指定数据库。若不指定，默认打开test 数据库。
- ?options 是连接选项。如果不使用/database，则前面需要加上/。所有连接选项都是键值对name=value，键值对之间通过&或;（分号）隔开
标准的连接格式包含了多个选项(options)，如下所示：
| 选项 | 描述 |
|---|---|
| replicaSet=name | 验证replica set的名称。 Impliesconnect=replicaSet. |
| slaveOk=true|false | true:在connect=direct模式下，驱动会连接第一台机器，即使这台服务器不是主。在connect=replicaSet模式下，驱动会发送所有的写请求到主并且把读取操作分布在其他从服务器。false: 在connect=direct模式下，驱动会自动找寻主服务器. 在connect=replicaSet 模式下，驱动仅仅连接主服务器，并且所有的读写命令都连接到主服务器。 |
| safe=true|false | true: 在执行更新操作之后，驱动都会发送getLastError命令来确保更新成功。(还要参考 wtimeoutMS).false: 在每次更新之后，驱动不会发送getLastError来确保更新成功。 |
| w=n | 驱动添加 { w : n } 到getLastError命令. 应用于safe=true。 |
| wtimeoutMS=ms | 驱动添加 { wtimeout : ms } 到 getlasterror 命令. 应用于 safe=true. |
| fsync=true|false | true: 驱动添加 { fsync : true } 到 getlasterror 命令.应用于safe=true.false: 驱动不会添加到getLastError命令中。 |
| journal=true|false | 如果设置为 true, 同步到 journal (在提交到数据库前写入到实体中).应用于 safe=true |
| connectTimeoutMS=ms | 可以打开连接的时间 |
| socketTimeoutMS=ms | 发送和接受sockets的时间 |
2. 分片集群-Sharded Cluster
2.1 分片概念
分片（sharding）是一种跨多台机器分布数据的方法， MongoDB使用分片来支持具有非常大的数据集和高吞吐量操作的部署。
换句话说：分片(sharding)是指将数据拆分，将其分散存在不同的机器上的过程。有时也用分区(partitioning)来表示这个概念。将数据分散到不同的机器上，不需要功能强大的大型计算机就可以储存更多的数据，处理更多的负载。
具有大型数据集或高吞吐量应用程序的数据库系统可以会挑战单个服务器的容量。例如，高查询率会耗尽服务器的CPU容量。工作集大小大于系统的RAM会强调磁盘驱动器的I / O容量。
有两种解决系统增长的方法：垂直扩展和水平扩展。
垂直扩展意味着增加单个服务器的容量，例如使用更强大的CPU，添加更多RAM或增加存储空间量。可用技术的局限性可能会限制单个机器对于给定工作负载而言足够强大。此外，基于云的提供商基于可用的硬件配置具有硬性上限。结果，垂直缩放有实际的最大值。
水平扩展意味着划分系统数据集并加载多个服务器，添加其他服务器以根据需要增加容量。虽然单个机器的总体速度或容量可能不高，但每台机器处理整个工作负载的子集，可能提供比单个高速大容量服务器更高的效率。扩展部署容量只需要根据需要添加额外的服务器，这可能比单个机器的高端硬件的总体成本更低。权衡是基础架构和部署维护的复杂性增加。
MongoDB支持通过分片进行水平扩展。
2.2 分片集群包含的组件
MongoDB分片群集包含以下组件：
- 分片（存储）：每个分片包含分片数据的子集。 每个分片都可以部署为副本集。
- mongos （路由）：mongos充当查询路由器，在客户端应用程序和分片集群之间提供接口。
- config servers （“调度”的配置）：配置服务器存储群集的元数据和配置设置。 从MongoDB 3.4开始，必须将配置服务器部署为副本集（CSRS）。
下图描述了分片集群中组件的交互：
MongoDB在集合级别对数据进行分片，将集合数据分布在集群中的分片上。
2.3 分片集群架构目标
两个分片节点副本集（3+3）+一个配置节点副本集（3）+两个路由节点（2），共11个服务节点。
2.4 分片（存储）节点副本集的创建
所有的的配置文件都直接放到 sharded_cluster 的相应的子目录下面，默认配置文件名字：mongod.conf
2.4.1 第一套副本集
准备存放数据和日志的目录：
1 | #-----------myshardrs01 |
新建或修改配置文件：
1 | vim /mongodb/sharded_cluster/myshardrs01_27018/mongod.conf |
myshardrs01_27018 ：
1 | systemLog: |
sharding.clusterRole：
| Value | Description |
|---|---|
| configsvr | Start this instance as a config server. The instance starts on port 27019 by default. |
| shardsvr | Start this instance as a shard . The instance starts on port 27018 by default. |
注意：
设置sharding.clusterRole需要mongod实例运行复制。 要将实例部署为副本集成员，请使用replSetName设置并指定副本集的名称。
新建或修改配置文件：
1 | vim /mongodb/sharded_cluster/myshardrs01_27118/mongod.conf |
myshardrs01_27118 ：
1 | systemLog: |
新建或修改配置文件：
1 | vim /mongodb/sharded_cluster/myshardrs01_27218/mongod.conf |
myshardrs01_27218 ：
1 | systemLog: |
启动第一套副本集：一主一副本一仲裁
依次启动三个mongod服务：
1 | [root@bobohost bin]# /usr/local/mongodb/bin/mongod -f /mongodb/sharded_cluster/myshardrs01_27018/mongod.conf |
查看服务是否启动：
1 | [root@bobohost bin]# ps -ef |grep mongod |
2.4.1.1 初始化副本集和创建主节点：
使用客户端命令连接任意一个节点，但这里尽量要连接主节点：
1 | /usr/local/mongodb/bin/mongo --host 180.76.159.126 --port 27018 |
执行初始化副本集命令：
1 | rs.initiate() |
查看副本集情况
1 | rs.status() |
主节点配置查看
1 | rs.conf() |
2.4.1.2 添加副本节点
1 | rs.add("180.76.159.126:27118") |
2.4.1.3 添加仲裁节点
1 | rs.addArb("180.76.159.126:27218") |
查看副本集的配置情况
1 | myshardrs01:PRIMARY> rs.conf() |
2.4.2 第二套副本集
准备存放数据和日志的目录：
1 | #-----------myshardrs02 |
新建或修改配置文件：
1 | vim /mongodb/sharded_cluster/myshardrs02_27318/mongod.conf |
myshardrs02_27318 ：
1 | systemLog: |
新建或修改配置文件：
1 | vim /mongodb/sharded_cluster/myshardrs02_27418/mongod.conf |
myshardrs02_27418 ：
1 | systemLog: |
新建或修改配置文件：
1 | vim /mongodb/sharded_cluster/myshardrs02_27518/mongod.conf |
myshardrs02_27518 ：
1 | systemLog: |
启动第二套副本集：一主一副本一仲裁
依次启动三个mongod服务：
1 | [root@bobohost bin]# /usr/local/mongodb/bin/mongod -f /mongodb/sharded_cluster/myshardrs02_27318/mongod.conf |
查看服务是否启动：
1 | [root@bobohost bin]# ps -ef |grep mongod |
2.4.2.1 初始化副本集和创建主节点
使用客户端命令连接任意一个节点，但这里尽量要连接主节点：
1 | /usr/local/mongodb/bin/mongo --host 180.76.159.126 --port 27318 |
执行初始化副本集命令：
1 | rs.initiate() |
查看副本集情况 (节选内容)：
1 | rs.status() |
主节点配置查看：
1 | rs.conf() |
2.4.2.2 添加副本节点
1 | rs.add("180.76.159.126:27418") |
2.4.2.3 添加仲裁节点
1 | rs.addArb("180.76.159.126:27518") |
查看副本集的配置情况
1 | myshardrs02:PRIMARY> rs.status() |
2.5 配置节点副本集的创建
第一步：准备存放数据和日志的目录：
1 | #-----------configrs |
新建或修改配置文件：
1 | vim /mongodb/sharded_cluster/myconfigrs_27019/mongod.conf |
myconfigrs_27019 ：
1 | systemLog: |
新建或修改配置文件：
1 | vim /mongodb/sharded_cluster/myconfigrs_27119/mongod.conf |
myconfigrs_27119
1 | systemLog: |
新建或修改配置文件：
1 | vim /mongodb/sharded_cluster/myconfigrs_27219/mongod.conf |
myconfigrs_27219
1 | systemLog: |
启动配置副本集：一主两副本
依次启动三个mongod服务：
1 | [root@bobohost bin]# /usr/local/mongodb/bin/mongod -f /mongodb/sharded_cluster/myconfigrs_27019/mongod.conf |
查看服务是否启动：
1 | [root@bobohost bin]# ps -ef |grep mongod |
2.5.1 初始化副本集和创建主节点
使用客户端命令连接任意一个节点，但这里尽量要连接主节点：
1 | /usr/local/mongodb/bin/mongo --host 180.76.159.126 --port 27019 |
执行初始化副本集命令：
1 | rs.initiate() |
查看副本集情况 (节选内容)：
1 | rs.status() |
主节点配置查看：
1 | rs.conf() |
2.5.2 添加两个副本节点
1 | myshardrs01:PRIMARY> rs.add("180.76.159.126:27119") |
查看副本集的配置情况：
1 | myshardrs01:PRIMARY> rs.conf() |
2.6 路由节点的创建和操作
2.6.1 第一个路由节点的创建和连接
第一步：准备存放数据和日志的目录：
1 | #-----------mongos01 |
mymongos_27017节点：
新建或修改配置文件：
1 | vi /mongodb/sharded_cluster/mymongos_27017/mongos.conf |
mongos.conf：
1 | systemLog: |
启动mongos：
1 | [root@bobohost bin]# /usr/local/mongodb/bin/mongos -f /mongodb/sharded_cluster/mymongos_27017/mongos.conf |
提示：启动如果失败，可以查看 log目录下的日志，查看失败原因。
客户端登录mongos
1 | /usr/local/mongodb/bin/mongo --host 180.76.159.126 --port 27017 |
此时，写不进去数据，如果写数据会报错：
1 | mongos> use aadb |
原因：通过路由节点操作，现在只是连接了配置节点，还没有连接分片数据节点，因此无法写入业务数据。
2.6.2 在路由节点上进行分片配置操作
使用命令添加分片：
2.6.2.1 添加分片：
语法：
1 | sh.addShard("IP:Port") |
将第一套分片副本集添加进来：
1 | mongos>sh.addShard("myshardrs01/192.168.0.2:27018,180.76.159.126:27118,180.76.159.126:27218") |
查看分片状态情况：
1 | mongos> sh.status() |
继续将第二套分片副本集添加进来：
1 | mongos>sh.addShard("myshardrs02/192.168.0.2:27318,180.76.159.126:27418,180.76.159.126:27518") |
查看分片状态：
1 | mongos> sh.status() |
提示：如果添加分片失败，需要先手动移除分片，检查添加分片的信息的正确性后，再次添加分片。
移除分片参考(了解)：
1 | use admin |
注意：如果只剩下最后一个 shard，是无法删除的
移除时会自动转移分片数据，需要一个时间过程。
完成后，再次执行删除分片命令才能真正删除。
2.6.2.2 开启分片功能
sh.enableSharding(“库名”)、sh.shardCollection(“库名.集合名”,{“key”:1})
在mongos上的articledb数据库配置sharding:
1 | mongos> sh.enableSharding("articledb") |
查看分片状态：
1 | mongos> sh.status() |
2.6.2.3 集合分片
对集合分片，你必须使用 sh.shardCollection() 方法指定集合和分片键
语法：
1 | sh.shardCollection(namespace, key, unique) |
参数：
| Parameter | Type | Description |
|---|---|---|
| namespace | string | 要（分片）共享的目标集合的命名空间，格式： |
| key | document | 用作分片键的索引规范文档。shard键决定MongoDB如何在shard之间分发文档。除非集合为空，否则索引必须在shardcollection命令之前存在。如果集合为空，则MongoDB在对集合进行分片之前创建索引，前提是支持分片键的索引不存在。简单的说：由包含字段和该字段的索引遍历方向的文档组成。 |
| unique | boolean | 当值为true情况下，片键字段上会限制为确保是唯一索引。哈希策略片键不支持唯一索引。默认是false。 |
对集合进行分片时,你需要选择一个 片键（Shard Key） , shard key 是每条记录都必须包含的,且建立了索引的单个字段或复合字段,MongoDB按照片键将数据划分到不同的 数据块 中,并将 数据块 均衡地分布到所有分片中.为了按照片键划分数据块,MongoDB使用 基于哈希的分片方式（随机平均分配）或者基于范围的分片方式（数值大小分配） 。
用什么字段当片键都可以，如：nickname作为片键，但一定是必填字段。
分片规则一：哈希策略
对于 基于哈希的分片 ,MongoDB计算一个字段的哈希值,并用这个哈希值来创建数据块.
在使用基于哈希分片的系统中,拥有”相近”片键的文档 很可能不会 存储在同一个数据块中,因此数据的分离性更好一些.
使用nickname作为片键，根据其值的哈希值进行数据分片
1 | mongos> sh.shardCollection("articledb.comment",{"nickname":"hashed"}) |
查看分片状态：sh.status()
1 | databases: |
分片规则二：范围策略
对于 基于范围的分片 ,MongoDB按照片键的范围把数据分成不同部分.假设有一个数字的片键:想象一个从负无穷到正无穷的直线,每一个片键的值都在直线上画了一个点.MongoDB把这条直线划分为更短的不重叠的片段,并称之为 数据块 ,每个数据块包含了片键在一定范围内的数据.
在使用片键做范围划分的系统中,拥有”相近”片键的文档很可能存储在同一个数据块中,因此也会存储在同一个分片中.
如使用作者年龄字段作为片键，按照点赞数的值进行分片：
1 | mongos> sh.shardCollection("articledb.author",{"age":1}) |
注意的是：
- 一个集合只能指定一个片键，否则报错。
- 一旦对一个集合分片，分片键和分片值就不可改变。 如：不能给集合选择不同的分片键、不能更新分片键的值。
- 根据age索引进行分配数据。
查看分片状态：
1 | articledb.author |
基于范围的分片方式与基于哈希的分片方式性能对比：
基于范围的分片方式提供了更高效的范围查询,给定一个片键的范围,分发路由可以很简单地确定哪个数据块存储了请求需要的数据,并将请求转发到相应的分片中.
不过,基于范围的分片会导致数据在不同分片上的不均衡,有时候,带来的消极作用会大于查询性能的积极作用.比如,如果片键所在的字段是线性增长的,一定时间内的所有请求都会落到某个固定的数据块中,最终导致分布在同一个分片中.在这种情况下,一小部分分片承载了集群大部分的数据,系统并不能很好地进行扩展.
与此相比,基于哈希的分片方式以范围查询性能的损失为代价,保证了集群中数据的均衡.哈希值的随机性使数据随机分布在每个数据块中,因此也随机分布在不同分片中.但是也正由于随机性,一个范围查询很难确定应该请求哪些分片,通常为了返回需要的结果,需要请求所有分片.
如无特殊情况，一般推荐使用 Hash Sharding。
而使用 _id 作为片键是一个不错的选择，因为它是必有的，你可以使用数据文档 _id 的哈希作为片键。
这个方案能够是的读和写都能够平均分布，并且它能够保证每个文档都有不同的片键所以数据块能够很精细。
似乎还是不够完美，因为这样的话对多个文档的查询必将命中所有的分片。虽说如此，这也是一种比较好的方案了。
理想化的 shard key 可以让 documents 均匀地在集群中分布：
显示集群的详细信息：
1 | mongos> db.printShardingStatus() |
查看均衡器是否工作（需要重新均衡时系统才会自动启动，不用管它）：
1 | mongos> sh.isBalancerRunning() |
查看当前 Balancer状态：
1 | mongos> sh.getBalancerState() |
2.6.3 分片后插入数据测试
测试一（哈希规则）：登录mongs后，向comment循环插入1000条数据做测试：
1 | mongos> use articledb |
提示： js的语法，因为mongo的shell是一个JavaScript的shell。
注意：从路由上插入的数据，必须包含片键，否则无法插入。
分别登陆两个片的主节点，统计文档数量
第一个分片副本集：
1 | /usr/local/mongodb/bin/mongo --host 180.76.159.126 --port 27018 |
第二个分片副本集：
1 | /usr/local/mongodb/bin/mongo --host 180.76.159.126 --port 27318 |
可以看到， 1000条数据近似均匀的分布到了2个shard上。是根据片键的哈希值分配的。
这种分配方式非常易于水平扩展：一旦数据存储需要更大空间，可以直接再增加分片即可，同时提升了性能。
使用db.comment.stats()查看单个集合的完整情况，mongos执行该命令可以查看该集合的数据分片的情况。
使用sh.status()查看本库内所有集合的分片信息。
测试二（范围规则）：登录mongs后，向comment循环插入1000条数据做测试：
1 | mongos> use articledb |
插入成功后，仍然要分别查看两个分片副本集的数据情况。
分片效果：
1 | articledb.author |
提示：
如果查看状态发现没有分片，则可能是由于以下原因造成了：
系统繁忙，正在分片中。
数据块（chunk）没有填满，默认的数据块尺寸（chunksize）是64M，填满后才会考虑向其他片的数据块填充数据，因此，为了测试，可以将其改小，这里改为1M，操作如下：
1
2use config
db.settings.save( { _id:"chunksize", value: 1 } )测试完改回来：
1
db.settings.save( { _id:"chunksize", value: 64 } )
注意：要先改小，再设置分片。为了测试，可以先删除集合，重新建立集合的分片策略，再插入数据测试即可。
2.6.4 再增加一个路由节点
文件夹：
1 | #-----------mongos02 |
新建或修改配置文件：
1 | vi /mongodb/sharded_cluster/mymongos_27117/mongos.conf |
mongos.conf：
1 | systemLog: |
启动mongos2：
1 | [root@bobohost bin]# /usr/local/mongodb/bin/mongos -f /mongodb/sharded_cluster/mymongos_27117/mongos.conf |
使用mongo客户端登录27117，发现，第二个路由无需配置，因为分片配置都保存到了配置服务器中了。
2.7 Compass 连接分片集群
compass连接：
提示：和连接单机 mongod一样。
连接成功后，上方有mongos和分片集群的提示：
2.8 SpringDataMongDB 连接分片集群
Java客户端常用的是SpringDataMongoDB，其连接的是mongs路由，配置和单机mongod的配置是一样的。
多个路由的时候的SpringDataMongoDB的客户端配置参考如下：
1 | spring: |
通过日志发现，写入数据的时候，会选择一个路由写入
2.9 清除所有的节点数据（备用）
如果在搭建分片的时候有操作失败或配置有问题，需要重新来过的，可以进行如下操作：
第一步：查询出所有的测试服务节点的进程：
1 | [root@bobohost sharded_cluster]# ps -ef |grep mongo |
根据上述的进程编号，依次中断进程：
1 | kill -2 进程编号 |
第二步：清除所有的节点的数据：
1 | rm -rf /mongodb/sharded_cluster/myconfigrs_27019/data/db/*.* \ & |
第三步：查看或修改有问题的配置
第四步：依次启动所有节点，不包括路由节点：
1 | /usr/local/mongodb/bin/mongod -f /mongodb/sharded_cluster/myshardrs01_27018/mongod.conf |
第五步：对两个数据分片副本集和一个配置副本集进行初始化和相关配置
第六步：检查路由mongos的配置，并启动mongos
1 | /usr/local/mongodb/bin/mongod -f /mongodb/sharded_cluster/mymongos_27017/mongos.cfg |
第七步：mongo登录mongos，在其上进行相关操作。
3. 安全认证
3.1 MongoDB 的用户和角色权限简介
默认情况下，MongoDB实例启动运行时是没有启用用户访问权限控制的，也就是说，在实例本机服务器上都可以随意连接到实例进行各种操作，MongoDB不会对连接客户端进行用户验证，这是非常危险的。
mongodb官网上说，为了能保障mongodb的安全可以做以下几个步骤：
- 使用新的端口，默认的27017端口如果一旦知道了ip就能连接上，不太安全。
- 设置mongodb的网络环境，最好将mongodb部署到公司服务器内网，这样外网是访问不到的。公司内部访问使用vpn等。
- 开启安全认证。认证要同时设置服务器之间的内部认证方式，同时要设置客户端连接到集群的账号密码认证方式。
为了强制开启用户访问控制(用户验证)，则需要在MongoDB实例启动时使用选项 – auth 或在指定启动配置文件中添加选项 auth=true 。
在开始之前需要了解一下概念
1）启用访问控制：
MongoDB使用的是基于角色的访问控制(Role-Based Access Control,RBAC)来管理用户对实例的访问。通过对用户授予一个或多个角色来控制用户访问数据库资源的权限和数据库操作的权限，在对用户分配角色之前，用户无法访问实例。
在实例启动时添加选项 – auth 或指定启动配置文件中添加选项 auth=true 。
2）角色：
在MongoDB中通过角色对用户授予相应数据库资源的操作权限，每个角色当中的权限可以显式指定，也可以通过继承其他角色的权限，或者两都都存在的权限。
3）权限：
权限由指定的数据库资源(resource)以及允许在指定资源上进行的操作(action)组成。
- 资源(resource)包括：数据库、集合、部分集合和集群；
- 操作(action)包括：对资源进行的增、删、改、查(CRUD)操作。
在角色定义时可以包含一个或多个已存在的角色，新创建的角色会继承包含的角色所有的权限。在同一个数据库中，新创建角色可以继承其他角色的权限，在 admin 数据库中创建的角色可以继承在其它任意数据库中角色的权限。
关于角色权限的查看，可以通过如下命令查询（了解）：
1 | // 查询所有角色权限(仅用户自定义角色) |
示例：
查看所有内置角色：
1 | > db.runCommand({ rolesInfo: 1, showBuiltinRoles: true }) |
常用的内置角色：
- 数据库用户角色： read、readWrite;
- 所有数据库用户角色： readAnyDatabase、readWriteAnyDatabase、userAdminAnyDatabase、dbAdminAnyDatabase
- 数据库管理角色： dbAdmin、dbOwner、userAdmin；
- 集群管理角色： clusterAdmin、clusterManager、clusterMonitor、hostManager；
- 备份恢复角色： backup、restore；
- 超级用户角色： root
- 内部角色： system
角色说明：
| 角色 | 权限描述 |
|---|---|
| read | 可以读取指定数据库中任何数据 |
| readWrite | 可以读写指定数据库中任何数据，包括创建、重命名、删除集合 |
| readAnyDatabase | 可以读取所有数据库中任何数据(除了数据库config和local之外) |
| readWriteAnyDatabase | 可以读写所有数据库中任何数据(除了数据库config和local之外) |
| userAdminAnyDatabase | 可以在指定数据库创建和修改用户(除了数据库config和local之外) |
| dbAdminAnyDatabase | 可以读取任何数据库以及对数据库进行清理、修改、压缩、获取统计信息、执行检查等操作(除了数据库config和local之外) |
| dbAdmin | 可以读取指定数据库以及对数据库进行清理、修改、压缩、获取统计信息、执行检查等操作 |
| userAdmin | 可以在指定数据库创建和修改用户 |
| clusterAdmin | 可以对整个集群或数据库系统进行管理操作 |
| backup | 备份MongoDB数据最小的权限 |
| restore | 从备份文件中还原恢复MongoDB数据(除了system.profile集合)的权限 |
| root | 超级账号，超级权限 |
3.2 单实例环境
目标：对单实例的MongoDB服务开启安全认证，这里的单实例指的是未开启副本集或分片的MongoDB实例。
3.2.1 关闭已开启的服务
增加mongod的单实例的安全认证功能，可以在服务搭建的时候直接添加，也可以在之前搭建好的服务上添加。
本文使用之前搭建好的服务，因此，先停止之前的服务
停止服务的方式有两种：快速关闭和标准关闭，下面依次说明：
（1）快速关闭方法（快速，简单，数据可能会出错）
目标：通过系统的kill命令直接杀死进程：
杀完要检查一下，避免有的没有杀掉。
1 | #通过进程编号关闭节点 |
【补充】
如果一旦是因为数据损坏，则需要进行如下操作（了解）：
1）删除lock文件：
1 | rm -f /mongodb/single/data/db/*.lock |
2 ）修复数据：
1 | /usr/local/mongodb/bin/mongod --repair --dbpath=/mongodb/single/data/db |
（2）标准的关闭方法（数据不容易出错，但麻烦）：
目标：通过mongo客户端中的shutdownServer命令来关闭服务
主要的操作步骤参考如下：
1 | //客户端登录服务，注意，这里通过localhost登录，如果需要远程登录，必须先登录认证才行。 |
3.2.2 添加用户和权限
（1）先按照普通无授权认证的配置，来配置服务端的配置文件 /mongodb/single/mongod.conf
1 | systemLog: |
（2）按之前未开启认证的方式（不添加 – auth 参数）来启动MongoDB服务
1 | /usr/local/mongodb/bin/mongod -f /mongodb/single/mongod.conf |
提示：
在操作用户时，启动mongod服务时尽量不要开启授权。
（3）使用Mongo客户端登录
1 | /usr/local/mongodb/bin/mongo --host 180.76.159.126 --port 27017 |
（4）创建两个管理员用户，一个是系统的超级管理员 myroot ，一个是admin库的管理用户myadmin
1 | //切换到admin库 |
提示：
- 本案例创建了两个用户，分别对应超管和专门用来管理用户的角色，事实上，你只需要一个用户即可。如果你对安全要求很高，防止超管泄漏，则不要创建超管用户。
- 和其它数据库（MySQL）一样，权限的管理都差不多一样，也是将用户和权限信息保存到数据库对应的表中。Mongodb存储所有的用户信息在admin 数据库的集合system.users中，保存用户名、密码和数据库信息。
- 如果不指定数据库，则创建的指定的权限的用户在所有的数据库上有效，如 {role: “userAdminAnyDatabase”, db:””}
（5）认证测试
测试添加的用户是否正确
1 | //切换到admin |
（6）创建普通用户
创建普通用户可以在没有开启认证的时候添加，也可以在开启认证之后添加，但开启认证之后，必须使用有操作admin库的用户登录认证后才能操作。底层都是将用户信息保存在了admin数据库的集合system.users中
1 | //创建(切换)将来要操作的数据库articledb, |
提示：
如果开启了认证后，登录的客户端的用户必须使用admin库的角色，如拥有root角色的myadmin用户，再通过myadmin用户去创建其他角色的用户
3.2.3 服务端开启认证和客户端连接登录
3.2.3.1 关闭已经启动的服务
1）使用linux命令杀死进程：
1 | [root@bobohost single]# ps -ef |grep mongo |
2 ）在mongo客户端中使用shutdownServer命令来关闭
1 | > db.shutdownServer() |
需要几个条件：
- 必须是在 admin库下执行该关闭服务命令。
- 如果没有开启认证，必须是从 localhost登陆的，才能执行关闭服务命令。
- 非 localhost的、通过远程登录的，必须有登录且必须登录用户有对admin操作权限才可以。
3.2.3.2 以开启认证的方式启动服务
有两种方式开启权限认证启动服务：一种是参数方式，一种是配置文件方式
1）参数方式
在启动时指定参数 – auth ，如：
1 | /usr/local/mongodb/bin/mongod -f /mongodb/single/mongod.conf --auth |
2）配置文件方式
在mongod.conf配置文件中加入：vim /mongodb/single/mongod.conf
1 | security: |
启动时可不加 – auth 参数：
1 | /usr/local/mongodb/bin/mongod -f /mongodb/single/mongod.conf |
3.2.3.3 开启了认证的情况下的客户端登录
有两种认证方式，一种是先登录，在mongo shell中认证；一种是登录时直接认证
1）先连接再认证
1 | [root@bobohost bin]# /usr/local/mongodb/bin/mongo --host 180.76.159.126 --port 27017 |
提示：
开启认证后再登录，发现打印的日志比较少了。
相关操作需要认证才可以：
查询admin库中的system.users集合的用户：
1 | > use admin |
查询articledb库中的comment集合的内容：
1 | > use articledb |
提示：
这里可能出现错误，说是太多的用户正在认证了。因为我们确实连续登录了两个用户了。
解决方案：退出shell，重新进来登录认证
1 | > exit |
2）连接时直接认证
对admin数据库进行登录认证和相关操作：
1 | [root@bobohost ~]# /usr/local/mongodb/bin/mongo --host 180.76.159.126 --port 27017 --authenticationDatabase admin -u myroot -p 123456 |
对articledb数据库进行登录认证和相关操作：
1 | [root@bobohost bin]# /usr/local/mongodb/bin/mongo --host 180.76.159.126 --port 27017 --authenticationDatabase articledb -u bobo -p 123456 |
提示：
-u：用户名-p：密码-- authenticationDatabase：指定连接到哪个库。当登录是指定用户名密码时，必须指定对应的数据库！
3.2.4 SpringDataMongoDB连接认证
使用用户名和密码连接到 MongoDB 服务器，你必须使用'username:password@hostname/dbname' 格式，’username’为用户名，’password’ 为密码。
目标：使用用户bobo使用密码 123456 连接到MongoDB 服务上。
application.yml：
1 | spring: |
3.3 副本集环境
3.3.1 前言
对于搭建好的mongodb副本集，为了安全，启动安全认证，使用账号密码登录。
副本集环境使用之前搭建好的，架构如下：
对副本集执行访问控制需要配置两个方面 :
- 副本集和共享集群的各个节点成员之间使用内部身份验证，可以使用密钥文件或x.509证书。密钥文件比较简单，本文使用密钥文件，官方推荐如果是测试环境可以使用密钥文件，但是正式环境，官方推荐x.509证书。原理就是，集群中每一个实例彼此连接的时候都检验彼此使用的证书的内容是否相同。只有证书相同的实例彼此才可以访问
- 使用客户端连接到mongodb集群时，开启访问授权。对于集群外部的访问。如通过可视化客户端，或者通过代码连接的时候，需要开启授权。
在keyfile身份验证中，副本集中的每个mongod实例都使用keyfile的内容作为共享密码，只有具有正确密钥文件的mongod或者mongos实例可以连接到副本集。密钥文件的内容必须在6到1024个字符之间，并且在unix/linux系统中文件所有者必须有对文件至少有读的权限。
3.3.2 关闭已开启的副本集服务
增加副本集的安全认证和服务鉴权功能，可以在副本集搭建的时候直接添加，也可以在之前搭建好的副本集服务上添加。
本文使用之前搭建好的副本集服务，因此，先停止之前的集群服务
停止服务的方式有两种：快速关闭和标准关闭，下面依次说明：
（1）快速关闭方法（快速，简单，数据可能会出错）
目标：通过系统的kill命令直接杀死进程：
依次杀死仲裁者、副本节点、主节点，直到所有成员都离线。建议主节点最后kill，以避免潜在的回滚。杀完要检查一下，避免有的没有杀掉。
1 | #通过进程编号关闭节点 |
【补充】
如果一旦是因为数据损坏，则需要进行如下操作（了解）：
1）删除lock文件：
1 | rm -f /mongodb/replica_sets/myrs_27017/data/db/*.lock \ |
2 ）依次修复数据：
1 | /usr/local/mongodb/bin/mongod --repair --dbpath=/mongodb/replica_sets/myrs_27017/data/db |
（2）标准的关闭方法（数据不容易出错，但麻烦）
目标：通过mongo客户端中的shutdownServer命令来依次关闭各个服务
关闭副本集中的服务，建议依次关闭仲裁节点、副本节点、主节点。主要的操作步骤参考如下：
1 | //客户端登录服务，注意，这里通过localhost登录，如果需要远程登录，必须先登录认证才行。 |
3.3.3 通过主节点添加一个管理员帐号
只需要在主节点上添加用户，副本集会自动同步。
开启认证之前，创建超管用户：myroot，密码：123456
1 | myrs:PRIMARY> use admin |
该步骤也可以在开启认证之后，但需要通过localhost登录才允许添加用户，用户数据也会自动同步到副本集。
后续再创建其他用户，都可以使用该超管用户创建。
3.3.4 创建副本集认证的key文件
第一步：生成一个key文件到当前文件夹中。
可以使用任何方法生成密钥文件。例如，以下操作使用openssl生成密码文件，然后使用chmod来更改文件权限，仅为文件所有者提供读取权限
1 | [root@bobohost ~]# openssl rand -base64 90 -out ./mongo.keyfile |
提示：
所有副本集节点都必须要用同一份keyfile，一般是在一台机器上生成，然后拷贝到其他机器上，且必须有读的权限，否则将来会报错： permissions on /mongodb/replica_sets/myrs_27017/mongo.keyfile are too open
一定要保证密钥文件一致，文件位置随便。但是为了方便查找，建议每台机器都放到一个固定的位置，都放到和配置文件一起的目录中。
这里将该文件分别拷贝到多个目录中：
1 | [root@bobohost ~]# cp mongo.keyfile /mongodb/replica_sets/myrs_27017 |
3.3.5 修改配置文件指定keyfile
分别编辑几个服务的mongod.conf文件，添加相关内容
/mongodb/replica_sets/myrs_27017/mongod.conf
1 | security: |
/mongodb/replica_sets/myrs_27018/mongod.conf
1 | security: |
/mongodb/replica_sets/myrs_27019/mongod.conf
1 | security: |
3.3.6 重新启动副本集
如果副本集是开启状态，则先分别关闭关闭复本集中的每个mongod，从次节点开始。直到副本集的所有成员都离线，包括任何仲裁者。主节点必须是最后一个成员关闭以避免潜在的回滚。
1 | #通过进程编号关闭三个节点 |
分别启动副本集节点：
1 | /usr/local/mongodb/bin/mongod -f /mongodb/replica_sets/myrs_27017/mongod.conf |
查看进程情况：
1 | [root@bobohost replica_sets]# ps -ef |grep mongod |
3.3.7 在主节点上添加普通账号
1 | #先用管理员账号登录 |
重新连接，使用普通用户 bobo重新登录，查看数据。
3.3.8 SpringDataMongoDB连接副本集
使用用户名和密码连接到 MongoDB 服务器，你必须使用'username:password@hostname/dbname' 格式，’username’为用户名，’password’ 为密码。
目标：使用用户bobo使用密码 123456 连接到MongoDB 服务上。
application.yml：
1 | spring: |
3.4 分片集群环境(扩展)
3.4.1 关闭已开启的集群服务
分片集群环境下的安全认证和副本集环境下基本上一样。
但分片集群的服务器环境和架构较为复杂，建议在搭建分片集群的时候，直接加入安全认证和服务器间的鉴权，如果之前有数据，可先将之前的数据备份出来，再还原回去。
本文使用之前搭建好的集群服务，因此，先停止之前的集群服务
停止服务的方式有两种：快速关闭和标准关闭，下面依次说明：
（1）快速关闭方法（快速，简单，数据可能会出错）
目标：通过系统的kill命令直接杀死进程：
依次杀死 mongos路由、配置副本集服务，分片副本集服务，从次节点开始。直到所有成员都离线。副本集杀的时候，建议先杀仲裁者，再杀副本节点，最后是主节点，以避免潜在的回滚。杀完要检查一下，避免有的没有杀掉。
1 | #通过进程编号关闭节点 |
【补充】
如果一旦是因为数据损坏，则需要进行如下操作（了解）：
1）删除lock文件：
1 | rm -f /mongodb/sharded_cluster/myshardrs01_27018/data/db/*.lock \ |
2 ）依次修复数据：
1 | /usr/local/mongodb/bin/mongod --repair -- |
（2）标准的关闭方法（数据不容易出错，但麻烦）：
目标：通过mongo客户端中的shutdownServer命令来依次关闭各个服务
关闭分片服务器副本集中的服务，建议依次关闭仲裁节点、副本节点、主节点。主要的操作步骤参考如下：
1 | //客户端登录服务，注意，这里通过localhost登录，如果需要远程登录，必须先登录认证才行。 |
关闭配置服务器副本集的服务，建议依次关闭副本节点、主节点。主要的操作步骤参考如下：
1 | //客户端登录服务，注意，这里通过localhost登录，如果需要远程登录，必须先登录认证才行。 |
关闭路由服务器的服务，建议依次关闭两个路由节点。主要的操作步骤参考如下：
1 | //客户端登录服务，注意，这里通过localhost登录，如果需要远程登录，必须先登录认证才行。 |
3.4.2 创建副本集认证的key文件
第一步：生成一个key文件到当前文件夹中。
可以使用任何方法生成密钥文件。例如，以下操作使用openssl生成密码文件，然后使用chmod来更改文件权限，仅为文件所有者提供读取权限
1 | [root@bobohost ~]# openssl rand -base64 90 -out ./mongo.keyfile |
提示：
所有副本集节点都必须要用同一份keyfile，一般是在一台机器上生成，然后拷贝到其他机器上，且必须
有读的权限，否则将来会报错： permissions on /mongodb/replica_sets/myrs_27017/mongo.keyfile are too open
一定要保证密钥文件一致，文件位置随便。但是为了方便查找，建议每台机器都放到一个固定的位置，都放到和配置文件一起的目录中。
这里将该文件分别拷贝到多个目录中：
1 | echo '/mongodb/sharded_cluster/myshardrs01_27018/mongo.keyfile |
3.4.3 修改配置文件指定keyfile
分别编辑几个服务的mongod.conf文件，添加相关内容：
/mongodb/sharded_cluster/myshardrs01_27018/mongod.conf
1 | security: |
/mongodb/sharded_cluster/myshardrs01_27118/mongod.conf
1 | security: |
/mongodb/sharded_cluster/myshardrs01_27218/mongod.conf
1 | security: |
/mongodb/sharded_cluster/myshardrs02_27318/mongod.conf
1 | security: |
/mongodb/sharded_cluster/myshardrs02_27418/mongod.conf
1 | security: |
/mongodb/sharded_cluster/myshardrs02_27518/mongod.conf
1 | security: |
/mongodb/sharded_cluster/myconfigrs_27019/mongod.conf
1 | security: |
/mongodb/sharded_cluster/myconfigrs_27119/mongod.conf
1 | security: |
/mongodb/sharded_cluster/myconfigrs_27219/mongod.conf
1 | security: |
/mongodb/sharded_cluster/mymongos_27017/mongos.conf
1 | security: |
/mongodb/sharded_cluster/mymongos_27117/mongos.conf
1 | security: |
mongos 比mongod少了authorization：enabled的配置。原因是，副本集加分片的安全认证需要配置两方面的，副本集各个节点之间使用内部身份验证，用于内部各个mongo实例的通信，只有相同keyfile才能相互访问。所以都要开启 keyFile: /mongodb/sharded_cluster/mymongos_27117/mongo.keyfile 。
然而对于所有的mongod，才是真正的保存数据的分片。mongos只做路由，不保存数据。所以所有的mongod开启访问数据的授权authorization:enabled。这样用户只有账号密码正确才能访问到数据。
3.4.4 重新启动节点
必须依次启动配置节点、分片节点、路由节点：
1 | /usr/local/mongodb/bin/mongod -f /mongodb/sharded_cluster/myconfigrs_27019/mongod.conf |
注意：
这里有个非常特别的情况，就是启动顺序。先启动配置节点，再启动分片节点，最后启动路由节点。
如果先启动分片节点，会卡住，提示：
1 | about to fork child process, waiting until server is ready for connections |
这也许是个 bug。原因未知。
3.3.5 创建帐号和认证
客户端mongo，通过localhost登录任意一个mongos路由，
1 | [root@bobohost db]# /usr/local/mongodb/bin/mongo --port 27017 |
提示：相当于一个后门，只能在 admin下添加用户。
创建一个管理员帐号：
1 | mongos> use admin |
提示：如果在开启认证之前已经创建了管理员账号，这里可以忽略
创建一个普通权限帐号：
1 | mongos> use admin |
提示：
通过mongos添加的账号信息，只会保存到配置节点的服务中，具体的数据节点不保存账号信息，因此，分片中的账号信息不涉及到同步问题。
mongo客户端登录mongos路由，用管理员帐号登录可查看分片情况：
1 | mongos> use admin |
退出连接，重新连接服务，使用普通权限帐号访问数据：
1 | [root@bobohost db]# /usr/local/mongodb/bin/mongo --host 180.76.159.126 --port 27017 |
3.3.6 SpringDataMongoDB连接认证
使用用户名和密码连接到 MongoDB 服务器，你必须使用'username:password@hostname/dbname' 格式，’username’为用户名，’password’ 为密码。
目标：使用用户bobo使用密码 123456 连接到MongoDB 服务上。
application.yml：
1 | spring: |
-------------本文结束感谢您的阅读-------------
本文作者：
Wgy
本文标题： MongoDB(二)
本文链接： https://wgy1993.gitee.io/archives/afe7047c.html
版权声明： 本作品采用 CC BY-NC-SA 4.0 进行许可。转载请注明出处！
本文标题： MongoDB(二)
本文链接： https://wgy1993.gitee.io/archives/afe7047c.html
版权声明： 本作品采用 CC BY-NC-SA 4.0 进行许可。转载请注明出处！
