瞧一瞧！这儿实现了MongoDB的增量备份与还原（含部署代码）

酸菜没窖养 發表於 2018-11-8 01:43:00

瞧一瞧！这儿实现了MongoDB的增量备份与还原（含部署代码）

<h2>一需求描述</h2>
我们知道数据是公司的重要资产，业务的系统化、信息化就是数字化。数据高效的存储与查询是系统完善和优化的方向，而数据库的稳定性、可靠性是实现的基础。高可用和RPO（RecoveryPointObjective，复原点目标，指能容忍的最大数据丢失量）是衡量一个数据库优劣的重要指标。作为一个DBA，搭建数据库可靠性体系时，一定会要考虑对数据库进行容灾备份。例如，SQL Server类型的数据库，我们一定会部署作业，定期进行完整备份、差异备份和日志备份；MySQL 数据库同样如此，也是定期进行完整备份、binlog备份等。
可能很多公司的DBA认为自己的数据库已采用了新的高可用方案，是多结点冗余了，不再需要冗余备份了，例如SQL Server 的AlwaysOn，MySQL的MHA。可是，我们还是要强调两点。
1.墨菲定律：如果有两种或两种以上的方式去做某件事情，而其中一种选择方式将导致灾难，则必定有人会做出这种选择。
过往无数的惨痛教训说明，将损失放大的原因就是备份数据也损坏了（大家不重视，实际上很可能就没做）。
2.容灾备份不仅仅可以解决物理故障，还可以将一些其它误操作回滚，将数据的损害降至最低。
数据容灾备份是为数据的灾难恢复加固了最后一道保障墙。
国务院信息化工作办公室领导编制的《重要信息系统灾难恢复指南》也对灾难恢复能力等级做了详细划分。
 
<table border="1" cellspacing="0" cellpadding="0">
<tbody>
<tr>
<td style="text-align: center" valign="top" width="139">
     灾难恢复能力等级
</td>
<td style="text-align: center" valign="top" width="180">
RTO
</td>
<td style="text-align: center" valign="top" width="204">
                     RPO
</td>
</tr>
<tr>
<td valign="top" width="139">
1
</td>
<td valign="top" width="180">
2天以上
</td>
<td valign="top" width="204">
1天至7天
</td>
</tr>
<tr>
<td valign="top" width="139">
2
</td>
<td valign="top" width="180">
24小时以后
</td>
<td valign="top" width="204">
1天至7天
</td>
</tr>
<tr>
<td valign="top" width="139">
3
</td>
<td valign="top" width="180">
12小时以上
</td>
<td valign="top" width="204">
数小时至1天
</td>
</tr>
<tr>
<td valign="top" width="139">
4
</td>
<td valign="top" width="180">
数小时至2天
</td>
<td valign="top" width="204">
数小时至1天
</td>
</tr>
<tr>
<td valign="top" width="139">
5
</td>
<td valign="top" width="180">
数分钟至2天
</td>
<td valign="top" width="204">
0至30分钟
</td>
</tr>
<tr>
<td valign="top" width="139">
6
</td>
<td valign="top" width="180">
数分钟
</td>
<td valign="top" width="204">
0
</td>
</tr>
</tbody>
</table>
 
随着MongoDB使用的越来越普及，存储的数据越来越重要，对其进行定期备份很有必要。现在业内普遍流行的做法是每天定时进行一次全库备份，出故障时，进行全库还原。但是一天一次的备份，很难保证恢复后的数据时效性，RPO较差，会有几个小时的数据丢失。例如，每天5点进行完整备份，如果故障点是晚上20:00,那么就会丢失15个小时的数据。对比上面的“灾难恢复能力等级“”列表，会发现，我们的灾难能力等级比较低。
如果每小时做一次全部备份，那么对存储空间的要求较高，还有就是对性能也会有影响。所以，探究Mongodb的增量备还与原很有必要！！！
<h2>二原理说明</h2>
关系型数据库，例如MySQL ,SQL Server 都有事务日志（或bin log），会将数据库的DML 、DDL、DCL等操作记录在事务文件中,可以通过日志备份来搭建增量容灾还原体系。MongoDB没有此类机制和数据文件，难以实现。但是MongoDB副本集有通过oplog（位于local数据库oplog.rs集合中）实现节点间的同步，此集合记录了整个mongod实例在一段时间内的所有变更（插入/更新/删除）操作。基于此，是否可以考虑通过oplog.rs集合的备份还原来实现实例的增量备份与增量还原。
查看mongodb备份命令Mongodump，其中有一个相关参数oplog。
Mongodump 中--oplog参数
<table border="0" cellspacing="0" cellpadding="0">
<tbody>
<tr>
<td valign="top" width="277">
参数
</td>
<td valign="top" width="277">
参数说明
</td>
</tr>
<tr>
<td valign="top" width="277">
--oplog
</td>
<td valign="top" width="277">
Use oplog for taking a point-in-time snapshot
</td>
</tr>
</tbody>
</table>
 
