MongoDB备份恢复笔记

1、全量逻辑备份/恢复 MonGodump/Mongorestore

对于数据量比较小的场景，使用官方的mongodump/mongorestore工具进行全量的备份和恢复就足够了。mongodump可以连上一个正在服务的mongod节点进行逻辑热备份。其主要原理是遍历所有集合，然后将文档一条条读出来，支持并发dump多个集合，并且支持归档和压缩，可以输出到一个文件（或标准输出）（对原理感兴趣可以参见我之前写的两篇文章Mongodump的arcHive（归档）模式原理解析以及Mongorestore的archive(归档)模式恢复原理解析）。同样，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进行恢复时，会在集合数据恢复完毕之后进行对应的索引创建。

2、全量物理备份/恢复

对于数据量很大的场景，如果使用mongodump/mongorestore进行备份和恢复，需要的时间可能会很长。对于备份来说，最主要的问题就是备份所需时间越长，oplog被滚掉的几率就越大，备份失败的几率也就越大。而对于恢复来说，由于恢复过程还涉及到索引的创建，如果除了数据量大，还有很多索引，所需花费的时间就更长了。遇到像炉石这种数据灾难，恢复时间当然是越短越好，毕竟在游戏行业分分钟的流水都很可观。这时候就需要物理备份出场了，物理备份，顾名思义就是通过物理拷贝数据文件实现备份。在恢复时可以直接使用物理备份拷贝出来的数据文件，直接启动mongod。物理备份最大的好处是速度快，恢复时也不需要再建索引。

实施方法

物理备份通过拷贝数据文件来实现，这要求所有被拷贝的数据文件必须是一个一致的数据快照。因此物理备份的实施方法和MongoDB采用的存储引擎有关，并且，根据是否配置MongoDB打开了Journal，在实施的细节上会有一些不同，具体可参考官方文档。不管使用何种存储引擎，在3.2版本之后，都可以用以下方法实现物理备份：

1. 通过mongoshell执行以下命令以确保所有的写操作都flush到磁盘并禁止新的写入：

db.fsyncLock();

1. 利用底层文件系统层或逻辑卷的快照功能对MongoDB的数据目录做快照，或直接通过cp、scp、tar等命令拷贝数据目录。

2. 还是在刚才的mongoshell上（这里需要保证和刚刚是同一个连接），执行以下命令以重新允许新的写入：

db.fsyncUnLock();

由于执行db.fsyncLock()会加数据库的全局写锁，这时数据库会处于一个不可访问的状态，因此物理备份最好也在备节点上执行（最好是hidden，注意同样需要确保物理备份完成之后节点的oplog能追上主节点）。目前我们阿里云MongoDB团队已经研发出了无需停写服务的物理热备份手段，相信很快就可以让大家用上，尽请期待！

增量备份

MongoDB的增量备份可以通过持续抓取oplog来实现，这个目前没有现成的工具可以利用，需要自己代码实现。抓取oplog主要的难题也和使用mongodump进行全量备份一样，需确保要抓取的oplog不被滚掉。目前我们阿里云MongoDB服务实现了自动增量备份的功能，结合全量备份可以实现任意时间点恢复功能。

3、Sharding的备份/恢复

炉石是不分服的，因此它后面也有可能是使用分布式数据库。对于分布式数据库来说，备份和恢复比单机数据库更加复杂。分布式数据库包含多个节点，并且通常包含不同角色的节点。以MongoDB的Sharding集群为例，它包含一个保存元数据的config server以及若干个保存数据的shard。其中最主要的元数据就是数据在shard之间的分布情况。对于多个节点的备份，其中一个难题是保证所有节点备份的数据是同一个时间点的，常规采用的手段是停止外部写入后进行备份，这在互联网服务中显然不可接受。退而求其次，可以在停止接受同步的备节点上进行备份，这样可以得到一个时间大致接近的备份。另外一个难题是各数据节点之间通常存在数据迁移，而数据迁移就涉及到起码2个以上数据节点的数据修改以及元数据节点的数据修改，如果在备份过程中发生数据迁移，很难保证备份出来的数据和元数据是一个一致的状态。因此通常在备份过程中需要关闭数据迁移。MongoDB官方的文档指导步骤就是采用这个思路，先关闭负责数据迁移的balancer，然后依次在config server和各个shard的备节点上进行备份。关闭数据迁移最大的问题是关闭期间集群无法实现数据均衡，除了会影响集群的访问性能外，还造成资源的浪费，这在数据量较大，所需备份时间较长时可能造成比较大的影响。