MongoDB集群和安全
目录
- 副本集-Replica Sets
-
- 简介
- 副本集的三个角色
- 副本集架构目标
- 副本集的创建
-
- 主节点
- 副本节点
- 仲裁节点
- 初始化配置副本集和主节点
- 查看副本集的配置内容
- 查看副本集状态
- 添加副本从节点
- 添加仲裁从节点
- 副本集的数据读写操作
- 主节点的选举原则
- 完整的连接字符串
- 分片集群-Sharded Cluster
-
- 分片概念
- 分片集群包含的组件
- 分片集群架构目标
- 分片（存储）节点副本集的创建
-
- 第一套副本集
- 第二套副本集
- 配置节点副本集的创建
- 路由节点的创建和操作
-
- 第一个路由节点的创建和连接
- 在路由节点上进行分片配置操作
- 基于范围的分片方式与基于哈希的分片方式性能对比：
- 再增加一个路由节点
- 连接分片集群
- 清除所有的节点数据（备用）
- 安全认证
-
- 常用的内置角色
- 单实例环境
-
- 添加用户和权限
- 服务端开启认证和客户端连接登录
副本集-Replica Sets
简介
MongoDB中的副本集（Replica Set）是一组维护相同数据集的mongod服务。 副本集可提供冗余和高可用性，是所有生产部署的基础。
也可以说，副本集类似于有自动故障恢复功能的主从集群。通俗的讲就是用多台机器进行同一数据的异步同步，从而使多台机器拥有同一数据的多个副本，并且当主库当掉时在不需要用户干预的情况下自动切换其他备份服务器做主库。而且还可以利用副本服务器做只读服务器，实现读写分离，提高负载。
（1）冗余和数据可用性
复制提供冗余并提高数据可用性。 通过在不同数据库服务器上提供多个数据副本，复制可提供一定级别的容错功能，以防止丢失单个数据库服务器。
在某些情况下，复制可以提供增加的读取性能，因为客户端可以将读取操作发送到不同的服务上， 在不同数据中心维护数据副本可以增加分布式应用程序的数据位置和可用性。 您还可以为专用目的维护其他副本，例如灾难恢复，报告或备份。
（2）MongoDB中的复制
副本集是一组维护相同数据集的mongod实例。 副本集包含多个数据承载节点和可选的一个仲裁节点。在承载数据的节点中，一个且仅一个成员被视为主节点，而其他节点被视为次要（从）节点。
主节点接收所有写操作。 副本集只能有一个主要能够确认具有{w：“most”}写入关注的写入; 虽然在某些情况下，另一个mongod实例可能暂时认为自己也是主要的。主要记录其操作日志中的数据集的所有更改，即oplog。
辅助(副本)节点复制主节点的oplog并将操作应用于其数据集，以使辅助节点的数据集反映主节点的数据
集。 如果master不在，则符合条件的slave将举行选举以选出新的master。
（3）主从复制和副本集区别
主从集群和副本集最大的区别就是副本集没有固定的“主节点”；整个集群会选出一个“主节点”，当其挂
掉后，又在剩下的从节点中选中其他节点为“主节点”，副本集总有一个活跃点(主、primary)和一个或多
个备份节点(从、secondary)。
副本集的三个角色
副本集有两种类型三种角色
两种类型：
- 主节点（Primary）类型：数据操作的主要连接点，可读写。
- 次要（辅助、从）节点（Secondaries）类型：数据冗余备份节点，可以读或选举。
三种角色：
3. 主要成员（Primary）：主要接收所有写操作。就是主节点。
4. 副本成员（Replicate）：从主节点通过复制操作以维护相同的数据集，即备份数据，不可写操作，但可以读操作（但需要配置）。是默认的一种从节点类型。
5. 仲裁者（Arbiter）：不保留任何数据的副本，只具有投票选举作用。当然也可以将仲裁服务器维护为副
本集的一部分，即副本成员同时也可以是仲裁者。也是一种从节点类型。
关于仲裁者的额外说明：
- 您可以将额外的mongod实例添加到副本集作为仲裁者。 仲裁者不维护数据集。 仲裁者的目的是通过响应其他副本集成员的心跳和选举请求来维护副本集中的仲裁。 因为它们不存储数据集，所以仲裁器可以是提供副本集仲裁功能的好方法，其资源成本比具有数据集的全功能副本集成员更便宜。
- 如果您的副本集具有偶数个成员，请添加仲裁者以获得主要选举中的“大多数”投票。 仲裁者不需要专用硬件。
- 仲裁者将永远是仲裁者，而主要人员可能会退出并成为次要人员，而次要人员可能成为选举期间的主要人员。
- 如果你的副本+主节点的个数是偶数，建议加一个仲裁者，形成奇数，容易满足大多数的投票。
- 如果你的副本+主节点的个数是奇数，可以不加仲裁者。
副本集架构目标
一主一副本一仲裁：
副本集的创建
主节点
新建或修改配置文件：
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
启动节点服务：
/usr/local/mongodb/bin/mongod -f /mongodb/replica_sets/myrs_27017/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
启动节点服务：
/usr/local/mongodb/bin/mongod -f /mongodb/replica_sets/myrs_27018/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
启动节点服务：
/usr/local/mongodb/bin/mongod -f /mongodb/replica_sets/myrs_27019/mongod.conf
初始化配置副本集和主节点
使用客户端命令连接任意一个节点，但这里尽量要连接主节点(27017节点)：
/usr/local/mongodb/bin/mongo --host=180.76.159.126 --port=27017
准备初始化新的副本集：
rs.initiate(configuration)
选项：
rs.initiate()
1）“ok”的值为1，说明创建成功。
2）命令行提示符发生变化，变成了一个从节点角色，此时默认不能读写。稍等片刻，回车，变成主节点。
查看副本集的配置内容
返回包含当前副本集配置的文档：
rs.conf(configuration)
提示：
- rs.config() 是该方法的别名。
- configuration：可选，如果没有配置，则使用默认主节点配置。
myrs:PRIMARY> rs.conf()
{
"_id" : "myrs",
"version" : 1,
"protocolVersion" : NumberLong(1),
"writeConcernMajorityJournalDefault" : true,
"members" : [
{
"_id" : 0,
"host" : "180.76.159.126:27017",
"arbiterOnly" : false,
"buildIndexes" : true,
"hidden" : false,
"priority" : 1,
"tags" : {},
"slaveDelay" : NumberLong(0),
"votes" : 1
}
],
"settings" : {
"chainingAllowed" : true,
"heartbeatIntervalMillis" : 2000,
"heartbeatTimeoutSecs" : 10,
"electionTimeoutMillis" : 10000,
"catchUpTimeoutMillis" : -1,
"catchUpTakeoverDelayMillis" : 30000,
"getLastErrorModes" : {},
"getLastErrorDefaults" : {
"w" : 1,
"wtimeout" : 0
},
"replicaSetId" : ObjectId("5d539bdcd6a308e600d126bb")
}
}
说明：
1） “_id” : “myrs” ：副本集的配置数据存储的主键值，默认就是副本集的名字
2） “members” ：副本集成员数组，此时只有一个： “host” : “180.76.159.126:27017” ，该成员不是仲裁节点： “arbiterOnly” : false ，优先级（权重值）： “priority” : 1,
3） “settings” ：副本集的参数配置。
副本集配置的查看命令，本质是查询的是 system.replset 的表中的数据：
myrs:PRIMARY> use local
switched to db local
myrs:PRIMARY> show collections
oplog.rs
replset.election
replset.minvalid
replset.oplogTruncateAfterPoint
startup_log
system.replset
system.rollback.id
myrs:PRIMARY> db.system.replset.find()
{ "_id" : "myrs", "version" : 1, "protocolVersion" : NumberLong(1),
"writeConcernMajorityJournalDefault" : true, "members" : [ { "_id" : 0, "host" :
"180.76.159.126:27017", "arbiterOnly" : false, "buildIndexes" : true, "hidden" :
false, "priority" : 1, "tags" : { }, "slaveDelay" : NumberLong(0), "votes" : 1
} ], "settings" : { "chainingAllowed" : true, "heartbeatIntervalMillis" : 2000,
"heartbeatTimeoutSecs" : 10, "electionTimeoutMillis" : 10000,
"catchUpTimeoutMillis" : -1, "catchUpTakeoverDelayMillis" : 30000,
"getLastErrorModes" : { }, "getLastErrorDefaults" : { "w" : 1, "wtimeout" : 0
}, "replicaSetId" : ObjectId("5d539bdcd6a308e600d126bb") } }
myrs:PRIMARY>
查看副本集状态
返回包含状态信息的文档。此输出使用从副本集的其他成员发送的心跳包中获得的数据反映副本集的当
前状态。
rs.status()
myrs:PRIMARY> rs.status()
{
"set" : "myrs",
"date" : ISODate("2019-08-14T05:29:45.161Z"),
"myState" : 1,
"term" : NumberLong(1),
"syncingTo" : "",
"syncSourceHost" : "",
"syncSourceId" : -1,
"heartbeatIntervalMillis" : NumberLong(2000),
"optimes" : {
"lastCommittedOpTime" : {
"ts" : Timestamp(1565760578, 1),
"t" : NumberLong(1)
},
"readConcernMajorityOpTime" : {
"ts" : Timestamp(1565760578, 1),
"t" : NumberLong(1)
},
"appliedOpTime" : {
"ts" : Timestamp(1565760578, 1),
"t" : NumberLong(1)
},
"durableOpTime" : {
"ts" : Timestamp(1565760578, 1),
"t" : NumberLong(1)
}
},
"lastStableCheckpointTimestamp" : Timestamp(1565760528, 1),
"members" : [
{
"_id" : 0,
"name" : "180.76.159.126:27017",
"health" : 1,
"state" : 1,
"stateStr" : "PRIMARY",
"uptime" : 419,
"optime" : {
"ts" : Timestamp(1565760578, 1),
"t" : NumberLong(1)
},
"optimeDate" : ISODate("2019-08-14T05:29:38Z"),
"syncingTo" : "",
"syncSourceHost" : "",
"syncSourceId" : -1,
"infoMessage" : "could not find member to sync from",
"electionTime" : Timestamp(1565760476, 2),
"electionDate" : ISODate("2019-08-14T05:27:56Z"),
"configVersion" : 1,
"self" : true,
"lastHeartbeatMessage" : ""
}
],
"ok" : 1,
"operationTime" : Timestamp(1565760578, 1),
"$clusterTime" : {
"clusterTime" : Timestamp(1565760578, 1),
"signature" : {
"hash" : BinData(0,"AAAAAAAAAAAAAAAAAAAAAAAAAAA="),
"keyId" : NumberLong(0)
}
}
}
1） “set” : “myrs” ：副本集的名字
2） “myState” : 1：说明状态正常
3） “members” ：副本集成员数组，此时只有一个： “name” : “180.76.159.126:27017” ，该成员的
角色是 “stateStr” : “PRIMARY”, 该节点是健康的： “health” : 1 。
添加副本从节点
在主节点添加从节点，将其他成员加入到副本集：
rs.add(host, arbiterOnly)
选项：
主机成员的配置文档：
{
_id: <int>,
host: <string>, // required
arbiterOnly: <boolean>,
buildIndexes: <boolean>,
hidden: <boolean>,
priority: <number>,
tags: <document>,
slaveDelay: <int>,
votes: <number>
}
将27018的副本节点添加到副本集中：
myrs:PRIMARY> rs.add("180.76.159.126:27018")
{
"ok" : 1,
"operationTime" : Timestamp(1565761757, 1),
"$clusterTime" : {
"clusterTime" : Timestamp(1565761757, 1),
"signature" : {
"hash" : BinData(0,"AAAAAAAAAAAAAAAAAAAAAAAAAAA="),
"keyId" : NumberLong(0)
}
}
}
添加仲裁从节点
rs.addArb(host)
将27019的仲裁节点添加到副本集中：
myrs:PRIMARY> rs.addArb("180.76.159.126:27019")
{
"ok" : 1,
"operationTime" : Timestamp(1565761959, 1),
"$clusterTime" : {
"clusterTime" : Timestamp(1565761959, 1),
"signature" : {
"hash" : BinData(0,"AAAAAAAAAAAAAAAAAAAAAAAAAAA="),
"keyId" : NumberLong(0)
}
}
}
副本集的数据读写操作
设置读操作权限：
rs.slaveOk()
#或
rs.slaveOk(true)
该命令是 db.getMongo().setSlaveOk() 的简化命令。
现在可实现了读写分离，让主插入数据，让从来读取数据。
如果要取消读权限：
rs.slaveOk(false)
主节点的选举原则
MongoDB在副本集中，会自动进行主节点的选举，主节点选举的触发条件：
1） 主节点故障
2） 主节点网络不可达（默认心跳信息为10秒）
3） 人工干预（rs.stepDown(600)）
选举规则是根据票数来决定谁获胜：
- 票数最高，且获得了“大多数”成员的投票支持的节点获胜。
- “大多数”的定义为：假设复制集内投票成员数量为N，则大多数为 N/2 + 1。例如：3个投票成员，则大多数的值是2。当复制集内存活成员数量不足大多数时，整个复制集将无法选举出Primary，复制集将无法提供写服务，处于只读状态。
- 若票数相同，且都获得了“大多数”成员的投票支持的，数据新的节点获胜。数据的新旧是通过操作日志oplog来对比的。
在获得票数的时候，优先级（priority）参数影响重大：
- 可以通过设置优先级（priority）来设置额外票数。优先级即权重，取值为0-1000，相当于可额外增加0-1000的票数，优先级的值越大，就越可能获得多数成员的投票（votes）数。指定较高的值可使成员更有资格成为主要成员，更低的值可使成员更不符合条件。
- 默认情况下，优先级的值是1
- 选举节点的优先级必须是0，不能是别的值。即不具备选举权，但具有投票权。
修改优先级：
1）先将配置导入cfg变量
myrs:SECONDARY> cfg=rs.conf()
2）然后修改值（ID号默认从0开始）：
myrs:SECONDARY> cfg.members[1].priority=2
3）重新加载配置
myrs:SECONDARY> rs.reconfig(cfg)
{ "ok" : 1 }
稍等片刻会重新开始选举。
完整的连接字符串
MongoDB客户端连接语法：
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)，如下所示：
分片集群-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个服务节点。
分片（存储）节点副本集的创建
第一套副本集
准备存放数据和日志的目录：
#-----------myshardrs01
mkdir -p /mongodb/sharded_cluster/myshardrs01_27018/log \ &
mkdir -p /mongodb/sharded_cluster/myshardrs01_27018/data/db \ &
mkdir -p /mongodb/sharded_cluster/myshardrs01_27118/log \ &
mkdir -p /mongodb/sharded_cluster/myshardrs01_27118/data/db \ &
mkdir -p /mongodb/sharded_cluster/myshardrs01_27218/log \ &
mkdir -p /mongodb/sharded_cluster/myshardrs01_27218/data/db
配置文件：
vim /mongodb/sharded_cluster/myshardrs01_27018/mongod.conf
systemLog:
#MongoDB发送所有日志输出的目标指定为文件
destination: file
#mongod或mongos应向其发送所有诊断日志记录信息的日志文件的路径
path: "/mongodb/sharded_cluster/myshardrs01_27018/log/mongod.log"
#当mongos或mongod实例重新启动时，mongos或mongod会将新条目附加到现有日志文件的末尾。
logAppend: true
storage:
#mongod实例存储其数据的目录。storage.dbPath设置仅适用于mongod。
dbPath: "/mongodb/sharded_cluster/myshardrs01_27018/data/db"
journal:
#启用或禁用持久性日志以确保数据文件保持有效和可恢复。
enabled: true
processManagement:
#启用在后台运行mongos或mongod进程的守护进程模式。
fork: true
#指定用于保存mongos或mongod进程的进程ID的文件位置，其中mongos或mongod将写入其PID
pidFilePath: "/mongodb/sharded_cluster/myshardrs01_27018/log/mongod.pid"
net:
#服务实例绑定所有IP，有副作用，副本集初始化的时候，节点名字会自动设置为本地域名，而不是ip
#bindIpAll: true
#服务实例绑定的IP
bindIp: localhost,192.168.0.2
#bindIp
#绑定的端口
port: 27018
replication:
#副本集的名称
replSetName: myshardrs01
sharding:
#分片角色
clusterRole: shardsvr
sharding.clusterRole：
注意：
设置sharding.clusterRole需要mongod实例运行复制。 要将实例部署为副本集成员，请使用
replSetName设置并指定副本集的名称。
启动第一套副本集：一主一副本一仲裁，依次启动三个mongod服务，然后在主节点将仲裁节点和副本加入副本集。
第二套副本集
#-----------myshardrs02
mkdir -p /mongodb/sharded_cluster/myshardrs02_27318/log \ &
mkdir -p /mongodb/sharded_cluster/myshardrs02_27318/data/db \ &
mkdir -p /mongodb/sharded_cluster/myshardrs02_27418/log \ &
mkdir -p /mongodb/sharded_cluster/myshardrs02_27418/data/db \ &
mkdir -p /mongodb/sharded_cluster/myshardrs02_27518/log \ &
mkdir -p /mongodb/sharded_cluster/myshardrs02_27518/data/db
配置文件，需要修改副本集名称：
systemLog:
#MongoDB发送所有日志输出的目标指定为文件
destination: file
#mongod或mongos应向其发送所有诊断日志记录信息的日志文件的路径
path: "/mongodb/sharded_cluster/myshardrs01_27018/log/mongod.log"
#当mongos或mongod实例重新启动时，mongos或mongod会将新条目附加到现有日志文件的末尾。
logAppend: true
storage:
#mongod实例存储其数据的目录。storage.dbPath设置仅适用于mongod。
dbPath: "/mongodb/sharded_cluster/myshardrs01_27018/data/db"
journal:
#启用或禁用持久性日志以确保数据文件保持有效和可恢复。
enabled: true
processManagement:
#启用在后台运行mongos或mongod进程的守护进程模式。
fork: true
#指定用于保存mongos或mongod进程的进程ID的文件位置，其中mongos或mongod将写入其PID
pidFilePath: "/mongodb/sharded_cluster/myshardrs01_27018/log/mongod.pid"
net:
#服务实例绑定所有IP，有副作用，副本集初始化的时候，节点名字会自动设置为本地域名，而不是ip
#bindIpAll: true
#服务实例绑定的IP
bindIp: localhost,192.168.0.2
#bindIp
#绑定的端口
port: 27018
replication:
#副本集的名称
replSetName: myshardrs02
sharding:
#分片角色
clusterRole: shardsvr
启动第二套副本集：一主一副本一仲裁
配置节点副本集的创建
#-----------configrs
#建立数据节点data和日志目录
mkdir -p /mongodb/sharded_cluster/myconfigrs_27019/log \ &
mkdir -p /mongodb/sharded_cluster/myconfigrs_27019/data/db \ &
mkdir -p /mongodb/sharded_cluster/myconfigrs_27119/log \ &
mkdir -p /mongodb/sharded_cluster/myconfigrs_27119/data/db \ &
mkdir -p /mongodb/sharded_cluster/myconfigrs_27219/log \ &
mkdir -p /mongodb/sharded_cluster/myconfigrs_27219/data/db
配置文件：
systemLog:
#MongoDB发送所有日志输出的目标指定为文件
destination: file
#mongod或mongos应向其发送所有诊断日志记录信息的日志文件的路径
path: "/mongodb/sharded_cluster/myconfigrs_27019/log/mongod.log"
#当mongos或mongod实例重新启动时，mongos或mongod会将新条目附加到现有日志文件的末尾。
logAppend: true
storage:
#mongod实例存储其数据的目录。storage.dbPath设置仅适用于mongod。
dbPath: "/mongodb/sharded_cluster/myconfigrs_27019/data/db"
journal:
#启用或禁用持久性日志以确保数据文件保持有效和可恢复。
enabled: true
processManagement:
#启用在后台运行mongos或mongod进程的守护进程模式。
fork: true
#指定用于保存mongos或mongod进程的进程ID的文件位置，其中mongos或mongod将写入其PID
pidFilePath: "/mongodb/sharded_cluster/myconfigrs_27019/log/mongod.pid"
net:
#服务实例绑定所有IP
#bindIpAll: true
#服务实例绑定的IP
bindIp: localhost,192.168.0.2
#绑定的端口
port: 27019
replication:
replSetName: myconfigrs
sharding:
clusterRole: configsvr
启动配置副本集：一主两副本
myshardrs01:PRIMARY> rs.add("180.76.159.126:27119")
myshardrs01:PRIMARY> rs.add("180.76.159.126:27219")
路由节点的创建和操作
第一个路由节点的创建和连接
配置文件：
systemLog:
#MongoDB发送所有日志输出的目标指定为文件
destination: file
#mongod或mongos应向其发送所有诊断日志记录信息的日志文件的路径
path: "/mongodb/sharded_cluster/mymongos_27017/log/mongod.log"
#当mongos或mongod实例重新启动时，mongos或mongod会将新条目附加到现有日志文件的末尾。
logAppend: true
processManagement:
#启用在后台运行mongos或mongod进程的守护进程模式。
fork: true
#指定用于保存mongos或mongod进程的进程ID的文件位置，其中mongos或mongod将写入其PID
pidFilePath: /mongodb/sharded_cluster/mymongos_27017/log/mongod.pid"
net:
#服务实例绑定所有IP，有副作用，副本集初始化的时候，节点名字会自动设置为本地域名，而不是ip
#bindIpAll: true
#服务实例绑定的IP
bindIp: localhost,192.168.0.2
#bindIp
#绑定的端口
port: 27017
sharding:
#指定配置节点副本集
configDB:
myconfigrs/180.76.159.126:27019,180.76.159.126:27119,180.76.159.126:27219
启动mongos：
/usr/local/mongodb/bin/mongos -f /mongodb/sharded_cluster/mymongos_27017/mongos.conf
在路由节点上进行分片配置操作
使用命令添加分片：
（1）添加分片：
语法：
sh.addShard("IP:Port")
mongos>
sh.addShard("myshardrs01/192.168.0.2:27018,180.76.159.126:27118,180.76.159.126:2
7218")
{
"shardAdded" : "myshardrs01",
"ok" : 1,
"operationTime" : Timestamp(1564611970, 4),
"$clusterTime" : {
"clusterTime" : Timestamp(1564611970, 4),
"signature" : {
"hash" : BinData(0,"AAAAAAAAAAAAAAAAAAAAAAAAAAA="),
"keyId" : NumberLong(0)
}
}
}
查看分片状态情况：
mongos> sh.status()
继续将第二套分片副本集添加进来：
sh.addShard("myshardrs02/192.168.0.2:27318,180.76.159.126:27418,180.76.159.126:27518")
提示：如果添加分片失败，需要先手动移除分片，检查添加分片的信息的正确性后，再次添加分片。
移除分片参考(了解)：
use admin
db.runCommand( { removeShard: "myshardrs02" } )
（2）开启分片功能：sh.enableSharding(“库名”)、sh.shardCollection(“库名.集合名”,{“key”:1})
在mongos上的articledb数据库配置sharding:
mongos> sh.enableSharding("articledb")
{
"ok" : 1,
"operationTime" : Timestamp(1564612296, 5),
"$clusterTime" : {
"clusterTime" : Timestamp(1564612296, 5),
"signature" : {
"hash" : BinData(0,"AAAAAAAAAAAAAAAAAAAAAAAAAAA="),
"keyId" : NumberLong(0)
}
}
}
（3）集合分片
对集合分片，你必须使用 sh.shardCollection() 方法指定集合和分片键。
语法：
sh.shardCollection(namespace, key, unique)
参数：
对集合进行分片时,你需要选择一个 片键（Shard Key） , shard key 是每条记录都必须包含的,且建立了
索引的单个字段或复合字段,MongoDB按照片键将数据划分到不同的 数据块 中,并将 数据块 均衡地分布
到所有分片中.为了按照片键划分数据块,MongoDB使用 基于哈希的分片方式（随机平均分配）或者基
于范围的分片方式（数值大小分配） 。
用什么字段当片键都可以，如：nickname作为片键，但一定是必填字段。
分片规则一：哈希策略
对于 基于哈希的分片 ,MongoDB计算一个字段的哈希值,并用这个哈希值来创建数据块.
在使用基于哈希分片的系统中,拥有”相近”片键的文档 很可能不会 存储在同一个数据块中,因此数据的分离性更好一些.
使用nickname作为片键，根据其值的哈希值进行数据分片
mongos> sh.shardCollection("articledb.comment",{"nickname":"hashed"})
查看分片状态：sh.status()
分片规则二：范围策略
对于 基于范围的分片 ,MongoDB按照片键的范围把数据分成不同部分.假设有一个数字的片键:想象一个
从负无穷到正无穷的直线,每一个片键的值都在直线上画了一个点.MongoDB把这条直线划分为更短的不
重叠的片段,并称之为 数据块 ,每个数据块包含了片键在一定范围内的数据.
在使用片键做范围划分的系统中,拥有”相近”片键的文档很可能存储在同一个数据块中,因此也会存储在同
一个分片中.
如使用作者年龄字段作为片键，按照点赞数的值进行分片：
mongos> sh.shardCollection("articledb.author",{"age":1})
注意的是：
1）一个集合只能指定一个片键，否则报错。
2）一旦对一个集合分片，分片键和分片值就不可改变。 如：不能给集合选择不同的分片键、不能更新
分片键的值。
3）根据age索引进行分配数据。
基于范围的分片方式与基于哈希的分片方式性能对比：
基于范围的分片方式提供了更高效的范围查询,给定一个片键的范围,分发路由可以很简单地确定哪个数
据块存储了请求需要的数据,并将请求转发到相应的分片中.
不过,基于范围的分片会导致数据在不同分片上的不均衡,有时候,带来的消极作用会大于查询性能的积极
作用.比如,如果片键所在的字段是线性增长的,一定时间内的所有请求都会落到某个固定的数据块中,最终
导致分布在同一个分片中.在这种情况下,一小部分分片承载了集群大部分的数据,系统并不能很好地进行
扩展.
与此相比,基于哈希的分片方式以范围查询性能的损失为代价,保证了集群中数据的均衡.哈希值的随机性
使数据随机分布在每个数据块中,因此也随机分布在不同分片中.但是也正由于随机性,一个范围查询很难
确定应该请求哪些分片,通常为了返回需要的结果,需要请求所有分片.
如无特殊情况，一般推荐使用 Hash Sharding。
而使用 _id 作为片键是一个不错的选择，因为它是必有的，你可以使用数据文档 _id 的哈希作为片键。
这个方案能够是的读和写都能够平均分布，并且它能够保证每个文档都有不同的片键所以数据块能够很
精细。
似乎还是不够完美，因为这样的话对多个文档的查询必将命中所有的分片。虽说如此，这也是一种比较
好的方案了。
理想化的 shard key 可以让 documents 均匀地在集群中分布：
显示集群的详细信息：
mongos> db.printShardingStatus()
查看均衡器是否工作（需要重新均衡时系统才会自动启动，不用管它）：
mongos> sh.isBalancerRunning()
false
查看当前Balancer状态：
mongos> sh.getBalancerState()
true
再增加一个路由节点
保持配置节点不变：
configDB:
myconfigrs/180.76.159.126:27019,180.76.159.126:27119,180.76.159.126:27219
启动mongos2：
/usr/local/mongodb/bin/mongos -f /mongodb/sharded_cluster/mymongos_27117/mongos.conf
使用mongo客户端登录27117，发现，第二个路由无需配置，因为分片配置都保存到了配置服务器中
了。
连接分片集群
# 连接副本集字符串
uri:mongodb://180.76.159.126:27017,180.76.159.126:27018,180.76.159.126:27019/article
db?connect=replicaSet&slaveOk=true&replicaSet=myrs
#连接路由字符串
uri: mongodb://180.76.159.126:27017,180.76.159.126:27117/articledb
清除所有的节点数据（备用）
如果在搭建分片的时候有操作失败或配置有问题，需要重新来过的，可以进行如下操作：
rm -rf /mongodb/sharded_cluster/myconfigrs_27019/data/db/*.* \ &
rm -rf /mongodb/sharded_cluster/myconfigrs_27119/data/db/*.* \ &
rm -rf /mongodb/sharded_cluster/myconfigrs_27219/data/db/*.* \ &
rm -rf /mongodb/sharded_cluster/myshardrs01_27018/data/db/*.* \ &
rm -rf /mongodb/sharded_cluster/myshardrs01_27118/data/db/*.* \ &
rm -rf /mongodb/sharded_cluster/myshardrs01_27218/data/db/*.* \ &
rm -rf /mongodb/sharded_cluster/myshardrs02_27318/data/db/*.* \ &
rm -rf /mongodb/sharded_cluster/myshardrs02_27418/data/db/*.* \ &
rm -rf /mongodb/sharded_cluster/myshardrs02_27518/data/db/*.* \ &
rm -rf /mongodb/sharded_cluster/mymongos_27017/data/db/*.* \ &
rm -rf /mongodb/sharded_cluster/mymongos_27117/data/db/*.*
然后，查看有问题的配置文件，修改后重新启动，进行上述流程
安全认证
默认情况下，MongoDB实例启动运行时是没有启用用户访问权限控制的，也就是说，在实例本机服务
器上都可以随意连接到实例进行各种操作，MongoDB不会对连接客户端进行用户验证，这是非常危险
的。
为了能保障mongodb的安全可以做以下几个步骤：
1）使用新的端口，默认的27017端口如果一旦知道了ip就能连接上，不太安全。
2）设置mongodb的网络环境，最好将mongodb部署到公司服务器内网，这样外网是访问不到的。公
司内部访问使用等。
3）开启安全认证。认证要同时设置服务器之间的内部认证方式，同时要设置客户端连接到集群的账号
密码认证方式。
为了强制开启用户访问控制(用户验证)，则需要在MongoDB实例启动时使用选项 --auth 或在指定启动
配置文件中添加选项 auth=true 。
1）启用访问控制：
MongoDB使用的是基于角色的访问控制(Role-Based Access Control,RBAC)来管理用户对实例的访问。
通过对用户授予一个或多个角色来控制用户访问数据库资源的权限和数据库操作的权限，在对用户分配
角色之前，用户无法访问实例。
在实例启动时添加选项 --auth 或指定启动配置文件中添加选项 auth=true 。
2）角色：
在MongoDB中通过角色对用户授予相应数据库资源的操作权限，每个角色当中的权限可以显式指定，
也可以通过继承其他角色的权限，或者两都都存在的权限。
3）权限：
权限由指定的数据库资源(resource)以及允许在指定资源上进行的操作(action)组成。
- 资源(resource)包括：数据库、集合、部分集合和集群；
- 操作(action)包括：对资源进行的增、删、改、查(CRUD)操作。
在角色定义时可以包含一个或多个已存在的角色，新创建的角色会继承包含的角色所有的权限。在同一
个数据库中，新创建角色可以继承其他角色的权限，在 admin 数据库中创建的角色可以继承在其它任意
数据库中角色的权限。
关于角色权限的查看，可以通过如下命令查询（了解）：
// 查询所有角色权限(仅用户自定义角色)
> db.runCommand({ rolesInfo: 1 })
// 查询所有角色权限(包含内置角色)
> db.runCommand({ rolesInfo: 1, showBuiltinRoles: true })
// 查询当前数据库中的某角色的权限
> db.runCommand({ rolesInfo: "" })
// 查询其它数据库中指定的角色权限
> db.runCommand({ rolesInfo: { role: "" , db: "" } }
// 查询多个角色权限
> db.runCommand(
{
rolesInfo: [
"" ,
{ role: "" , db: "" },
...
]
}
)
常用的内置角色
- 数据库用户角色：read、readWrite;
- 所有数据库用户角色：readAnyDatabase、readWriteAnyDatabase、userAdminAnyDatabase、dbAdminAnyDatabase
- 数据库管理角色：dbAdmin、dbOwner、userAdmin；
- 集群管理角色：clusterAdmin、clusterManager、clusterMonitor、hostManager；
- 备份恢复角色：backup、restore；
- 超级用户角色：root
- 内部角色：system
角色说明：
单实例环境
如果一旦是因为数据损坏，则需要进行如下操作（了解）：
# 删除lock文件：
rm -f /mongodb/single/data/db/*.lock
# 修复数据：
/usr/local/mongodb/bin/mongod --repair --dbpath=/mongodb/single/data/db
标准的关闭方法（数据不容易出错，但麻烦）：
//客户端登录服务，注意，这里通过localhost登录，如果需要远程登录，必须先登录认证才行。
mongo --port 27017
//#切换到admin库
use admin
//关闭服务
db.shutdownServer()
添加用户和权限
创建两个管理员用户，一个是系统的超级管理员 myroot ，一个是admin库的管理用户myadmin ：
//切换到admin库
> use admin
//创建系统超级用户 myroot,设置密码123456，设置角色root
//> db.createUser({user:"myroot",pwd:"123456",roles:[ { "role" : "root", "db" :"admin" } ]})
//或
> 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")
true
> db.system.users.find()
//修改密码
> db.changeUserPassword("myroot", "123456")
1）本案例创建了两个用户，分别对应超管和专门用来管理用户的角色，事实上，你只需要一个用户即
可。如果你对安全要求很高，防止超管泄漏，则不要创建超管用户。
2）和其它数据库（MySQL）一样，权限的管理都差不多一样，也是将用户和权限信息保存到数据库对
应的表中。Mongodb存储所有的用户信息在admin 数据库的集合system.users中，保存用户名、密码和数据库信息。
3）如果不指定数据库，则创建的指定的权限的用户在所有的数据库上有效，如 {role:“userAdminAnyDatabase”, db:“”}
测试添加的用户是否正确：
//切换到admin
> use admin
//密码输错
> db.auth("myroot","12345")
Error: Authentication failed.
0
//密码正确
> db.auth("myroot","123456")
1
创建普通用户可以在没有开启认证的时候添加，也可以在开启认证之后添加，但开启认证之后，必须使
用有操作admin库的用户登录认证后才能操作。底层都是将用户信息保存在了admin数据库的集合system.users中。
//创建(切换)将来要操作的数据库articledb,
> use articledb
switched to db articledb
//创建用户，拥有articledb数据库的读写权限readWrite，密码是123456
> db.createUser({user: "bobo", pwd: "123456", roles: [{ role: "readWrite", db:
"articledb" }]})
//> db.createUser({user: "bobo", pwd: "123456", roles: ["readWrite"]})
//测试是否可用
> db.auth("bobo","123456")
如果开启了认证后，登录的客户端的用户必须使用admin库的角色，如拥有root角色的myadmin用
户，再通过myadmin用户去创建其他角色的用户。
服务端开启认证和客户端连接登录
在mongod.conf配置文件中加入：
security:
#开启授权认证
authorization: enabled
连接时直接认证：
/usr/local/mongodb/bin/mongo --host 180.76.159.126 --port 27017 --authenticationDatabase admin -u myroot -p 123456
对articledb数据库进行登录认证和相关操作：
/usr/local/mongodb/bin/mongo --host 180.76.159.126 --port 27017 --authenticationDatabase articledb -u bobo -p 123456
提示：
- -u ：用户名
- -p ：密码
- –authenticationDatabase ：指定连接到哪个库。当登录是指定用户名密码时，必须指定对应的数据库！
uri连接：
uri: mongodb://bobo:[email protected]:27017/articledb