该参数的主要作用是在导出库集合数据的同时生成一个oplog.bson文件，里面存放了开始进行dump到dump结束之间所有的op log 操作。
<img src="https://img2018.cnblogs.com/blog/780228/201810/780228-20181022204059487-1011211891.png">
 
注意：--oplog选项只对全库导出有效。
相应的 Mongorestore 中与 Oplog 相关的参数
<table border="0" cellspacing="0" cellpadding="0">
<tbody>
<tr>
<td style="text-align: center" valign="top" width="189">
参数
</td>
<td style="text-align: center" valign="top" width="365">
参数说明
</td>
</tr>
<tr>
<td style="text-align: center" valign="top" width="189">
oplogReplay
</td>
<td valign="top" width="365">
replay oplog for point-in-time restore
</td>
</tr>
<tr>
<td style="text-align: center" valign="top" width="189">
oplogLimit
</td>
<td valign="top" width="365">
only include oplog entries before the provided Timestamp
</td>
</tr>
<tr>
<td style="text-align: center" valign="top" width="189">
oplogFile
</td>
<td valign="top" width="365">
oplog file to use for replay of oplog
 
</td>
</tr>
</tbody>
</table>
 
 仔细观察oplogReplay参数下的还原过程，我们发现，是先还原数据库文件，再重放还原oplog.bson种的数据。这就启发了我们，如果还原路径下，只有oplog.bson文件，没有数据库备份文件，是不是只进行重放还原操作。如此，如果oplog.bson中记录都是上次备份后的变化操作（op log），还原oplog.bson就可以实现了增量还原。考虑到副本集的变化操作（op log）保存在oplog.rs集合中，只要连续从oplog.rs导出操作的相关数据进行备份，就可以实现增量备份。
即理论上，从oplog.rs导出的数据完全可以替代mongodump过程中产生的oplog.bson，进行增量还原。
实际生产中经过多次验证，也是完全可以。
-----具体原理及验证内容还可参考本人博客 --https://www.cnblogs.com/xuliuzai/p/9832333.html
<h2>三代码实现【重点推荐】</h2>
在容灾体系建设中，既有全库的完整备份也有增量备份。下面是我们的实现代码，因为MongoDB多是在Linux系统下部署，所以这些备份代码都是通过shell语言实现。这些代码大家只要稍微改动，调整部分参数，即可部署应用。
1. 实现完整（全库）备份的代码
<div class="cnblogs_code">
<pre>#!/bin/bash
sourcepath='/data/mongodb/mongobin344/bin'
targetpath='/data/mongodb_back/bkXXX_2XXXX'
nowtime=$(date "+%Y%m%d")
start()
{
${sourcepath}/mongodump --host 172.XXX.XXX.XXX --port 2XXXX -u 用户名-p "密码" --oplog --gzip --authenticationDatabase "admin" --out ${targetpath}/${nowtime}
}
execute()
{

echo "================================ $(date) bakXXX 2XXXX mongodb back start${nowtime}========="

start
if [ $? -eq 0 ]
then
echo "The MongoDB BackUp Successfully!"
else "The MongoDB BackUp Failure"
fi
}
if [ ! -d "${targetpath}/${nowtime}/" ]
then
mkdir ${targetpath}/${nowtime}
fi
execute

baktime=$(date -d '-3 days' "+%Y%m%d")
if [ -d "${targetpath}/${baktime}/" ]
then
rm -rf "${targetpath}/${baktime}/"
echo "=======${targetpath}/${baktime}/===删除完毕=="
fi

echo "================================ $(date) bakXXX 2XXXX mongodb back end ${nowtime}========="</pre>
</div>
 
代码说明：
1.完整备份的脚本，通过crontab触发执行，每天执行一次。
2.备份完整后，会将三天前的备份文件自动删除。
3.sourcepath 定义了MongoDB 运行程序所在路径；targetpath定义了归档文件存放的文件夹（请提前创建）。
 
2. 实现增量备份的代码
 
