经验首页 前端设计 程序设计 Java相关 移动开发 数据库/运维 软件/图像 大数据/云计算 其他经验
当前位置:技术经验 » 数据库/运维 » MongoDB » 查看文章
瞧一瞧!这儿实现了MongoDB的增量备份与还原(含部署代码)
来源:cnblogs  作者:东山絮柳仔  时间:2018/11/8 9:40:13  对本文有异议

一 需求描述

我们知道数据是公司的重要资产,业务的系统化、信息化就是数字化。数据高效的存储与查询是系统完善和优化的方向,而数据库的稳定性、可靠性是实现的基础。高可用和RPO(RecoveryPointObjective,复原点目标,指能容忍的最大数据丢失量)是衡量一个数据库优劣的重要指标。作为一个DBA,搭建数据库可靠性体系时,一定会要考虑对数据库进行容灾备份。例如,SQL Server类型的数据库,我们一定会部署作业,定期进行完整备份、差异备份和日志备份;MySQL 数据库同样如此,也是定期进行完整备份、binlog备份等。

可能很多公司的DBA认为自己的数据库已采用了新的高可用方案,是多结点冗余了,不再需要冗余备份了,例如SQL Server 的AlwaysOn,MySQL的MHA。可是,我们还是要强调两点。

1.墨菲定律:如果有两种或两种以上的方式去做某件事情,而其中一种选择方式将导致灾难,则必定有人会做出这种选择。

过往无数的惨痛教训说明,将损失放大的原因就是备份数据也损坏了(大家不重视,实际上很可能就没做)。

2.容灾备份不仅仅可以解决物理故障,还可以将一些其它误操作回滚,将数据的损害降至最低。

数据容灾备份是为数据的灾难恢复加固了最后一道保障墙。

国务院信息化工作办公室领导编制的《重要信息系统灾难恢复指南》也对灾难恢复能力等级做了详细划分。

 

     灾难恢复能力等级

RTO

                     RPO

1

2天以上

1天至7天

2

24小时以后

1天至7天

3

12小时以上

数小时至1天

4

数小时至2天

数小时至1天

5

数分钟至2天

0至30分钟

6

数分钟

0

 

随着MongoDB使用的越来越普及,存储的数据越来越重要,对其进行定期备份很有必要。现在业内普遍流行的做法是每天定时进行一次全库备份,出故障时,进行全库还原。但是一天一次的备份,很难保证恢复后的数据时效性,RPO较差,会有几个小时的数据丢失。例如,每天5点进行完整备份,如果故障点是晚上20:00,那么就会丢失15个小时的数据。对比上面的“灾难恢复能力等级“”列表,会发现,我们的灾难能力等级比较低。

如果每小时做一次全部备份,那么对存储空间的要求较高,还有就是对性能也会有影响。所以,探究Mongodb的增量备还与原很有必要!!!

二 原理说明

关系型数据库,例如MySQL ,SQL Server 都有事务日志(或bin log),会将数据库的DML 、DDL、DCL等操作记录在事务文件中,可以通过日志备份来搭建增量容灾还原体系。MongoDB没有此类机制和数据文件,难以实现。但是MongoDB副本集有通过oplog(位于local数据库oplog.rs集合中) 实现节点间的同步,此集合记录了整个mongod实例在一段时间内的所有变更(插入/更新/删除)操作。基于此,是否可以考虑通过oplog.rs集合的备份还原来实现实例的增量备份与增量还原。

查看mongodb备份命令Mongodump,其中有一个相关参数oplog。

Mongodump --oplog参数

参数

参数说明

--oplog

Use oplog for taking a point-in-time snapshot

 

该参数的主要作用是在导出库集合数据的同时生成一个oplog.bson文件,里面存放了开始进行dump到dump结束之间所有的op log 操作。

 

注意:--oplog选项只对全库导出有效。

相应的 Mongorestore 中与 Oplog 相关的参数

参数

参数说明

oplogReplay

replay oplog for point-in-time restore

oplogLimit

only include oplog entries before the provided Timestamp

oplogFile

oplog file to use for replay of oplog

 

 

 仔细观察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

三 代码实现【重点推荐

在容灾体系建设中,既有全库的完整备份也有增量备份。下面是我们的实现代码,因为MongoDB多是在Linux系统下部署,所以这些备份代码都是通过shell语言实现。这些代码大家只要稍微改动,调整部分参数,即可部署应用。

