966,690 六月 独立访问用户
语言 & 开发
架构 & 设计
文化 & 方法
您目前处于：
10gen发布MongoDB增量备份服务
10gen发布MongoDB增量备份服务
日. 估计阅读时间:
不到一分钟
智能化运维、Serverless、DevOps......2017年有哪些最新运维技术趋势？!
Author Contacted
相关厂商内容
相关赞助商
CNUTCon全球运维技术大会，9月10日-9月11日，上海&光大会展中心大酒店，
告诉我们您的想法
允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p
当有人回复此评论时请E-mail通知我
允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p
当有人回复此评论时请E-mail通知我
允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p
当有人回复此评论时请E-mail通知我
赞助商链接
架构 & 设计
文化 & 方法
<及所有内容，版权所有 &#169;
C4Media Inc.
服务器由 提供, 我们最信赖的ISP伙伴。
北京创新网媒广告有限公司
京ICP备号-7
找回密码....
InfoQ账号使用的E-mail
关注你最喜爱的话题和作者
快速浏览网站内你所感兴趣话题的精选内容。
内容自由定制
选择想要阅读的主题和喜爱的作者定制自己的新闻源。
设置通知机制以获取内容更新对您而言是否重要
注意：如果要修改您的邮箱，我们将会发送确认邮件到您原来的邮箱。
使用现有的公司名称
修改公司名称为：
公司性质：
使用现有的公司性质
修改公司性质为:
使用现有的公司规模
修改公司规模为：
使用现在的国家
使用现在的省份
Subscribe to our newsletter?
Subscribe to our industry email notices?
我们发现您在使用ad blocker。
我们理解您使用ad blocker的初衷，但为了保证InfoQ能够继续以免费方式为您服务，我们需要您的支持。InfoQ绝不会在未经您许可的情况下将您的数据提供给第三方。我们仅将其用于向读者发送相关广告内容。请您将InfoQ添加至白名单，感谢您的理解与支持。Linux下MongoDB实现自动备份脚本 - CNode技术社区
这家伙很懒，什么个性签名都没有留下。
#!/bin/bash
数据库备份
nowtime=date +&%Y-%m-%d&
echo “============= back start ${nowtime}=============”
parentpath=/opt/mongodbback
cd ${parentpath}
/usr/local/mongodb/bin/mongodump -h 127.0.0.1 -d DB -o ${parentpath}/${nowtime}
if [ $? -eq 0 ]
echo &back successfully!&
echo &back failure!&
directory is exist
if [ ! -d ${parentpath}/${nowtime} ]
mkdir pwd/${nowtime}
echo “============= back end${nowtime}=============”
CNode 社区为国内最专业的 Node.js 开源技术社区，致力于 Node.js 的技术研究。
服务器赞助商为
，存储赞助商为
，由提供应用性能服务。
新手搭建 Node.js 服务器，推荐使用无需备案的从炉石传说数据库故障谈谈MongoDB的数据库备份和恢复手段
发表于 11:09|
来源云栖社区|
作者云栖社区
摘要：基于飞天分布式系统和高性能存储，提供三节点副本集的高可用架构，容灾切换，故障迁移完全透明化。
基于飞天分布式系统和高性能存储，提供三节点副本集的高可用架构，容灾切换，故障迁移完全透明化。并提供专业的数据库在线扩容、备份回滚、性能优化等解决方案。
最近数据库真是多灾多难，前段时间刚刚爆出MongoDB数据库安全问题（见）。这两天又被炉石传说数据库故障给刷屏了。
看到这个消息，我的第一反应是重新翻出尘封已久的ipad，装上炉石准备上线领补偿。等等，作为一个数据库行业从业人员，是不是还应该干点什么？恩，很有必要再重新审视一下我们的数据库有没有做好容灾，否则，今天你看别人热闹，明天可能就别人看你热闹了。借此机会我想给大家普及一下MongoDB数据库的备份和恢复手段（当然炉石传说应该不一定是使用MongoDB作为数据库），以帮助大家做好容灾，过个好年。同时，我也为我们阿里云MongoDB服务做下广告，我们的MongoDB服务拥有完善的自动备份/恢复功能，灵活的备份策略，好用的恢复到任意时间点功能。我们的备份存放了多份副本，可靠性达10个9，请大家放心使用！
MongoDB数据库备份手段
全量逻辑备份/恢复
Mongodump/Mongorestore
对于数据量比较小的场景，使用官方的工具进行全量的备份和恢复就足够了。mongodump可以连上一个正在服务的mongod节点进行逻辑热备份。其主要原理是遍历所有集合，然后将文档一条条读出来，支持并发dump多个集合，并且支持归档和压缩，可以输出到一个文件（或标准输出）（对原理感兴趣可以参见我之前写的两篇文章以及）。同样，mongorestore则是连上一个正在服务的mongod节点进行逻辑恢复。其主要原理是将备份出来的数据再一条条写回到数据库中。
对性能的影响
mongodump执行过程由于会遍历所有数据，因此会对MongoDB性能有影响，最好在备节点执行（最好是hidden，需检查备节点数据同步是否正常）。
获取一致的数据快照
在mongodump执行过程中由于数据库还有新的修改，直接运行dump出来的结果不是一个一致的快照，需要使用一个『--oplog』的选项来将这个过程中的oplog也一块dump下来（使用mongorestore进行恢复时对应要使用--oplogReplay选项对oplog进行重放）。而由于MongoDB的oplog是一个固定大小的特殊集合，当oplog集合达到配置的大小时旧的oplog会被滚掉以为新的oplog腾出空间。在使用『--oplog』选项进行dump时，mongodump会在dump集合数据前获取当时最新的oplog时间点，并在集合数据dump完毕之后再次检查这个时间点的oplog是否还在，如果dump过程很长，oplog空间又不够，oplog被滚掉就会dump失败。因此在dump前最好检查一下oplog的配置大小以及目前oplog的增长情况（可结合业务写入量及oplog平均大小进行粗略估计），确保dump不会失败。目前我们阿里云MongoDB服务针对oplog做了弹性扩缩容的优化，能够确保在逻辑备份过程中oplog不被滚掉，一定能够备份成功。
索引的备份和恢复
对于集合数据，mongodump出来的结果是一个个bson文件。而对于集合的索引，则是描述在一个metadata的json文件里，里面还包含创建集合时所使用的选项。在使用mongorestore进行恢复时，会在集合数据恢复完毕之后进行对应的索引创建。
全量物理备份/恢复
对于数据量很大的场景，如果使用mongodump/mongorestore进行备份和恢复，需要的时间可能会很长。对于备份来说，最主要的问题就是备份所需时间越长，oplog被滚掉的几率就越大，备份失败的几率也就越大。而对于恢复来说，由于恢复过程还涉及到索引的创建，如果除了数据量大，还有很多索引，所需花费的时间就更长了。遇到像炉石这种数据灾难，恢复时间当然是越短越好，毕竟在游戏行业分分钟的流水都很可观。这时候就需要物理备份出场了，物理备份，顾名思义就是通过物理拷贝数据文件实现备份。在恢复时可以直接使用物理备份拷贝出来的数据文件，直接启动mongod。物理备份最大的好处是速度快，恢复时也不需要再建索引。
物理备份通过拷贝数据文件来实现，这要求所有被拷贝的数据文件必须是一个一致的数据快照。因此物理备份的实施方法和MongoDB采用的存储引擎有关，并且，根据是否配置MongoDB打开了Journal，在实施的细节上会有一些不同，具体可参考。不管使用何种存储引擎，在3.2版本之后，都可以用以下方法实现物理备份：
由于执行db.fsyncLock()会加数据库的全局写锁，这时数据库会处于一个不可访问的状态，因此物理备份最好也在备节点上执行（最好是hidden，注意同样需要确保物理备份完成之后节点的oplog能追上主节点）。目前我们阿里云MongoDB团队已经研发出了无需停写服务的物理热备份手段，相信很快就可以让大家用上，尽请期待！
MongoDB的增量备份可以通过持续抓取oplog来实现，这个目前没有现成的工具可以利用，需要自己代码实现。抓取oplog主要的难题也和使用mongodump进行全量备份一样，需确保要抓取的oplog不被滚掉。目前我们阿里云MongoDB服务实现了自动增量备份的功能，结合全量备份可以实现任意时间点恢复功能。
Sharding的备份/恢复
炉石是不分服的，因此它后面也有可能是使用分布式数据库。对于分布式数据库来说，备份和恢复比单机数据库更加复杂。分布式数据库包含多个节点，并且通常包含不同角色的节点。以MongoDB的Sharding集群为例，它包含一个保存元数据的config server以及若干个保存数据的shard。其中最主要的元数据就是数据在shard之间的分布情况。对于多个节点的备份，其中一个难题是保证所有节点备份的数据是同一个时间点的，常规采用的手段是停止外部写入后进行备份，这在互联网服务中显然不可接受。退而求其次，可以在停止接受同步的备节点上进行备份，这样可以得到一个时间大致接近的备份。另外一个难题是各数据节点之间通常存在数据迁移，而数据迁移就涉及到起码2个以上数据节点的数据修改以及元数据节点的数据修改，如果在备份过程中发生数据迁移，很难保证备份出来的数据和元数据是一个一致的状态。因此通常在备份过程中需要关闭数据迁移。MongoDB官方的指导步骤就是采用这个思路，先关闭负责数据迁移的balancer，然后依次在config server和各个shard的备节点上进行备份。关闭数据迁移最大的问题是关闭期间集群无法实现数据均衡，除了会影响集群的访问性能外，还造成资源的浪费，这在数据量较大，所需备份时间较长时可能造成比较大的影响。
针对这两大难题，我们阿里云MongoDB团队研发了不需要停外部写，并且无需关数据迁移的Sharding备份手段，能够实现『任意』时间点恢复，这个功能将伴随着即将推出的Sharding形态一起推出，尽情期待！
阿里云MongoDB备份服务
阿里云MongoDB服务提供自动备份/恢复功能，默认每天为数据进行全量备份，并且自动抓取oplog进行增量备份。用户可以在控制台自定义备份策略以及进行恢复。
恢复时可以选择某一个备份集或某一个时间点克隆出一个新的实例，可以在新实例上进行数据校验，等校验没问题后切换到新实例。此外，全量备份的数据还提供下载功能，用户也可以选择下载备份集到本地后恢复到一个临时实例进行数据校验。
说了这么多，大家应该对MongoDB的备份/恢复手段有了一个大概的认识。如果要图省心，还是建议直接使用阿里云MongoDB服务，我们有自动化的备份/恢复服务，灵活的备份策略，只需点点鼠标就能用上任意时间点恢复、物理热备份、Sharding备份/恢复这些黑科技，从此不再为数据库容灾发愁，业务你们做，锅有我们来背，还等什么呢，快来试用吧！
基于飞天分布式系统和高性能存储，提供三节点副本集的高可用架构，容灾切换，故障迁移完全透明化。并提供专业的数据库在线扩容、备份回滚、性能优化等解决方案。
推荐阅读相关主题：
CSDN官方微信
扫描二维码,向CSDN吐槽
微信号：CSDNnews
相关热门文章5507人阅读
NOSQL（47）
开发语言（5）
MongoDB本身不支持增量备份，所以这里介绍几种我找到的，或者是自己使用代码实现的方法：
我的环境：集群环境，
如果是分片集群，只好各【分片集群】和【配置服务器集群】分开备份处理，因为使用了Oplog
所以不适合单机环境
一、 Delay server &#43; Oplog replay(延迟节点&#43;Oplog 重现)
【MongoDB The.Definitive.Guide 2nd.pdf】P363中介绍的使用mongooplog 工具来做增量备份的方法
应该 也属于此类方法。
二、使用mongosync 同步工具，&& &它的功能有：
&& &1.&& &全量同步
&& &2.&& &增量同步
&& &3.&& &全量和增量同步，实时同步
&& &4.&& &可批量同步某个库/表
&& &优点：
&& &&& &切换快，（如果使用了增量备份，那备份机必须是集群，因为用到oplog ）
&& &（url: /articles/iei6n2）
&& &下载链接：/s/1qXrpbDa 密码：yybn
三、使用开源代码: Wordnik MongoDB Admin Tools 进行增量备份。
&& &具体操作可以看git:& /reverb/wordnik-oss/blob/master/modules/mongo-admin-utils/README.md
&& &下面有打包好的文件：
&& &&& &链接：/s/1bogjYVH 密码：i82e
&& &我测试下来，增量备份速度不太理想，也有可能是和测试环境有关系。
这里我把我使用python 代码实现 oplog 增量备份及恢复的罗列如下：
1. Delay server &#43; Oplog replay(延迟节点&#43;Oplog 重现)
使用Oplog replay 的优点是：可以在恢复时，具体恢复到某一个时间点
步骤如下：
&& &1、在集群中添加一个延迟节点，比如延迟设置成10小时；
&& &2、另外找一台MongoDB 实例（可以是集群，也可以是单机）使用代码同步local.oplog.rs 表数据到
&& &备份库中（不要选择local库，因为local 库中的表你无法修改表结构，表索引，比如我新建立的表库名：oplog_bak）
&& &代码如下（python）：
&#39;&#39;&#39;
Author: tang
MongoDB Incremental Backup oplog.rs to other serverDB
&#39;&#39;&#39;
import time
import json
import pymongo
import datetime
import sys
import bson
def init_back_database(p_db_name):
&#39;&#39;&#39;init back desc db&#39;&#39;&#39;
dest_conn.get_database(p_db_name).create_collection(&#39;oplog.rs&#39;,autoIndexId=False)
dest_conn.get_database(p_db_name).get_collection(&#39;oplog.rs&#39;).create_index([(&ts&,pymongo.ASCENDING)],unique=True)
dest_conn.get_database(p_db_name).get_collection(&#39;oplog.rs&#39;).create_index([(&#39;ns&#39;,pymongo.ASCENDING)])
dest_conn.get_database(p_db_name).get_collection(&#39;oplog.rs&#39;).insert({&ts&:bson.timestamp.Timestamp(0,1)})
def inc_oplog(p_db_name):
&&&copy source server oplog to backup db&&&
#get last_timestamp
row_count = dest_conn.get_database(p_db_name).get_collection(&#39;oplog.rs&#39;).count()
if row_count==0:
init_back_database(p_db_name)
last_timestamp = bson.timestamp.Timestamp(int(time.time())-24*3600,1)
cur_oplog_rs = dest_conn.get_database(p_db_name).get_collection(&#39;oplog.rs&#39;).find({},{&ts&:1}).sort([(&ts&,-1)]).limit(1)
for row in cur_oplog_rs:
last_timestamp = row[&ts&]
#copy oplog
cur_oplog = source_conn.get_database(&#39;local&#39;).get_collection(&#39;oplog.rs&#39;).find({&ts&:{&$gt&:last_timestamp},&op&:{&$in&:[&#39;i&#39;,&#39;d&#39;,&#39;u&#39;]}}).limit(100000)
for row in cur_oplog:
row_data = row
#change dist2str save, bypass: field name not start $
if row_data.has_key(&#39;o&#39;):
row_data[&#39;o&#39;] = str(row_data[&#39;o&#39;])
if row_data.has_key(&#39;o2&#39;):
row_data[&#39;o2&#39;] = str(row_data[&#39;o2&#39;])
#print row_data
dest_conn.get_database(p_db_name).get_collection(&#39;oplog.rs&#39;).insert(row_data)
#end copy oplog
#end inc_oplog
def replay_oplog(p_db_name,p_tb_name,p_start_ts,p_end_ts):
&#39;&#39;&#39;use oplog log row,replay data to every collections&#39;&#39;&#39;
#copy oplog
cur_oplog = source_conn.get_database(p_db_name).get_collection(&#39;oplog.rs&#39;).find({&ts&:{&$gt&:p_last_ts}})
for row in cur_oplog:
db_name = row[&ns&].split(&#39;.&#39;)[0]
tbl_name = row[&ns&].split(&#39;.&#39;)[1]
if row[&#39;op&#39;]==&#39;i&#39;:
document_dist = eval(row[&#39;o&#39;])
dest_conn.get_database(db_name).get_collection(tbl_name).insert(document_dist)
if row.has_key(&#39;b&#39;):
muli_flg = row[&#39;b&#39;]
muli_flg = False
if row[&#39;op&#39;]==&#39;u&#39;:
document_dist = eval(row[&#39;o&#39;])
if row.has_key(&#39;o2&#39;):
document2_dist = eval(row[&#39;o2&#39;])
dest_conn.get_database(db_name).get_collection(tbl_name).update(document2_dist,document_dist,multi=muli_flg)
dest_conn.get_database(db_name).get_collection(tbl_name).update({},document_dist,multi=muli_flg)
if row[&#39;op&#39;]==&#39;d&#39;:
document_dist = eval(row[&#39;o&#39;])
dest_conn.get_database(db_name).get_collection(tbl_name).remove(document_dist,multi=muli_flg)
#end def replay_oplog
if __name__==&#39;__main__&#39;:
btype = sys.argv[1]
source_host = sys.argv[2]
desc_host = sys.argv[3]
desc_dbname = sys.argv[4]
last_ts = sys.argv[5]
source_conn = pymongo.MongoClient([&#39;mongodb://%s&#39;%source_host])
dest_conn = pymongo.MongoClient([&#39;mongodb://%s&#39;%desc_host])
if btype in [&#39;b&#39;,&#39;back&#39;,&#39;bak&#39;]:
inc_oplog(desc_dbname)
if btype in [&#39;r&#39;,&#39;rest&#39;,&#39;restore&#39;]:
replay_oplog(desc_dbname, last_ts)
【MongoDB The.Definitive.Guide 2nd.pdf】P363：
Creating Incremental Backups with mongooplog
All of the backup methods outlined must make a full copy of the data, even if very little
of it has changed since the last backup. If you have data that is very large relative to the
amount that is being written, you may want to look into incremental backups.
Instead of making full copies of the data every day or week, you take one backup and
then use the oplog to back up all operations that have happened since the backup. This
technique is much more complex than the ones described above, so prefer them unless
incremental backups are absolutely necessary.
This technique requires two machines, A and B, running mongod. A is your main
machine (probably a secondary) and B is your backup machine:
1. Make a note of the latest optime in A’s oplog:
& op = db.oplog.rs.find().sort({$natural: -1}).limit(1).next();
& start = op['ts']['t']/1000
Keep this somewhere safe—you’ll need it for a later step.
2. Take a backup of your data, using one of the techniques above to get a point-intime backup. Restore this backup to the data directory on B.
3. Periodically add any operations that have happened on A to B’s copy of the data.
There is a special tool that comes with MongoDB distributions that makes this easy:
mongooplog (pronounced mon-goop-log) which copies data from the oplog of one
server and applies it to the data set on another. On B, run:
$ mongooplog --from A --seconds 1234567
--seconds should be passed the number of seconds between the start variable
calculated in step 1 and the current time, then add a bit (better to replay operations
a second time than miss them).
This keeps your backup relatively up-to-date with your data. This technique is sort of
like keeping a secondary up-to-date manually, so you may just want to use a slavedelayed secondary instead
&&相关文章推荐
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：849397次
积分：9138
积分：9138
排名：第1932名
原创：205篇
转载：91篇
评论：45条
(3)(3)(2)(6)(4)(2)(1)(3)(4)(1)(2)(3)(1)(2)(2)(4)(5)(3)(4)(6)(4)(2)(13)(4)(8)(5)(6)(12)(13)(5)(2)(5)(6)(6)(6)(1)(6)(4)(5)(20)(2)(4)(1)(1)(2)(1)(9)(1)(1)(3)(1)(1)(4)(1)(2)(4)(1)(1)(1)(1)(1)(1)(6)(1)(1)(6)(7)(6)(4)(3)(2)(5)(6)(7)(4)