<div class="cnblogs_code">
<pre>#
# This file is used by cron to Backup the data of oplog collection,the collection is part of local DB.
# The oplog (operations log) is a special capped collection that keeps a rolling record of all operations
# that modify the data stored in your databases.All replica set members contain a copy of the oplog,
# in the local.oplog.rs collection, which allows them to maintain the current state of the database.
# Each operation in the oplog is idempotent. That is, oplog operations produce the same results
# whether applied once or multiple times to the target dataset.
#
# We backup the collections by periodicity to restore the DBin case ofDB disaster
# The version is defined V.001
# Version ModifyTime ModifyBy Desc
# Ver001 2018-11-06 17:00 xuchangpei Create the Scripts File
#
#
#!/bin/bash

#### 请在此处输入关键参数，例如程序路径，账号，密码，实例端口###
command_linebin="/data/mongodb/mongobin344/bin/mongo"
username="用户名"
password="用户命名"
port="mongo都被的端口号"
####
####comments0 start 第一次运行此脚本时，自动检查创建备份路径 ####
if [ ! -d "/data/mongodb_back/mongodboplog_back/mongo$port" ]
then
mkdir -p /data/mongodb_back/mongodboplog_back/mongo$port
fi

if [ ! -d "/data/mongodb_back/mongodboplog_back/log/$port" ]
then
mkdir -p /data/mongodb_back/mongodboplog_back/log/$port
fi

bkdatapath=/data/mongodb_back/mongodboplog_back/mongo$port
bklogpath=/data/mongodb_back/mongodboplog_back/log/$port

####comments end ##

logfilename=$(date -d today +"%Y%m%d")

echo "===================================Message --=MongoDB 端口为" $port "的差异备份开始，开始时间为" $(date -d today +"%Y%m%d%H%M%S") >> $bklogpath/$logfilename.log

ParamBakEndDate=$(date +%s)
echo "Message --本次备份时间参数中的结束时间为：" $ParamBakEndDate >> $bklogpath/$logfilename.log

DiffTime=$(expr 65 \* 60)

echo "Message --备份设置的间隔时间为：" $DiffTime >> $bklogpath/$logfilename.log

ParamBakStartDate=$(expr $ParamBakEndDate - $DiffTime)
echo "Message --本次备份时间参数中的开始时间为：" $ParamBakStartDate >> $bklogpath/$logfilename.log

bkfilename=$(date -d today +"%Y%m%d%H%M%S")

#### comments1 start 获取数据库中oplog记录的开始范围，防止导出的数据不完整 ####

command_line="${command_linebin} localhost:$port/admin -u$username -p$password"

opmes=$(/bin/echo "db.printReplicationInfo()" | $command_line --quiet)

echo $opmes > opdoctime$port.tmplog

opbktmplogfile=opdoctime$port.tmplog

#opstartmes=$(grep "oplog first event time" $opmes)

opstartmes=$(grep "oplog first event time" $opbktmplogfile | awk -F 'CST' '{print $1}' | awk -F 'oplog first event time: ''{print $2}' | awk -F ' GMT' '{print $1}')

echo "Message --oplog集合记录的开始时间为："$opstartmes >> $bklogpath/$logfilename.log

oplogRecordFirst=$(date -d "$opstartmes"+%s)

echo "Message --oplog集合记录的开始时间为:" $oplogRecordFirst >> $bklogpath/$logfilename.log

##begin 比较备份参数的开始时间是否在oplog记录的时间范围内
if [ $oplogRecordFirst -le $ParamBakStartDate ]
then
echo "Message --检查设置备份时间合理。备份参数的开始时间在oplog记录的时间范围内。" >> $bklogpath/$logfilename.log
else echo "Fatal Error --检查设置的备份时间不合理合理。备份参数的开始时间不在oplog记录的时间范围内。请调整oplog size或调整备份频率。本次备份可以持续进行，但还原时数据完整性丢失。" >> $bklogpath/$logfilename.log
fi

##end##

#### comments1 end####

## 调整一下命令，将备份的过程打印到log文件中，我们可以从local.oplog.rs导出的文档数据量来评估，一个周期内的操作量，和预估如果恢复可能的耗时