1. 实现完整(全库)备份的代码

  1. #!/bin/bash
  2. sourcepath='/data/mongodb/mongobin344/bin'
  3. targetpath='/data/mongodb_back/bkXXX_2XXXX'
  4. nowtime=$(date "+%Y%m%d")
  5. start()
  6. {
  7. ${sourcepath}/mongodump --host 172.XXX.XXX.XXX --port 2XXXX -u 用户名-p "密码" --oplog --gzip --authenticationDatabase "admin" --out ${targetpath}/${nowtime}
  8. }
  9. execute()
  10. {
  11. echo "================================ $(date) bakXXX 2XXXX mongodb back start ${nowtime}========="
  12. start
  13. if [ $? -eq 0 ]
  14. then
  15. echo "The MongoDB BackUp Successfully!"
  16. else "The MongoDB BackUp Failure"
  17. fi
  18. }
  19. if [ ! -d "${targetpath}/${nowtime}/" ]
  20. then
  21. mkdir ${targetpath}/${nowtime}
  22. fi
  23. execute
  24. baktime=$(date -d '-3 days' "+%Y%m%d")
  25. if [ -d "${targetpath}/${baktime}/" ]
  26. then
  27. rm -rf "${targetpath}/${baktime}/"
  28. echo "=======${targetpath}/${baktime}/===删除完毕=="
  29. fi
  30.  
  31. echo "================================ $(date) bakXXX 2XXXX mongodb back end ${nowtime}========="

 

代码说明:

1.完整备份的脚本,通过crontab触发执行,每天执行一次。

2.备份完整后,会将三天前的备份文件自动删除。

3.sourcepath 定义了MongoDB 运行程序所在路径;targetpath定义了归档文件存放的文件夹(请提前创建)。

 

