看到这个消息，我的第一反应是挖出尘封已久的ipad，装上炉石准备上线领赔。等等，作为数据库行业的从业者，我是不是应该做点别的？那么，重新审视我们的数据库是否容灾是非常有必要的，否则，今天你看到别人的热闹，明天你可能会看到你在爆笑。借此机会给大家科普一下MongoDB数据库的备份和恢复方法（当然炉石应该不一定是用MongoDB做数据库），帮助大家做好灾备，过个好年.同时也给我们的阿里云MongoDB服务打广告。我们的MongoDB服务具有完善的自动备份/恢复功能，灵活的备份策略，简单易用的任意时间点恢复功能。我们的备份存储多份，可靠性达到109，请放心使用！MongoDB数据库备份即全量逻辑备份/恢复Mongodump/Mongorestore对于数据量比较小的场景，使用官方的mongodump/mongorestore工具进行全量备份和恢复即可。mongodump可以连接到服务mongod节点进行逻辑热备份。它的主要原理是遍历所有的集合，然后一个一个的读出文档。支持多个集合的并发转储，支持归档和压缩。可以输出到文件（或标准输出）（如果对原理感兴趣可以参考我之前写的两篇文章Mongodump的归档（archive）模式原理分析和Mongorestore的归档（archive）模式恢复原理分析）。类似地，mongorestore连接到服务mongod节点以进行逻辑恢复。它的主要原理是将备份数据逐条写回数据库。对性能的影响因为mongodump执行过程会遍历所有数据，所以会影响MongoDB的性能。最好在备节点上执行（***是隐藏的，需要检查备节点的数据同步是否正常）。获取一致的数据快照在mongodump执行过程中，由于数据库有新的修改，直接运行dump的结果并不是一致的快照。您需要使用“-oplog”选项来转储此过程中的oplog。（当使用mongorestore进行恢复时，应该使用--oplogReplay选项重放操作日志）。并且由于MongoDB的oplog是一个特殊的集合，大小固定，当oplog集合达到配置的大小时，旧的oplog会被滚掉，为新的oplog腾出空间。当使用“-oplog”选项进行dump时，mongodump会在dump采集数据前获取最新的oplog时间点，并在采集数据dump完成后检查该时间点的oplog是否还在。如果dump过程很慢Long，而且oplog空间不够用。如果oplog被转出，转储将失败。因此，在转储前，最好检查一下oplog的配置大小和oplog当前的增长情况（可以根据业务写入量和oplog的平均大小做一个粗略的估计），确保转储成功不会失败。目前我们阿里云MongoDB服务已经优化了oplog的弹性伸缩，可以保证逻辑备份过程中oplog不会滚出，备份成功。索引备份与恢复对于集合数据，mongodump的结果是一个bson文件。至于集合的索引，是在一个元数据json文件中描述的，里面也包含了创建集合时使用的选项。使用mongorestore恢复时，恢复集合数据后会创建相应的索引。全量物理备份/恢复对于数据量较大的场景，如果使用mongodump/mongorestore进行备份和恢复，可能需要较长时间。对于备份来说，主要的问题是备份时间越长，oplog被rolloff的几率就越大，备份失败的几率就越大。对于恢复，由于恢复的过程中还涉及到索引的创建，如果数据量大，索引又多的话，时间会比较长。万一发生炉石这样的数据灾难，恢复时间越短越好。毕竟在游戏行业，每分钟的营业额是相当可观的。这时候就需要进行物理备份。物理备份，顾名思义，就是通过物理拷贝数据文件来实现备份。恢复时可以直接使用从物理备份中复制出来的数据文件直接启动mongod。物理备份最大的优点就是速度快，恢复的时候不需要建索引。实现方式物理备份是通过复制数据文件来实现的，这就要求所有复制的数据文件必须是一致的数据快照。因此，物理备份的实现方式与MongoDB使用的存储引擎有关，根据MongoDB是否配置开启Journal的不同，实现细节也会有所不同。详情请参考官方文档。无论使用何种存储引擎，在3.2版本之后，都可以通过如下方式实现物理备份：通过mongoshell执行如下命令，确保所有写操作都刷入磁盘，并禁止新的写操作：db.fsyncLock();使用底层文件系统层或逻辑卷的快照功能对MongoDB数据目录进行快照，或者直接通过cp、scp、tar等命令复制数据目录。还是在刚才的mongoshell上（需要保证和刚才是同一个连接），执行如下命令重新允许新的写入：db.fsyncUnLock();由于db.fsyncLock()的执行会加上数据库的全局写锁，此时数据库会处于不可访问状态，所以物理备份***也在备节点上进行（***是隐藏的，还需要保证物理备份完成后节点的oplog能赶上主节点）。目前，我们阿里云MongoDB团队已经研发出一种无需停写服务的物理热备方式。相信很快就会为大家所用。敬请期待！增量备份MongoDB的增量备份可以通过不断抓取oplog来实现，目前没有现成的工具可以使用，需要自己代码实现。捕获oplog的主要困难与使用mongodump进行完整备份相同。需要保证抓取的oplog不会被roll出来。目前我们阿里云MongoDB服务已经实现了自动增量备份的功能，结合全量备份，可以实现任意时间点的恢复功能。Sharding对炉石传说的备份/恢复是与服务器无关的，因此也可以在其背后使用分布式数据库。对于分布式数据库，备份和恢复要比单机数据库复杂。分布式数据库包含多个节点，并且通常包含具有不同角色的节点。以MongoDB的Sharding集群为例，它包括一个存储元数据的配置服务器和若干个存储数据的分片。最重要的元数据是分片之间的数据分布。对于多节点的备份，难点之一是保证所有节点备份的数据在同一时间点。常规的做法是停止对外写入，然后进行备份，这在互联网服务中显然是不能接受的。下一个最好的办法是在停止接受同步的备用节点上执行备份，这样就可以获得时间上大致接近的备份。另一个问题是数据节点之间通常存在数据迁移，数据迁移涉及至少两个或多个数据节点的数据修改和元数据节点的数据修改。如果在备份过程中发生数据迁移，则很难保证备份产生的数据和元数据处于一致的状态。因此，通常需要在备份过程中关闭数据迁移。MongoDB官方文档指导步骤采用了这种思路，先关闭负责数据迁移的balancer，然后依次对configserver和各shard的standby节点进行备份。关闭数据迁移的问题是集群在关闭期间无法实现数据平衡。除了影响集群的访问性能外，还会造成资源的浪费。当数据量大，需要备份的时间长时，可能会导致数据量比较大。影响。针对这两个问题，我们阿里云MongoDB团队研发了一种不需要停止外部写入，不需要关闭数据迁移，可以实现“任意”时间点恢复的分片备份方式。该功能将与即将推出的分片形态一起上线，敬请期待！阿里云MongoDB备份服务阿里云MongoDB服务提供自动备份/恢复功能。默认每天进行全量备份，自动抓取oplog进行增量备份。用户可以自定义备份策略，在控制台进行恢复。恢复时，可以选择一个备份集或者某个时间点克隆一个新实例，对新实例进行数据校验，校验OK后切换到新实例。此外，全量备份数据还提供了下载功能，用户也可以选择将备份集下载到本地，然后恢复到临时实例进行数据校验。总结说了这么多，大家应该对MongoDB的备份/恢复方式有了一个大概的了解。如果想省心，建议直接使用阿里云MongoDB服务。我们有自动备份/恢复服务和灵活的备份策略。只需轻点鼠标，即可使用任意时间点恢复、物理热备份、分片备份/恢复。这些黑科技再也不用为数据库容灾发愁了。如果你做生意，我们会承担责任。你在等什么？快来试试吧！主要关注分布式存储、Nosql数据库等技术领域。目前主要参与MongoDB云数据库的研发，致力于让开发者使用最新的MongoDB云服务。