##dumpmsg=$(/data/mongodb/mongobin344/bin/mongodump -h localhost --port $port --authenticationDatabase admin -u$username -p$password -d local -c oplog.rs--query '{ts:{$gte:Timestamp('$ParamBakStartDate',1),$lte:Timestamp('$ParamBakEndDate',9999)}}' -o $bkdatapath/mongodboplog$bkfilename)
 /data/mongodb/mongobin344/bin/mongodump -h localhost --port $port --authenticationDatabase admin -u$username -p$password -d local -c oplog.rs--query '{ts:{$gte:Timestamp('$ParamBakStartDate',1),$lte:Timestamp('$ParamBakEndDate',9999)}}' -o $bkdatapath/mongodboplog$bkfilename >> $bklogpath/$logfilename.log 2>&1

#echo "本次导出的具体信息如下：" $dumpmsg
#echo $dumpmsg >> $bklogpath/$logfilename.log

## 调整结束

#### comments2 start再次检查，防止导出oplog数据过程耗时过长，比如，我们一小时导出一份，每一次循环涵盖65分钟，如果导出执行过程耗时5分钟以上就可能导致导出的数据不完整。####
## 下面的70 是有上面的65+5而得，+5 是允许导出耗时5分钟。这个逻辑有点绕，大家可以测测，这段逻辑看几分钟可以理解通透了。
DiffTime=$(expr 70 \* 60)
AllowMaxDate=$(expr $(date +%s) - $DiffTime)
if [ $AllowMaxDate -le $ParamBakStartDate ]
then
echo "Message --oplog记录导出时间在规定的DiffTime范围内。数据有效" >> $bklogpath/$logfilename.log
else echo "Fatal Error --oplog记录导出时间超出了规定的DiffTime范围。数据完整性等不到保证。请增大DiffTime参数或调整备份频率。" >> $bklogpath/$logfilename.log
fi

#### comments2 end ####

#### comments3 检查备份文件是否已经删除start ####
if [ -d "$bkdatapath/mongodboplog$bkfilename" ]
then
echo "Message --检查此次备份文件已经产生.文件信息为:" $bkdatapath/mongodboplog$bkfilename >> $bklogpath/$logfilename.log
else echo "Fatal Error --备份过程已执行，但是未检测到备份产生的文件，请检查！" >> $bklogpath/$logfilename.log
fi
##### comments3 end ####

#### comments4 start 删除历史备份文件，保留3天，如需调整，请在持续设置
keepbaktime=$(date -d '-3 days' "+%Y%m%d%H")*
if [ -d $bkdatapath/mongodboplog$keepbaktime ]
then
rm -rf $bkdatapath/mongodboplog$keepbaktime
echo "Message -- $bkdatapath/mongodboplog$keepbaktime 删除完毕" >> $bklogpath/$logfilename.log
fi
### comments4 end

echo "============================Message --MongoDB 端口为" $port "的差异备份结束，结束时间为：" $(date -d today +"%Y%m%d%H%M%S") >> $bklogpath/$logfilename.log</pre>
</div>
 
代码说明：
1.增量备份的脚本，也是通过crontab触发执行，以上参数未修改前，建议每小时执行一次。
2.备份完整后，会自动检查文件是否产生，并且会将三天前的备份文件删除。
3.脚本会自动检查备份路径，不存在将自动产生。
4.增量导出中开始时间和结束时间是最重要的参数，并且要对参数的合法性、有效性检查。例如，检查Oplog的记录是否完全涵盖输入的时间，防止出现希望导出08:00--09:00的数据，但是oplog集合中只有08:30--09:00的数据；防止导出过程耗时过长（例如超过定义的5分钟），导致数据不完整。代码中都会对这些异常进行判断和捕获。
 
 2018-11-30 01:48 再次更新，将代码调整如下，主要针对判断增量备份出的oplog数据能否涵盖60分钟。本代码为不小于61分钟，大家可根据需求调整。
 
前面的代码，是通过限制备份时间（要小于5分钟）来做判断的，仔细分析下，oplog是固定集合，大小由oplogsize设置，其覆盖情况有插入量的多少来决定，不是时间来决定。如果短时间有大量的插入就会很快覆盖掉前面的操作，即1分钟的大量操作完全可能会覆盖掉前面20分钟的操作，所以，有可能有这种情况发生，例如，08:00 执行增量备份，备份时间参数命令为06:55---08:00，执行到08:02 结束。但是在08:00 -08:01 期间有大量的写操作，此时oplog中 06:55 --07:10的集合很可能会被新进来的08:00 -08:01覆盖掉了，所以，备份导出的数据数据07:10 之前的数据很有可能是丢失的，不完整的。最保险的办法，还是通过db.printReplicationInfo()检查判断。
所以代码调整如下：
<div class="cnblogs_code">
<pre>#
# This file is used by cron to Backup the data of oplog collection,the collection is part of local DB.
# The oplog (operations log) is a special capped collection that keeps a rolling record of all operations
# that modify the data stored in your databases.All replica set members contain a copy of the oplog,
# in the local.oplog.rs collection, which allows them to maintain the current state of the database.
# Each operation in the oplog is idempotent. That is, oplog operations produce the same results
# whether applied once or multiple times to the target dataset.
#
# We backup the collections by periodicity to restore the DBin case ofDB disaster
# The version is defined V.001
# Version ModifyTime ModifyBy Desc
# Ver001 2018-11-06 17:00 xuchangpei Create the Scripts File
#
#
#!/bin/bash