2. 实现增量备份的代码

  1. #
  2. # This file is used by cron to Backup the data of oplog collection,the collection is part of local DB.
  3. # The oplog (operations log) is a special capped collection that keeps a rolling record of all operations
  4. # that modify the data stored in your databases.All replica set members contain a copy of the oplog,
  5. # in the local.oplog.rs collection, which allows them to maintain the current state of the database.
  6. # Each operation in the oplog is idempotent. That is, oplog operations produce the same results
  7. # whether applied once or multiple times to the target dataset.
  8. #
  9. # We backup the collections by periodicity to restore the DB in case of DB disaster
  10. # The version is defined V.001
  11. # Version ModifyTime ModifyBy Desc
  12. # Ver001 2018-11-06 17:00 xuchangpei Create the Scripts File
  13. #
  14. #
  15. #!/bin/bash
  16. #### 请在此处输入关键参数,例如程序路径,账号,密码,实例端口###
  17. command_linebin="/data/mongodb/mongobin344/bin/mongo"
  18. username="用户名"
  19. password="用户命名"
  20. port="mongo都被的端口号"
  21. ####
  22. ####comments0 start 第一次运行此脚本时,自动检查创建备份路径 ####
  23. if [ ! -d "/data/mongodb_back/mongodboplog_back/mongo$port" ]
  24. then
  25. mkdir -p /data/mongodb_back/mongodboplog_back/mongo$port
  26. fi
  27.  
  28. if [ ! -d "/data/mongodb_back/mongodboplog_back/log/$port" ]
  29. then
  30. mkdir -p /data/mongodb_back/mongodboplog_back/log/$port
  31. fi
  32. bkdatapath=/data/mongodb_back/mongodboplog_back/mongo$port
  33. bklogpath=/data/mongodb_back/mongodboplog_back/log/$port
  34. ####comments end ##
  35. logfilename=$(date -d today +"%Y%m%d")
  36. echo "===================================Message --=MongoDB 端口为" $port "的差异备份开始,开始时间为" $(date -d today +"%Y%m%d%H%M%S") >> $bklogpath/$logfilename.log
  37. ParamBakEndDate=$(date +%s)
  38. echo "Message --本次备份时间参数中的结束时间为:" $ParamBakEndDate >> $bklogpath/$logfilename.log
  39. DiffTime=$(expr 65 \* 60)
  40. echo "Message --备份设置的间隔时间为:" $DiffTime >> $bklogpath/$logfilename.log
  41. ParamBakStartDate=$(expr $ParamBakEndDate - $DiffTime)
  42. echo "Message --本次备份时间参数中的开始时间为:" $ParamBakStartDate >> $bklogpath/$logfilename.log
  43. bkfilename=$(date -d today +"%Y%m%d%H%M%S")
  44. #### comments1 start 获取数据库中oplog记录的开始范围,防止导出的数据不完整 ####
  45. command_line="${command_linebin} localhost:$port/admin -u$username -p$password"
  46. opmes=$(/bin/echo "db.printReplicationInfo()" | $command_line --quiet)
  47. echo $opmes > opdoctime$port.tmplog
  48. opbktmplogfile=opdoctime$port.tmplog
  49. #opstartmes=$(grep "oplog first event time" $opmes)
  50. 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}' )
  51. echo "Message --oplog集合记录的开始时间为:"$opstartmes >> $bklogpath/$logfilename.log
  52. oplogRecordFirst=$(date -d "$opstartmes" +%s)
  53. echo "Message --oplog集合记录的开始时间为:" $oplogRecordFirst >> $bklogpath/$logfilename.log
  54. ##begin 比较备份参数的开始时间是否在oplog记录的时间范围内
  55. if [ $oplogRecordFirst -le $ParamBakStartDate ]
  56. then
  57. echo "Message --检查设置备份时间合理。备份参数的开始时间在oplog记录的时间范围内。" >> $bklogpath/$logfilename.log
  58. else echo "Fatal Error --检查设置的备份时间不合理合理。备份参数的开始时间不在oplog记录的时间范围内。请调整oplog size或调整备份频率。本次备份可以持续进行,但还原时数据完整性丢失。" >> $bklogpath/$logfilename.log
  59. fi
  60. ##end##
  61. #### comments1 end ####
  62. 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)
  63. echo "本次导出的具体信息如下:" $dumpmsg
  64. echo $dumpmsg >> $bklogpath/$logfilename.log
  65. #### comments2 start 再次检查,防止导出oplog数据过程耗时过长,比如,我们一小时导出一份,每一次循环涵盖65分钟,如果导出执行过程耗时5分钟以上就可能导致导出的数据不完整。####
  66. ## 下面的70 是有上面的65+5而得,+5 是允许导出耗时5分钟。这个逻辑有点绕,大家可以测测,这段逻辑看几分钟可以理解通透了。
  67. DiffTime=$(expr 70 \* 60)
  68. AllowMaxDate=$(expr $(date +%s) - $DiffTime)
  69. if [ $AllowMaxDate -le $ParamBakStartDate ]
  70. then
  71. echo "Message --oplog记录导出时间在规定的DiffTime范围内。数据有效" >> $bklogpath/$logfilename.log
  72. else echo "Fatal Error --oplog记录导出时间 超出了 规定的DiffTime范围。数据完整性等不到保证。请增大DiffTime参数或调整备份频率。" >> $bklogpath/$logfilename.log
  73. fi
  74. #### comments2 end ####
  75. #### comments3 检查备份文件是否已经删除start ####
  76. if [ -d "$bkdatapath/mongodboplog$bkfilename" ]
  77. then
  78. echo "Message --检查此次备份文件已经产生.文件信息为:" $bkdatapath/mongodboplog$bkfilename >> $bklogpath/$logfilename.log
  79. else echo "Fatal Error --备份过程已执行,但是未检测到备份产生的文件,请检查!" >> $bklogpath/$logfilename.log
  80. fi
  81. ##### comments3 end ####
  82. #### comments4 start 删除历史备份文件,保留3天,如需调整,请在持续设置
  83. keepbaktime=$(date -d '-3 days' "+%Y%m%d%H")*
  84. if [ -d $bkdatapath/mongodboplog$keepbaktime ]
  85. then
  86. rm -rf $bkdatapath/mongodboplog$keepbaktime
  87. echo "Message -- $bkdatapath/mongodboplog$keepbaktime 删除完毕" >> $bklogpath/$logfilename.log
  88. fi
  89. ### comments4 end
  90. echo "============================Message --MongoDB 端口为" $port "的差异备份结束,结束时间为:" $(date -d today +"%Y%m%d%H%M%S") >> $bklogpath/$logfilename.log

 

代码说明:

1.增量备份的脚本,也是通过crontab触发执行,以上参数未修改前,建议每小时执行一次。

2.备份完整后,会自动检查文件是否产生,并且会将三天前的备份文件删除。

3.脚本会自动检查备份路径,不存在将自动产生。

4.增量导出中开始时间和结束时间是最重要的参数,并且要对参数的合法性、有效性检查。例如,检查Oplog的记录是否完全涵盖输入的时间,防止出现希望导出08:00--09:00的数据,但是oplog集合中只有08:30--09:00的数据;防止导出过程耗时过长(例如超过定义的5分钟),导致数据不完整。代码中都会对这些异常进行判断和捕获。

 

四 功能测试验证

1. 测试环境

 

Item ServerIP Port User DB
源库 172.XXX.XXX.124(Primary) 2XXX30 testoplog
备份还原库 172.XXX.XXX.124(Primary) 2XXX20

 

2. 完整备份与还原

