MongoDB集群环境部署监控及备份配置
1、环境介绍
MongoDB复制集是一个带有故障转移的主从集群。是从现有的主从模式演变而来，增加了自动故障转移和节点成员自动恢复。MongoDB复制集模式中没有固定的主结点，在启动后，多个服务节点间将自动选举产生一个主结点。该主结点被称为primary，一个或多个从结点被称为secondaries。primary结点基本上就是master结点，不同之处在于primary结点在不同时间可能是不同的服务器。如果当前的主结点失效了，复制集中的其余结点将会试图选出一个新的主结点。
参照下图，本文我们搭建Mongo副本集集群环境
2、环境准备
IP名称主机名安装软件
155.155.1.184masterMongo01MongoDB-hsblog、MongoDB-CDA、MMS-auth-agent
155.155.1.116backup01Mongo02MongoDB-hsblog、MongoDB-CDA、MMS-auth-agent
155.155.2.12backup02Mongo03backup01MongoDB-hsblog、MongoDB-CDA、MMS-auth-agent
155.155.2.13MongoMMSMongoMMSMongo- MMS、MongoDB-MMS、MMS-auth-agent
一共4台服务器,master、backup01、backup02分别安装两个mongoDB-hsblog和MongoDB-CDA数据库，以端口来区分，MongoMMS安装ops工具以及MMS数据库
数据库环境安装参照mongoDB数据库安装部署文档，此处不再展开说明
3、Mongo集群环境搭建
3.1、系统初始化
3.1.1增加主机名映射
在每台服务器下执行下面命令
echo155.155.1.184 Mongo01 >>/etc/hosts
echo155.155.1.116 Mongo02 >>/etc/hosts
echo155.155.2.12 Mongo03 >>/etc/hosts
echo155.155.2.13 MongoMMS >>/etc/hosts
3.1.2开通防火墙端口8080、8081、8443、27017、28017
在每台服务器下执行下面命令
firewall-cmd--zone=public--add-port=8080/tcp--permanent
firewall-cmd--zone=public--add-port=8081/tcp--permanent
firewall-cmd--zone=public--add-port=8443/tcp--permanent
firewall-cmd--zone=public--add-port=27017/tcp--permanent
firewall-cmd--zone=public--add-port=28017/tcp--permanent
firewall-cmd--reload
3.1.3依赖包安装
每台服务器上都要安装
yum install cyrus-sasl cyrus-sasl-gssapi \
cyrus-sasl-plain krb5-libs libcurl net-snmp \
net-snmp-libs openldapopensslxz-libs-y
3.1.4 开启日志文件记录
mongo副本集和mms连接数据库需要开启journal=true的认证，之前做单机是没有开启的，否则后面会进行报错
每台服务器上的每个mongodb.conf都要进行修改
要先关闭mongod进程
/data/mongo/mongodb-hsblog/bin/mongod -shutdown --config /data/mongo/mongodb-hsblog/etc/mongodb.conf
/data/mongo/mongodb-cda/bin/mongod -shutdown --config /data/mongo/mongodb-cda/etc/mongodb.conf
/data/mongo/mongodb-mms/bin/mongod -shutdown --config /data/mongo/mongodb-mms/etc/mongodb.conf
vim /data/mongo/mongodb-mms/etc/mongodb.conf
把journal=false 改成 journal=true 然后启动
3.1.5关闭hugepage服务
官方建议关闭hugepage服务，在每台服务器上都要执行
hugepage服务就是允许hugepage可以动态分配，而不是系统启动时预先分配，对内存消耗很大的服务都不喜欢它.
这个配置会在多个服务上都是坑elasticsearch ，mongodb ,oracle ,官方推荐默认系统初始化就关掉。
临时关闭,重启后失效
echonever > /sys/kernel/mm/transparent_hugepage/enabled
永久关闭
编辑开启加载文件
vim/etc/rc.local
增加下列内容
iftest-f/sys/kernel/mm/transparent_hugepage/enabled;then
echonever > /sys/kernel/mm/transparent_hugepage/enabled
fi
iftest-f/sys/kernel/mm/transparent_hugepage/defrag;then
echonever > /sys/kernel/mm/transparent_hugepage/defrag
fi
授权
chmod+x /etc/rc.local
3.2、集群环境搭建
3.2.1创建集群key认证文件
在master 服务器上执行命令,生成key文件后，然后拷贝到backup01,backup02服务器相同的路径
cd /data/mongo
openssl rand -base64 756 > energy-rc.key
chmod 400 energy-rc.key
scp -r energy-rc.key root@155.155.1.116:/data/mongo/
scp -r energy-rc.key root@155.155.2.12:/data/mongo/
在每台服务器下都执行，把生成的key添加到mongodb.conf配置文件中,开启key认证
echo keyFile=/data/mongo/energy-rc.key >>/data/mongo/mongodb-hsblog/etc/mongodb.conf
echo keyFile=/data/mongo/energy-rc.key >>/data/mongo/mongodb-cda/etc/mongodb.conf
3.2.2在配置文件中增加集群名称
在master、backup01、backup02服务器上执行，命令
echo replSet=rs0 >>/data/mongo/mongodb-hsblog/etc/mongodb.conf
echo replSet=rs1 >>/data/mongo/mongodb-cda/etc/mongodb.conf
增加后需要重新启动数据库生效，在master、backup01、backup02服务器上执行命令
# 关闭数据库
/data/mongo/mongodb-hsblog/bin/mongod -shutdown --config /data/mongo/mongodb-hsblog/etc/mongodb.conf
/data/mongo/mongodb-cda/bin/mongod -shutdown --config /data/mongo/mongodb-cda/etc/mongodb.conf
# 启动数据库
/data/mongo/mongodb-hsblog/bin/mongod --config /data/mongo/mongodb-hsblog/etc/mongodb.conf
/data/mongo/mongodb-cda/bin/mongod --config /data/mongo/mongodb-cda/etc/mongodb.conf
3.2.3在主库上进行集群初始化
启动三台mongo-hsblog数据库
/data/mongo/mongodb-hsblog/bin/mongod --config /data/mongo/mongodb-hsblog/etc/mongodb.conf
在master上进行操作，启动mongo程序
/data/mongo/mongodb-hsblog/bin/mongo 127.0.0.1:27017
输入用户名密码认证
use admin
db.auth("admin","Zaq12wsx")
输入数据库基本配置信息
config = { _id : "configs",
members : [
{_id : 0, host : "155.155.1.184:27017" },
{_id : 1, host : "155.155.1.116:27017" },
{_id : 2, host : "155.155.2.12:27017" }
] }
继续输入初始化命令
rs.initiate( {
_id : "rs0",
members: [
{ _id: 0, host: "155.155.1.184:27017" },
{ _id: 1, host: "155.155.1.116:27017" },
{ _id: 2, host: "155.155.2.12:27017" }
]
})
之后使用exit退出 再重新登录
/data/mongo/mongodb-hsblog/bin/mongo 127.0.0.1:27017
可以看到master服务器上的mongo服务已经变成PRIMARY主节点
输入用户密码认证
use admin
db.auth("admin","Zaq12wsx")
查看集群配置信息
rs.conf()
返回下列内容：
MongoDB Enterprise rs0:PRIMARY> rs.conf()
{
"_id" : "rs0",
"version" : 1,
"term" : 2,
"members" : [
{
"_id" : 0,
"host" : "155.155.1.184:27017",
"arbiterOnly" : false,
"buildIndexes" : true,
"hidden" : false,
"priority" : 1,
"tags" : {
},
"secondaryDelaySecs" : NumberLong(0),
"votes" : 1
},
{
"_id" : 1,
"host" : "155.155.1.116:27017",
"arbiterOnly" : false,
"buildIndexes" : true,
"hidden" : false,
"priority" : 1,
"tags" : {
},
"secondaryDelaySecs" : NumberLong(0),
"votes" : 1
},
{
"_id" : 2,
"host" : "155.155.2.12:27017",
"arbiterOnly" : false,
"buildIndexes" : true,
"hidden" : false,
"priority" : 1,
"tags" : {
},
"secondaryDelaySecs" : NumberLong(0),
"votes" : 1
}
],
"protocolVersion" : NumberLong(1),
"writeConcernMajorityJournalDefault" : true,
"settings" : {
"chainingAllowed" : true,
"heartbeatIntervalMillis" : 2000,
"heartbeatTimeoutSecs" : 10,
"electionTimeoutMillis" : 10000,
"catchUpTimeoutMillis" : -1,
"catchUpTakeoverDelayMillis" : 30000,
"getLastErrorModes" : {
},
"getLastErrorDefaults" : {
"w" : 1,
"wtimeout" : 0
},
"replicaSetId" : ObjectId("62b1eb80013710ba0dd00cf9")
}
}
MongoDB Enterprise rs0:PRIMARY>
查看成员状态信息
rs.status()
返回下列内容
MongoDB Enterprise rs0:PRIMARY> rs.status()
{
"set" : "rs0",
"date" : ISODate("2022-06-21T16:11:45.795Z"),
"myState" : 1,
"term" : NumberLong(2),
"syncSourceHost" : "",
"syncSourceId" : -1,
"heartbeatIntervalMillis" : NumberLong(2000),
"majorityVoteCount" : 2,
"writeMajorityCount" : 2,
"votingMembersCount" : 3,
"writableVotingMembersCount" : 3,
"optimes" : {
"lastCommittedOpTime" : {
"ts" : Timestamp(1655827329, 1),
"t" : NumberLong(-1)
},
"lastCommittedWallTime" : ISODate("2022-06-21T16:02:09.013Z"),
"readConcernMajorityOpTime" : {
"ts" : Timestamp(1655827329, 1),
"t" : NumberLong(-1)
},
"appliedOpTime" : {
"ts" : Timestamp(1655827900, 1),
"t" : NumberLong(2)
},
"durableOpTime" : {
"ts" : Timestamp(1655827900, 1),
"t" : NumberLong(2)
},
"lastAppliedWallTime" : ISODate("2022-06-21T16:11:40.012Z"),
"lastDurableWallTime" : ISODate("2022-06-21T16:11:40.012Z")
},
"lastStableRecoveryTimestamp" : Timestamp(1655827329, 1),
"electionCandidateMetrics" : {
"lastElectionReason" : "electionTimeout",
"lastElectionDate" : ISODate("2022-06-21T16:06:49.952Z"),
"electionTerm" : NumberLong(2),
"lastCommittedOpTimeAtElection" : {
"ts" : Timestamp(1655827329, 1),
"t" : NumberLong(-1)
},
"lastSeenOpTimeAtElection" : {
"ts" : Timestamp(1655827598, 1),
"t" : NumberLong(1)
},
"numVotesNeeded" : 2,
"priorityAtElection" : 1,
"electionTimeoutMillis" : NumberLong(10000),
"numCatchUpOps" : NumberLong(0),
"newTermStartDate" : ISODate("2022-06-21T16:06:50.006Z")
},
"members" : [
{
"_id" : 0,
"name" : "155.155.1.184:27017",
"health" : 1,
"state" : 1,
"stateStr" : "PRIMARY",
"uptime" : 705,
"optime" : {
"ts" : Timestamp(1655827900, 1),
"t" : NumberLong(2)
},
"optimeDate" : ISODate("2022-06-21T16:11:40Z"),
"lastAppliedWallTime" : ISODate("2022-06-21T16:11:40.012Z"),
"lastDurableWallTime" : ISODate("2022-06-21T16:11:40.012Z"),
"syncSourceHost" : "",
"syncSourceId" : -1,
"infoMessage" : "",
"electionTime" : Timestamp(1655827609, 1),
"electionDate" : ISODate("2022-06-21T16:06:49Z"),
"configVersion" : 1,
"configTerm" : 2,
"self" : true,
"lastHeartbeatMessage" : ""
},
{
"_id" : 1,
"name" : "155.155.1.116:27017",
"health" : 1,
"state" : 5,
"stateStr" : "STARTUP2",
"uptime" : 306,
"optime" : {
"ts" : Timestamp(0, 0),
"t" : NumberLong(-1)
},
"optimeDurable" : {
"ts" : Timestamp(0, 0),
"t" : NumberLong(-1)
},
"optimeDate" : ISODate("1970-01-01T00:00:00Z"),
"optimeDurableDate" : ISODate("1970-01-01T00:00:00Z"),
"lastAppliedWallTime" : ISODate("1970-01-01T00:00:00Z"),
"lastDurableWallTime" : ISODate("1970-01-01T00:00:00Z"),
"lastHeartbeat" : ISODate("2022-06-21T16:11:44.008Z"),
"lastHeartbeatRecv" : ISODate("2022-06-21T16:11:44.043Z"),
"pingMs" : NumberLong(0),
"lastHeartbeatMessage" : "",
"syncSourceHost" : "155.155.1.184:27017",
"syncSourceId" : 0,
"infoMessage" : "",
"configVersion" : 1,
"configTerm" : 2
},
{
"_id" : 2,
"name" : "155.155.2.12:27017",
"health" : 1,
"state" : 5,
"stateStr" : "STARTUP2",
"uptime" : 306,
"optime" : {
"ts" : Timestamp(0, 0),
"t" : NumberLong(-1)
},
"optimeDurable" : {
"ts" : Timestamp(0, 0),
"t" : NumberLong(-1)
},
"optimeDate" : ISODate("1970-01-01T00:00:00Z"),
"optimeDurableDate" : ISODate("1970-01-01T00:00:00Z"),
"lastAppliedWallTime" : ISODate("1970-01-01T00:00:00Z"),
"lastDurableWallTime" : ISODate("1970-01-01T00:00:00Z"),
"lastHeartbeat" : ISODate("2022-06-21T16:11:44.510Z"),
"lastHeartbeatRecv" : ISODate("2022-06-21T16:11:44.608Z"),
"pingMs" : NumberLong(0),
"lastHeartbeatMessage" : "",
"syncSourceHost" : "155.155.1.184:27017",
"syncSourceId" : 0,
"infoMessage" : "",
"configVersion" : 1,
"configTerm" : 2
}
],
"ok" : 1
}
MongoDB Enterprise rs0:PRIMARY>
详细说明如下：
"_id" : #集群中节点编号
"name" : #成员服务器名称及端口
"health" : #表示成员中的健康状态（0:down;1:up）
"state" : #为0~10，表示成员的当前状态
"stateStr" : #描述该成员是主库（PRIMARY）还是备库（SECONDARY）
"uptime" : #该成员在线时间（秒）
"optime" : #成员最后一次应用日志(oplog)的信息
"optimeDate" : #成员最后一次应用日志(oplog)的时间
"electionTime" : #当前primary从操作日志中选举信息
"electionDate" : #当前primary被选定为primary的日期
"configVersion" : #mongodb版本
"self" : #为true 表示当前节点
登录其他节点的mongo查看，可以看到节点已经改变
接着我们在cda库的集群上也进行同样的操作（补充）
./mongo 127.0.0.1:28017
#通过验证
use admin
db.auth("admin","SdMgDb_@05");
#输入集群配置信息
config = { _id : "configs",
members : [
{_id : 0, host : "155.155.1.184:28017" },
{_id : 1, host : "155.155.1.116:28017" },
{_id : 2, host : "155.155.2.12:28017" }
] }
#集群初始化配置
rs.initiate( {
_id : "rs1",
members: [
{ _id: 0, host: "155.155.1.184:28017" },
{ _id: 1, host: "155.155.1.116:28017" },
{ _id: 2, host: "155.155.2.12:28017" }
]
})
#退出重新登录
exit
./mongo 127.0.0.1:28017
use admin
db.auth("admin","SdMgDb_@05");
#查看状态
rs.status()
#集群配置信息
rs.conf()
3.2.4集群数据初始化同步说明
集群状态说明，通过上面可以看到，backup01和back02的节点是other，通过用户和密码认证之后可以看到显示为startup02,如下图
状态说明
状态号状态名称释义说明
0STARTUP启动尚未成为任何集群的活跃成员。所有成员都以这种状态启动。 mongod在启动时会解析
1PRIMARY主处于primary状态的成员是唯一可接受写操作的成员。有资格投票。
2SECONDARY辅助处于secondary状态的成员正在复制数据存储。有资格投票。
3RECOVERING恢复成员执行启动自检，或从 完成回滚或重新同步 过渡。有资格投票。
5STARTUP2启动2该成员已加入集群，并且正在运行初始同步。有资格投票。
6UNKNOWN未知从集群中另一个成员的角度看，该成员的状态未知。
7ARBITER仲裁仲裁不复制数据，仅存在于选举中。有资格投票。
8DOWN掉线从该集群的另一个成员看，该成员无法访问。
9ROLLBACK回滚该成员正在积极执行回滚。有资格投票。无法从该成员读取数据。从4.2版开始，当成员进入ROLLBACK状态时，MongoDB将终止所有正在进行的用户操作。
10REMOVED已删除此成员曾经在副本集中，但随后被删除
由于生产环境300多个G的数据存储，startup2代表主库正在和其他成员的库进行数据初始化同步，副本集中的每个数据承载成员都会进入STARTUP2状态这时它将成为副本集中的活跃成员并可以投票。然后，成员决定是否进行初始同步。如果成员开始初始同步，则该成员将保留在STARTUP2中，直到复制所有数据并构建所有索引为止。之后，成员转换为RECOVERING。
当副本集的成员尚未准备好接受读取时，它将进入RECOVERING状态。 RECOVERING状态可能在正常操作期间发生，并不一定反映错误情况。处于RECOVERING状态的成员有资格在选举中投票，但没有资格进入PRIMARY状态。
在复制了足够的数据以保证用于客户端读取的数据的一致视图之后，成员从RECOVERING过渡到SECONDARY。 RECOVERING和SECONDARY状态之间的唯一区别是RECOVERING禁止客户端读取，而SECONDARY允许它们读取。 SECONDARY状态不能保证任何有关主数据过时问题。
此时可以通过命令看到，mongodb的数据存储目录db是一直递增的，证明正在进行数据初始化同步
ll -h | grep total
耐心等待之后，进入mongoshell，可以看到节点状态已经变成SECONDARY，证明集群环境已经恢复正常，可以继续进行集群环境测试
3.2.5集群环境测试
3.2.5.1数据同步测试
使用robo3t工具链接每台mongod,使用robo3t工具链接mongod集群，如图
在主库上增加数据进行测试，选中集合，点击右键，insert document,插入文档，可以看到主库现在已经被推选为2.12服务，所以i我们在2.12上进行新增数据
选中对应的集合，右键点击插入文档
数据内容
{
"updateDate" : ISODate("2021-12-15T13:22:25.950Z"),
"logScecode" : "CheckAppInfoAdd",
"updateBy" : "HIIP",
"logData" : "{\"resourceType\":\"ServiceRequest\",\"meta\":{\"versionId\":\"1\",\"lastUpdated\":\"2021-12-15T21:22:25.996\",\"source\":\"\"},\"identifier\":[{\"use\":\"usual\"}]}",
"logSorcode" : "RIS",
"createDate" : ISODate("2021-12-15T13:22:25.950Z"),
"logTimeMsgout" : ISODate("2021-12-15T13:22:25.997Z"),
"logTarcode" : "TechRM",
"logSeq" : "2",
"logSvcname" : "HIIP_CSB_HL7v3",
"logMsgid" : "SJTBCS0000000000001",
"logRequestid" : "11D08CE2-7B94-49B4-9A0C-2D5C8D8A2372",
"createBy" : "HIIP",
"logTimeMsgin" : ISODate("2021-12-15T13:22:25.950Z")
}
点击save插入数据。
查询展示
db.getCollection('CSBBusinessLog').find({'logMsgid':'SJTBCS0000000000001'})
PRIMARY
SECONDARY
可以看到，在PRIMARY 插入数据后，剩下的两个SECONDARY已经自动同步数据
接下来CDA库的集群我们同样进行如上的测试操作，此处不在展开说明
3.2.5.2高可用测试
接下来我们分别停止PRIMARY 和SECONDARY模拟业务down机情况，查看集群环境是否运行
停止PRIMARY 库测试
在PRIMARY 服务器上操作
/data/mongo/mongodb-hsblog/bin/mongod -shutdown --config /data/mongo/mongodb-hsblog/etc/mongodb.conf
主库已经停止，接下来我们使用工具分别连接集群和单机测试
使用robo3t单机连接测试，可以看到数据库已经连接不上。
使用集群连接，可以看到PRIMARY 已经从2.12变成1.184,数据也可以正常查询显示。
恢复正常环境后，SECONDARY节点down机测试
/data/mongo/mongodb-hsblog/bin/mongod -shutdown --config /data/mongo/mongodb-hsblog/etc/mongodb.conf
通过robo3t工具可以看到SECONDARY节点down机，对集群环境不产生影响
接下来CDA库的集群我们同样进行如上的测试操作，此处不在展开说明
3.2.6推举某个库为主节点（补充）
链接地址：Adjust Priority for Replica Set Member — MongoDB Manual
4、监控工具MMS安装配置
4.1MMS介绍
MMS全称 MongoDB Management Service，MongoDB早期叫法，新版本叫做MongoDB Ops Manager运维管理器，实质上MMS和MongoDB Ops Manager可以理解是一个同一个程序。
MongoDB Ops Manager运维管理器有三个大的功能，自动化、监视、备份。
自动化是指通过配置实现对进行Mongo节点和集群监控、备份、还原、部署等自动化作业。在每个MongoDB主机上使用自动化的MongoDB代理可以维护您的MongoDB部署。您可以安装MongoDB代理。自动化可以以及[部署和升级新的或现有的群集。
监视是指Ops Manager 监控提供有关关键数据库和硬件指标的实时报告、可视化和警报。当在MongoDB主机上激活监控时，监控会从MongoDB部署中的节点收集统计信息。代理将数据库统计信息传输回运维管，实时报告部署状态。您可以对所选指标设置警报。
备份是指Ops Manager Backup提供MongoDB副本集和[分片集群的计划快照和时间点恢复。当为MongoDB部署激活备份时，备份会从您指定的MongoDB进程中获取数据的快照。
本文中后面会用到监视、备份两大功能。
MMS可以理解为Mongo官方基于java开发的一个集自动化、监控、备份功能的一个程序，也是需要连接数据mongo数据库的，建议和要生产库分开，否则后面开启监控后会产生上百个库，容易和生成的搞混。另外MMS的库还存储的有副本集环境的OPLOG相当于归档日志，用于数据恢复。
4.2安装MMS运维管理工具
4.2.1上传MMS的压缩包到/data/mongo/目录下
cd /data/mongo/
对压缩包进行解压,并重命名
tar -zxf mongodb-mms-5.0.11.100.20220602T1040Z-1.x86_64.tar.gz
mv mongodb-mms-5.0.11.100.20220602T1040Z-1.x86_64/ mms
4.2.2生成key文件
到对应路径下运行mms-gen-key程序，运行后会在/etc/se 路径下生成key认证文件，mms进程启动的时候会用到
cd /data/mongo/mms/bin/
ll /etc/mongodb-mms/gen.key
4.2.3配置文件修改
修改数据库链接信息
vim /data/mongo/mms/conf/conf-mms.properties
修改数据库链接信息
增加一行
tlsAllowInvalidCertificates=false
mongo.mongoUri=mongodb://admin:admin1234@127.0.0.1:27017/?maxPoolSize=150&retryWrites=false&retryReads=false
注意此处密码带有特殊符号@ ：/等需要进行转义，否则后面启动mms进程会报空指针异常,官网上有对照说明
4.2.4默认端口修改
mms默认web端口是8080和tomcat端口冲突，修改成8081
编辑文件，找到 BASE_PORT=8080 修改成 BASE_PORT=8081
vim /data/mongo/mms/conf/mms.conf
4.2.6启动MMS
启动会比较占用内存资源，根据服务器性能启动的效率会受影响
cd /data/mongo/mms/bin
# 启动命令
./mongodb-mms start
# 停止命令
./mongodb-mms stop
注意要确认Backup Daemon 备份守护进程是否启动，如果mms连接的是副本集数据库，默认不会启动的，需要手动启动./mongodb-mms-backup-daemon start ，只有mms连接单实例数据库才会跟随mongodb-mms一起启动
4.2.7初始化配置MMS
通过浏览器访问链接,首次登录需要注册账号
http://155.155.2.13:8081/account/login
点击登记注册账号，根据提示输入邮箱账号密码
注册完成登记之后进行运维管理器配置
运维管理器配置需要邮件服务器，如果内网有的话就根据提示配置，如果没有也无妨，因为是必填项就随机填写以下为例,其他的选项给空就可以
URL To Access Ops Manager * http://155.155.2.13:8081/
"From" Email Address * root@localhost
"Reply To" Email Address * root@localhost
Admin Email Address * root@localhost
Email Delivery Method Configuration * SMTP Email Server
Transport * smtp
SMTP Server Hostname * mongo03
SMTP Server Port * 23
接着点击继续加载到下一页,全部默认点击继续
点击继续
点击继续
在mms服务器上创建目录
mkdir -p /opt/mongodb/mms/mongodb-releases/
接着点击继续
以上这些配置，我们用到的时候再从管理页面上进行修改
最后我们进入到web页面
5、MMS-auth-agent安装配置
5.1、MMS-auth-代理介绍配置
MongoDB代理作为单个二进制文件运行，监测、备份、自动化这三个功能都是基于代理实现的。
使用运维管理器 UI 激活监控和/或备份功能。
创建新集群或导入现有集群时激活自动化。
当在MMS启动的实话，会启动一个8443端口用于和其他服务器的mms-auto-agent代理程序进行通讯，收集监控数据，实现备份、自动化传输等功能。
5.2、MMS-auth-代理安装配置
登录运维管理工具MMS，点击代理=> 下载设置=》选择对应的linux版本，我们这里选择linux7的tar版本
他会自动弹出下载安装命令，我们这里根据提示操作
点击这里 下面会生成一个key,这个key只有首次生成的时候会出现，我们要把他记下来
mmsGroupId=62b1b717e36e174a392e01fb
mmsApiKey=62b1bf19e36e174a392e0776a66caab6807f68c27bb705911001873c
mmsBaseUrl=http://155.155.2.13:8081
5.3、通过shell进行安装MMS代理
由于我们需要在每一台装mongo的服务器上进行代理安装配置，此处我们选择用shell在服务器上进行安装
在mms服务器上创建sprict目录用于存放shell
mkdir -p /opt/sprict
vim /opt/sprict/mongo-auth-agent-install
输入下列内容
#! /bin/bash
#下载安装重命名
cd /data/mongo/
curl -OL http://155.155.2.13:8081/download/agent/automation/mongodb-mms-automation-agent-11.0.16.7080-1.rhel7_x86_64.tar.gz >> /data/mongo/mongo-mms-auto-agent-install.log
sleep 2
tar -xvf mongodb-mms-automation-agent-11.0.16.7080-1.rhel7_x86_64.tar.gz >> /data/mongo/mongo-mms-auto-agent-install.log
mv mongodb-mms-automation-agent-11.0.16.7080-1.rhel7_x86_64 mongodb-mms-automation-agent
#修改配置文件
sed -i 's/mmsGroupId=/mmsGroupId=62b1b717e36e174a392e01fb/g' /data/mongo/mongodb-mms-automation-agent/local.config
sed -i 's/mmsApiKey=/mmsApiKey=62b1bf19e36e174a392e0776a66caab6807f68c27bb705911001873c/g' /data/mongo/mongodb-mms-automation-agent/local.config
sed -i 's/mmsBaseUrl=/mmsBaseUrl=http:\/\/155.155.2.13:8081/g' /data/mongo/mongodb-mms-automation-agent/local.config
#创建相关目录
mkdir -p /var/lib/mongodb-mms-automation
mkdir -p /var/log/mongodb-mms-automation-agent
#单词script拼写错误目录调整,后续项目安装调整
mkdir -p /opt/sprict/
#创建启动脚本
echo "#! /bin/bash" >> /opt/sprict/mongo-mms-auto.start
echo "cd /data/mongo/mongodb-mms-automation-agent" >> /opt/sprict/mongo-mms-auto.start
echo "nohup ./mongodb-mms-automation-agent --config=local.config >> /var/log/mongodb-mms-automation-agent/automation-agent-fatal.log 2>&1 &" >> /opt/sprict/mongo-mms-auto.start
chmod +x /opt/sprict/mongo-mms-auto.start
#创建软链接并执行
ln -s /opt/sprict/mongo-mms-auto.start /data/mongo/mongodb-mms-automation-agent/mongo-mms-auto.start
/data/mongo/mongodb-mms-automation-agent/mongo-mms-auto.start >> /data/mongo/mongo-mms-auto-agent-install.log
授予执行权限，并执行
chmod +x /opt/sprict/mongo-auth-agent-install
/opt/sprict/mongo-auth-agent-install
执行完成之后查看mongo进程，可以看到mongodb-mms-automation-agent --config=local.config 已经启动
通过scp 将mms代理安装脚本拷贝到http服务器上，（http服务配置参照《Linux系统yum源软件安装环境配置20220304更新.docx》文档）
scp -r /opt/sprict/mongo-auth-agent-install root@155.155.1.56:/var/www/html/sprictshell/
在master、backup01、backup02服务器上分别执行
curl http://155.155.1.56/sprictshell/mongo-auth-agent-install | bash
ps aux|grep mongodb-mms
5.4通过运维管理工具查看安装的代理服务
代理安装完成之后在页面Servers可以看到安装的代理服务
6、MMS-代理以及备份配置
6.1单机数据库代理配置
点击添加新的=》现有的MongoDB部署，如图
前面已经安装过代理，点击继续
点击继续
输入主机名、mms数据库的端口、选择启用身份验证、申请验证机制选择用户名和密码，输入相对于的数据库用户名和密码，点击继续，耐心等待
提示找到部署之后点击继续
配置完成后可以在servers页面里面看到代理服务上跑的数据库、端口 以及版本信息
点击Processes页面还可以看到监控的数据，包括数据库大小，连接数等
接着点击METRICS可以看到详细的数据库监控
点击页面尾部的+-号指标按钮，可以在增加或者显示相关的指标数据
说明，这些数据都是由通过代理收集后，存储在mongodb-mms库中，同时mongodb也会创建上百个库，来存储这些监控的数据。可以通过robo3t工具进行查看，库比较多此处不在一一列举。
6.2集群数据库代理配置
6.2.1开启集群认证，否则后面无法进行数据库备份作业
依次点击安全、Authenticxxxation & TLS、编辑设置
我们采用5.0.9版本，根据提示 选择第二项 用户名和密码设置，点击下一个
继续点击下一个
勾选代理身份验证机制，其他的都不用操作，点击save
完成之后，可以看到备份身份验证已经开启
6.2.2集群数据库代理及配置
集群数据库代理配置参照单机版本，过程类似，点击添加新的=》现有的MongoDB部署，如图
输入mongo服务的端口设置，点击继续后耐心等待，直到下面提示发现部署后，点击继续按钮
点击继续按钮
这里选择不，只是监视器，自动化需要连接外网的mongo依赖库去下载脚本等。
接下来回到主页面就可以看到集群的配置信息，同样点击过程，也可以看到监控的数据，和单机操作类似。
接下来点击这里，激活监控和激活备份功能，每个代理都要开启。
接下来横幅上面会有操作审查，只有通过审核后功能才能真正开启，我们可以把多个动作一起审查，点击确认和部署
备注此处添加了的代理hsblogdb的集群id为rs0的代理配置，cda集群的代理配置此处不在展开说明。
6.3集群数据库备份配置
6.3.1备份作业创建
在页面上点击连续备份
点击配置备份模块
在mongo-mms服务器上创建目录，并填写上去，点击设置
mkdir -p /data/mongo/heads/
等待找到备份守护程序后，点击启动守护程序
选择配置文件存储系统
在mongomms里面创建目录并填写，点击保存
mkdir -p /data/mongo/heads/fileback
输入mongomms库的连接信息，并点击保存
接下来点击返回项目，再次选择连续备份，点击开始设置，进行定时备份配置
点击 下一个
代理前面已经安装配置成功，我们继续点击下一个
这里选择副本集rs0，点击开始备份
作业已经创建成功
备注此处添加了的代理hsblogdb的集群id为rs0的备份作业创建，cda集群的备份作业创建此处不在展开说明。
6.3.2备份作业配置
如图，依次点击 ... 数据库凭据配置
在右侧弹框中输入要备份库的数据库用户名和密码，点击提交
继续点击快照计划，可以进行快照备份的时间设置
如下图
接下来我们查看备份作业运行情况，点击右上角的admin，依次点击备份、工作、搜索可以看到备份的作业
点击作业时间表可以查看详细的情况
备份作业首次配置完成之后，WT checkpoint 之后默认会进行第一次快照备份，由于生产环境数据量较大，耐心即可。
备注此处添加了的代理hsblogdb的集群id为rs0的备份作业配置，cda集群的备份作业配置此处不在展开说明。
经过一段时间时间再次查看定时任务和OPLOG已经执行
从admin 管理页面进去查看备份作业
7、备份恢复
备份恢复，获取快照有两种方法，一种是通过页面网页进行下载，另外一种方法是去对应存储目录下进行拷贝。紧急情况下第一种方法受限于网络传输效率，通常采用第二种方法，效率高一点。
到对应的MMS服务器的存放快照的目录下
目录说明62b1b717e36e174a392e01fb 是项目的项目id，接下来rs0和rs1是集群的名称,62b322560b5d061415e08046是集群快照的id
cd /data/mongo/heads/fileback/62b1b717e36e174a392e01fb/rs0/62b322560b5d061415e08046/
接下来重新安装配置一个MongoD实例，把/data/mongo/heads/fileback/62b1b717e36e174a392e01fb/rs0/62b322560b5d061415e08046/ 目录下的数据文件拷贝到新安装配置的MongoD实例下的db文件夹，然后启动实例就可以了。