#### 请在此处输入关键参数，例如程序路径，账号，密码，实例端口###
command_linebin="/data/mongodb/mongobin344/bin/mongo"
username="用户名"
password="用户命名"
port="mongo都被的端口号"
####
####comments0 start 第一次运行此脚本时，自动检查创建备份路径 ####
if [ ! -d "/data/mongodb_back/mongodboplog_back/mongo$port" ]
then
mkdir -p /data/mongodb_back/mongodboplog_back/mongo$port
fi

if [ ! -d "/data/mongodb_back/mongodboplog_back/log/$port" ]
then
mkdir -p /data/mongodb_back/mongodboplog_back/log/$port
fi

bkdatapath=/data/mongodb_back/mongodboplog_back/mongo$port
bklogpath=/data/mongodb_back/mongodboplog_back/log/$port

####comments end ##

logfilename=$(date -d today +"%Y%m%d")

echo "===================================Message --=MongoDB 端口为" $port "的差异备份开始，开始时间为" $(date -d today +"%Y%m%d%H%M%S") >> $bklogpath/$logfilename.log

ParamBakEndDate=$(date +%s)
echo "Message --本次备份时间参数中的结束时间为：" $ParamBakEndDate >> $bklogpath/$logfilename.log

DiffTime=$(expr 65 \* 60)

echo "Message --备份设置的间隔时间为：" $DiffTime >> $bklogpath/$logfilename.log

ParamBakStartDate=$(expr $ParamBakEndDate - $DiffTime)
echo "Message --本次备份时间参数中的开始时间为：" $ParamBakStartDate >> $bklogpath/$logfilename.log

####上文中的DiffTime用来备份前检查oplog 中的数据是否瞒住要求,即最早的一笔数据要满足在 65分钟前,那么备份后应该也要检查一下.防止在备份的过程中有大量的操作,将前面的尚未导出的oplog数据覆盖点. 例如,08:00执行导出,备份前最早的一笔数据要在06:00
####执行完毕后,再次检查oplog中最早的一笔数据,知识要在07:00 之前,在此我们要求在06:59 即 61分钟前.再次增加一个时间参数用来表示备份后,oplog 必须满足的时间要求.参数命名为

DiffTime=$(expr 61 \* 60)
ParamAfterBakRequestStartDate=$(expr $ParamBakEndDate - $DiffTime)
echo "Message --为保证备份的连续性,本次备份后,oplog中的开始时间需小于：" $ParamAfterBakRequestStartDate >> $bklogpath/$logfilename.log
##### end

bkfilename=$(date -d today +"%Y%m%d%H%M%S")

#### comments1 start 获取数据库中oplog记录的开始范围，防止导出的数据不完整 ####

command_line="${command_linebin} localhost:$port/admin -u$username -p$password"

opmes=$(/bin/echo "db.printReplicationInfo()" | $command_line --quiet)

echo $opmes > opdoctime$port.tmplog

opbktmplogfile=opdoctime$port.tmplog

#opstartmes=$(grep "oplog first event time" $opmes)

opstartmes=$(grep "oplog first event time" $opbktmplogfile | awk -F 'CST' '{print $1}' | awk -F 'oplog first event time: ''{print $2}' | awk -F ' GMT' '{print $1}')

echo "Message --oplog集合记录的开始时间为："$opstartmes >> $bklogpath/$logfilename.log

oplogRecordFirst=$(date -d "$opstartmes"+%s)

echo "Message --oplog集合记录的开始时间为:" $oplogRecordFirst >> $bklogpath/$logfilename.log