step 1 在备份前,先向数据库testoplog插入部分数据

step 2 完整备份所有的数据库,执行的代码为上面的完整备份代码(保存到执行文件bkoplogtest_2XXX30),打印出执行过程如下截图

step 3 还原完整备份,执行的代码和打印执行过程如下:

执行的命令:

/data/mongodb/mongobin344/bin/mongorestore -h 172.XXX.XXX.124 --port 2XXX20  --oplogReplay --authenticationDatabase 认证数据库-u 用户名-p '密码' --gzip /data/mongodb_back/testoplogbackfile/20181107

打印出的执行过程:

step 4 检查还原库的情况,检查库(testoplog)、表(testfullbefore01、testfullbefore02、testfullbefore03)是否还原。

结论:完整还原后与原库完整备份时数据一致,符合测试预期。

 

 3. 增量备份与还原

 

增量备份与还原的测试案例描述

 

测试案例 第一次增量备份 第一次增量还原 第二次增量备份 第二次增量还原
源库

备份前,新建集合testdiffbk01

并插入10000笔数据

 无操作

备份前,新建集合testdiffbk02

并插入10000笔数据

 无操作
还原库 无操作

还原后,检查testdiffbk01是否存在

以及数据量

 无操作

还原后,检查testdiffbk02是否存在

以及数据量

 

step 1 第一次增量备份前,向源库中插入测试数据

step 2 第一次执行增量备份(执行增量备份的脚本,代码放置在执行文件mongodb_oplogbacktestoplog2XXXX.sh中)

 

step 3 向源库中第二次插入测试数据

step 4 第二次执行增量备份

两次增量备份产生的文件在 文件夹 /data/mongodb_back/mongodboplog_back/mongo27230 中,如下图所示:

step 5 将完整备份所在路径下的文件清空,将第一次备份的产生的oplog.rs.bson 文件,copy至此路径下,并重命名为oplog.bson。【即还原第一份增量备份

清空指令:

Copy+ 重命名指令

还原指令:

/data/mongodb/mongobin344/bin/mongorestore -h 172.XXX.XXX.124 --port 2XXX20 --oplogReplay --authenticationDatabase 验证数据库-u 用户名-p '密码' /data/mongodb_back/testoplogbackfile/20181107

 

step 7 验证第一次增量还原的数据,验证测试所用的集合testdiffbk01及数据,与原库第一次增量备份时一致,即已正常还原增量。

step 8 将完整备份所在路径下的文件清空,将第二次增量备份的产生的oplog.rs.bson 文件,copy至此路径下,并重命名为oplog.bson。【即还原第二份增量备份

删除指令

copy + 重命名指令

还原增量备份的指令【与第一次执行的还原命令完全一样】

/data/mongodb/mongobin344/bin/mongorestore -h 172.XXX.XXX.124 --port 2XXX20  --oplogReplay --authenticationDatabase 验证数据库-u 用户名-p '密码' /data/mongodb_back/testoplogbackfile/20181107

 

step 9  验证第二次增量还原的数据,验证测试所用的集合testdiffbk02及数据。结论:与原库第二次增量备份时一致,即已正常还原增量。

 此次测试有完整备份与完整还原,还有两次增量备份月增量,详细演示增量还原方案的可行性和相关代码的可执行性,部署后满足生产所需。

五 注意事项

一定要在还原完整备份的路径下,还原已备份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命令报错:

如果我们将/local/oplog.rs.bson复制至还原完整备份所在的路径下( /XXX/XXXX_back/bkrcs_27XXX/20181105),执行restore,测试不再报错。

 

检查新增数据也已同步过去。

所以,还原时增量备份(oplog)一定要放置完整备份所在的文件夹下(copy前,先将完整备份完结删除)进行还原。

 

本文版权归作者所有,未经作者同意不得转载,谢谢配合!!!

 本文版权归作者所有,未经作者同意不得转载,谢谢配合!!!

本文版权归作者所有,未经作者同意不得转载,谢谢配合!!!

 友情链接:直通硅谷  点职佳  北美留学生论坛

本站QQ群:前端 618073944 | Java 606181507 | Python 626812652 | C/C++ 612253063 | 微信 634508462 | 苹果 692586424 | C#/.net 182808419 | PHP 305140648 | 运维 608723728

W3xue 的所有内容仅供测试,对任何法律问题及风险不承担任何责任。通过使用本站内容随之而来的风险与本站无关。
关于我们  |  意见建议  |  捐助我们  |  报错有奖  |  广告合作、友情链接(目前9元/月)请联系QQ:27243702 沸活量
皖ICP备17017327号-2 皖公网安备34020702000426号