##begin 比较备份参数的开始时间是否在oplog记录的时间范围内
if [ $oplogRecordFirst -le $ParamBakStartDate ]
then
echo "Message --检查设置备份时间合理。备份参数的开始时间在oplog记录的时间范围内。" >> $bklogpath/$logfilename.log
else echo "Fatal Error --检查设置的备份时间不合理合理。备份参数的开始时间不在oplog记录的时间范围内。请调整oplog size或调整备份频率。本次备份可以持续进行，但还原时数据完整性丢失。" >> $bklogpath/$logfilename.log
fi

##end##

#### comments1 end####

## 调整一下命令，将备份的过程打印到log文件中，我们可以从local.oplog.rs导出的文档数据量来评估，一个周期内的操作量，和预估如果恢复可能的耗时

##dumpmsg=$(/data/mongodb/mongobin344/bin/mongodump -h localhost --port $port --authenticationDatabase admin -u$username -p$password -d local -c oplog.rs--query '{ts:{$gte:Timestamp('$ParamBakStartDate',1),$lte:Timestamp('$ParamBakEndDate',9999)}}' -o $bkdatapath/mongodboplog$bkfilename)

/data/mongodb/mongobin344/bin/mongodump -h localhost --port $port --authenticationDatabase admin -u$username -p$password -d local -c oplog.rs--query '{ts:{$gte:Timestamp('$ParamBakStartDate',1),$lte:Timestamp('$ParamBakEndDate',9999)}}' -o $bkdatapath/mongodboplog$bkfilename >> $bklogpath/$logfilename.log 2>&1

#echo "本次导出的具体信息如下：" $dumpmsg
#echo $dumpmsg >> $bklogpath/$logfilename.log

## 调整结束

#### comments2 start再次检查，防止导出oplog数据过程耗时过长，因oplog是固定集合，如果操作期间有大量的操作，则oplog中新的数据会覆盖掉旧的数据，就可能导致导出的数据不完整，无法保证增量文件间的时间连续性。因此备份后再次检查####
opmes=$(/bin/echo "db.printReplicationInfo()" | $command_line --quiet)
echo $opmes > opdoctime$port.tmplog
opbktmplogfile=opdoctime$port.tmplog
opstartmes=$(grep "oplog first event time" $opbktmplogfile | awk -F 'CST' '{print $1}' | awk -F 'oplog first event time: ''{print $2}' | awk -F ' GMT' '{print $1}')
echo "Message --执行备份后,oplog集合记录的开始时间为："$opstartmes >> $bklogpath/$logfilename.log
oplogRecordFirst=$(date -d "$opstartmes"+%s)
echo "Message --执行备份后,oplog集合记录的开始时间为[时间格式化]:" $oplogRecordFirst >> $bklogpath/$logfilename.log
##begin 比较备份参数的开始时间是否在oplog记录的时间范围内
if [ $oplogRecordFirst -le $ParamAfterBakRequestStartDate ]
then
echo "Message --备份后，检查oplog集合中数据的开始时间，即集合中最早的一笔数据，时间不小于61分钟的时间（即参数 ParamAfterBakRequestStartDate）。这样可以保证每个增量备份含有最近一个小时的全部op操作，满足文件的持续完整性，逐个还原无丢失数据风险。" >> $bklogpath/$logfilename.log
else echo "Fatal Error --备份后，检查oplog集合的涵盖的时间范围过小（小于61min）。设置的备份时间不合理合理，备份后的文件不能完全涵盖最近60分钟的数据。请调整oplog size或调整备份频率。本次备份可以持续进行，但还原时数据完整性丢失。" >> $bklogpath/$logfilename.log
fi
#### comments2 end ####

#### comments3 检查备份文件是否已经删除start ####
if [ -d "$bkdatapath/mongodboplog$bkfilename" ]
then
echo "Message --检查此次备份文件已经产生.文件信息为:" $bkdatapath/mongodboplog$bkfilename >> $bklogpath/$logfilename.log
else echo "Fatal Error --备份过程已执行，但是未检测到备份产生的文件，请检查！" >> $bklogpath/$logfilename.log
fi
##### comments3 end ####

#### comments4 start 删除历史备份文件，保留3天，如需调整，请在持续设置
keepbaktime=$(date -d '-3 days' "+%Y%m%d%H")*
if [ -d $bkdatapath/mongodboplog$keepbaktime ]
then
rm -rf $bkdatapath/mongodboplog$keepbaktime
echo "Message -- $bkdatapath/mongodboplog$keepbaktime 删除完毕" >> $bklogpath/$logfilename.log
fi
### comments4 end

echo "============================Message --MongoDB 端口为" $port "的差异备份结束，结束时间为：" $(date -d today +"%Y%m%d%H%M%S") >> $bklogpath/$logfilename.log</pre>
</div>
（第二份代码尚未大量验证，因为我们的oplogsize设置的较大，oplog数据范围没有小于60分钟的风险。部署的多是前面的第一份代码。但从准确性上来讲，后者要强于前者，待大量验证完善，将逐渐推广。）
<h2>四功能测试验证</h2>
<h3>1. 测试环境</h3>
 
<table style="border: 0 solid rgba(0, 0, 0, 1)" border="0">
<tbody>
<tr>
<td style="text-align: center">Item</td>
<td style="text-align: center">ServerIP</td>
<td style="text-align: center">Port</td>
<td style="text-align: center">User DB</td>
</tr>
<tr>
<td style="text-align: center">源库</td>
<td>172.XXX.XXX.124(Primary)</td>
<td>2XXX30</td>
<td>testoplog</td>
</tr>
<tr>
<td style="text-align: center">备份还原库</td>
<td>172.XXX.XXX.124(Primary)</td>
<td>2XXX20</td>
<td>无</td>
</tr>
</tbody>
</table>
 
<h3>2. 完整备份与还原</h3>
step 1 在备份前，先向数据库testoplog插入部分数据
<img src="https://img2018.cnblogs.com/blog/780228/201811/780228-20181107140223217-1786957581.png">
step 2 完整备份所有的数据库，执行的代码为上面的完整备份代码（保存到执行文件bkoplogtest_2XXX30），打印出执行过程如下截图
<img src="https://img2018.cnblogs.com/blog/780228/201811/780228-20181108004109405-136041771.png">
step 3 还原完整备份，执行的代码和打印执行过程如下：
执行的命令：
/data/mongodb/mongobin344/bin/mongorestore -h 172.XXX.XXX.124 --port 2XXX20  --oplogReplay --authenticationDatabase 认证数据库-u 用户名-p '密码' --gzip /data/mongodb_back/testoplogbackfile/20181107
打印出的执行过程：
<img src="https://img2018.cnblogs.com/blog/780228/201811/780228-20181107163702966-14690828.png">
step 4 检查还原库的情况，检查库（testoplog）、表（testfullbefore01、testfullbefore02、testfullbefore03）是否还原。
<img src="https://img2018.cnblogs.com/blog/780228/201811/780228-20181107164132339-490464559.png">
结论：完整还原后与原库完整备份时数据一致，符合测试预期。
 
<h3> 3. 增量备份与还原</h3>
 
增量备份与还原的测试案例描述
 
<table border="0">
<tbody>
<tr>
<td style="text-align: center">测试案例</td>
<td style="text-align: center">第一次增量备份</td>
<td style="text-align: center">第一次增量还原</td>
<td style="text-align: center">第二次增量备份</td>
<td style="text-align: center">第二次增量还原</td>
</tr>
<tr>
<td style="text-align: center">源库</td>
<td>
备份前，新建集合testdiffbk01
并插入10000笔数据
</td>
<td> 无操作</td>
<td>
备份前，新建集合testdiffbk02
并插入10000笔数据
</td>
<td> 无操作</td>
</tr>
<tr>
<td style="text-align: center">还原库</td>
<td>无操作</td>
<td>
还原后，检查testdiffbk01是否存在
以及数据量
</td>
<td> 无操作</td>
<td>
还原后，检查testdiffbk02是否存在
以及数据量
</td>
</tr>
</tbody>
</table>
 
step 1 第一次增量备份前，向源库中插入测试数据
<img src="https://img2018.cnblogs.com/blog/780228/201811/780228-20181107195340945-1479518009.png">
step 2 第一次执行增量备份（执行增量备份的脚本，代码放置在执行文件mongodb_oplogbacktestoplog2XXXX.sh中）
<h2> <img src="https://img2018.cnblogs.com/blog/780228/201811/780228-20181107195640657-69634870.png"></h2>
step 3 向源库中第二次插入测试数据
<img src="https://img2018.cnblogs.com/blog/780228/201811/780228-20181107195735494-1363116325.png">
step 4 第二次执行增量备份
<img src="https://img2018.cnblogs.com/blog/780228/201811/780228-20181107195842532-1892852197.png">
两次增量备份产生的文件在文件夹 /data/mongodb_back/mongodboplog_back/mongo27230 中，如下图所示：
<img src="https://img2018.cnblogs.com/blog/780228/201811/780228-20181107201351690-1838141352.png">
step 5 将完整备份所在路径下的文件清空，将第一次备份的产生的oplog.rs.bson 文件，copy至此路径下，并重命名为oplog.bson。【即还原第一份增量备份】
清空指令：
<img src="https://img2018.cnblogs.com/blog/780228/201811/780228-20181107201746480-276412176.png">
Copy+ 重命名指令
<img src="https://img2018.cnblogs.com/blog/780228/201811/780228-20181107201906095-1701568728.png">
还原指令：
/data/mongodb/mongobin344/bin/mongorestore -h 172.XXX.XXX.124 --port 2XXX20 --oplogReplay --authenticationDatabase 验证数据库-u 用户名-p '密码' /data/mongodb_back/testoplogbackfile/20181107
 <img src="https://img2018.cnblogs.com/blog/780228/201811/780228-20181107202428767-1159408883.png">
step 7 验证第一次增量还原的数据，验证测试所用的集合testdiffbk01及数据,与原库第一次增量备份时一致，即已正常还原增量。
<img src="https://img2018.cnblogs.com/blog/780228/201811/780228-20181107202604236-848123840.png">
step 8 将完整备份所在路径下的文件清空，将第二次增量备份的产生的oplog.rs.bson 文件，copy至此路径下，并重命名为oplog.bson。【即还原第二份增量备份】
删除指令
<img src="https://img2018.cnblogs.com/blog/780228/201811/780228-20181107202954600-1378468488.png">
copy + 重命名指令
<img src="https://img2018.cnblogs.com/blog/780228/201811/780228-20181107203222465-371929014.png">
还原增量备份的指令【与第一次执行的还原命令完全一样】
/data/mongodb/mongobin344/bin/mongorestore -h 172.XXX.XXX.124 --port 2XXX20  --oplogReplay --authenticationDatabase 验证数据库-u 用户名-p '密码' /data/mongodb_back/testoplogbackfile/20181107
 <img src="https://img2018.cnblogs.com/blog/780228/201811/780228-20181107203518140-506665164.png">
step 9  验证第二次增量还原的数据，验证测试所用的集合testdiffbk02及数据。结论：与原库第二次增量备份时一致，即已正常还原增量。
<img src="https://img2018.cnblogs.com/blog/780228/201811/780228-20181107203709921-1016083591.png">
 此轮测试有完整备份与完整还原，还有两次增量备份月增量，详细演示增量还原方案的可行性和相关代码的可执行性，部署后满足生产所需。
<h2>五注意事项</h2>
一定要在还原完整备份的路径下，还原已备份oplog的增量文件。即先将已还原的完整备份文件删除，再将增量备份产生oplog.rs.bson文件copy至路径下，并且重命名为oplog.bson。
如果是在其他路径下，则报错，主要的错误信息为：
2018-11-06T10:24:51.848+0800 checking for collection data in /data/mongodb_back/bkrcs_test/oplog.bson 2018-11-06T10:24:51.848+0800 Failed: no oplog file to replay; make sure you run mongodump with --oplog
验证测试，完整备份（全库备份）的文件在路径  /XXX/XXXX_back/bkrcs_2XXXX/20181105 下。
如果我们将oplog的增量文件（oplog.rs集合导出的数据）/local/oplog.rs.bson 复制至 /XXX/XXXX_back/bkrcs_test/路径下，并重命名为oplog.bson
执行restore命令报错：
<img src="https://img2018.cnblogs.com/blog/780228/201811/780228-20181106110407701-792560039.png">
如果我们将/local/oplog.rs.bson复制至还原完整备份所在的路径下（ /XXX/XXXX_back/bkrcs_27XXX/20181105），执行restore，测试不再报错。
 <img src="https://img2018.cnblogs.com/blog/780228/201811/780228-20181106111838785-773571071.png">
检查新增数据也已同步过去。
所以，还原时增量备份（oplog）一定要放置完整备份所在的文件夹下（copy前，先将完整备份完结删除）进行还原。
 
本文版权归作者所有，未经作者同意不得转载,谢谢配合！！！
 本文版权归作者所有，未经作者同意不得转载,谢谢配合！！！
本文版权归作者所有，未经作者同意不得转载,谢谢配合！！！ 
来源：https://www.cnblogs.com/xuliuzai/p/9917137.html

頁: [1]

琼殿技术论坛's Archiver

瞧一瞧！这儿实现了MongoDB的增量备份与还原（含部署代码）