从炉石传说数据库故障谈谈MongoDB的数据库备份和恢复手段

  • 时间:
  • 浏览:1
  • 来源:大发彩票快三—大发彩票app

对性能的影响

在mongodump执行过程中怎么让数据库还有新的修改,直接运行dump出来的结果是否 4个一致的快照,都能否 了使用4个『–oplog』的选项来将你是什么 过程中的oplog也一块dump下来(使用mongorestore进行恢复时对应要使用–oplogReplay选项对oplog进行重放)。而怎么让MongoDB的oplog是4个固定大小的特殊集合,当oplog集合达到配置的大小时旧的oplog会被滚掉以为新的oplog腾出空间。在使用『–oplog』选项进行dump时,mongodump会在dump集合数据前获取当时最新的oplog时间点,并在集合数据dump完毕完后 再次检查你是什么 时间点的oplog是否 还在,怎么让dump过程很长,oplog空间又缺乏,oplog被滚掉就会dump失败。怎么让在dump前最好检查一下oplog的配置大小以及目前oplog的增长状态(可结合业务写入量及oplog平均大小进行粗略估计),确保dump不用失败。目前亲们阿里云MongoDB服务针对oplog做了弹性扩缩容的优化,能否 确保在逻辑备份过程中oplog不被滚掉,一定能否 备份成功。

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

对于集合数据,mongodump出来的结果是4个个bson文件。而对于集合的索引,则是描述在4个metadata的json文件里,中间还含高创建集合时所使用的选项。在使用mongorestore进行恢复时,会在集合数据恢复完毕完后 进行对应的索引创建。

对于数据量比较小的场景,使用官方的mongodump/mongorestore工具进行全量的备份和恢复就足够了。mongodump都能否 连上4个正在服务的mongod节点进行逻辑热备份。其主要原理是遍历所有集合,怎么让将文档一根 条读出来,支持并发dump多个集合,怎么让支持归档和压缩,都能否 输出到4个文件(或标准输出)(对原理感兴趣都能否 参见我完后 写的两篇文章Mongodump的archive(归档)模式原理解析以及Mongorestore的archive(归档)模式恢复原理解析)。同样,mongorestore则是连上4个正在服务的mongod节点进行逻辑恢复。其主要原理是将备份出来的数据再一根 条写回到数据库中。

MongoDB数据库备份手段

物理备份通过拷贝数据文件来实现,这要求所有被拷贝的数据文件都能否 了是4个一致的数据快照。怎么让物理备份的实施法律依据和MongoDB采用的存储引擎有关,怎么让,根据是否 配置MongoDB打开了Journal,在实施的细节上会有你是什么 不同,具体可参考官方文档。不管使用何种存储引擎,在3.2版本完后 ,都都能否 用以下法律依据实现物理备份:

怎么让执行db.fsyncLock()会加数据库的全局写锁,这时数据库会趋于稳定4个不可访问的状态,怎么让物理备份最好也在备节点上执行(最好是hidden,注意同样都能否 了确保物理备份完成完后 节点的oplog能追上主节点)。目前亲们阿里云MongoDB团队怎么让研发出了不用停写服务的物理热备份手段,相信变快就都能否 让亲们用上,尽请期待!

针对这两大难题,亲们阿里云MongoDB团队研发了都能否 了了停内部管理写,怎么让不用关数据迁移的Sharding备份手段,能否 实现『任意』时间点恢复,你是什么 功能将伴随着即将推出的Sharding社会形态一起推出,尽情期待!

MongoDB的增量备份都能否 通过持续抓取oplog来实现,你是什么 目前都能否 了现成的工具都能否 利用,都能否 了被委托人代码实现。抓取oplog主要的难题也和使用mongodump进行全量备份一样,需确保要抓取的oplog不被滚掉。目前亲们阿里云MongoDB服务实现了自动增量备份的功能,结合全量备份都能否 实现任意时间点恢复功能。

看多你是什么 消息,我的第一反应是重新翻出尘封已久的ipad,装上炉石准备上线领补偿。等等,作为4个数据库行业从业人员,是否 还应该干点有哪些?恩,很有必要再重新审视一下亲们的数据库有都能否 了做好容灾,怎么让,今天你看别人热闹,明天怎么让就别人看你热闹了。借此怎么让让我 给亲们普及一下MongoDB数据库的备份和恢复手段(当然炉石传说应该不一定是使用MongoDB作为数据库),以帮助亲们做好容灾,过个好年。一起,我也为亲们阿里云MongoDB服务做下广告,亲们的MongoDB服务拥有完善的自动备份/恢复功能,灵活的备份策略,好用的恢复到任意时间点功能。亲们的备份存放了多份副本,可靠性达10个9,请亲们放心使用!

索引的备份和恢复

实施法律依据

恢复时都能否 选着 某4个备份集或某4个时间点基因重组出4个新的实例,都能否 在新实例上进行数据校验,等校验没难题后切换到新实例。此外,全量备份的数据还提供下载功能,用户也都能否 选着 下载备份集到本地后恢复到4个临时实例进行数据校验。

全量逻辑备份/恢复

还是在刚才的mongoshell上(这里都能否 了保证和完后 是同4个连接),执行以下命令以重新允许新的写入:

阿里云MongoDB服务提供自动备份/恢复功能,默认每天为数据进行全量备份,怎么让自动抓取oplog进行增量备份。用户都能否 在控制台自定义备份策略以及进行恢复。

Sharding的备份/恢复

总结

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

全量物理备份/恢复

来源:51CTO

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

Mongodump/Mongorestore

增量备份

本文作者:郑涔

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

mongodump执行过程怎么让会遍历所有数据,怎么让会对MongoDB性能有影响,最好在备节点执行(最好是hidden,需检查备节点数据同步是否 正常)。

说了都能否 了多,亲们应该对MongoDB的备份/恢复手段有了4个大约的认识。怎么让要图省心,还是建议直接使用阿里云MongoDB服务,亲们有自动化的备份/恢复服务,灵活的备份策略,只需点点鼠标就能用上任意时间点恢复、物理热备份、Sharding备份/恢复有有哪些黑科技,从此不再为数据库容灾发愁,业务亲们做,锅有亲们来背,还等有哪些呢,快来试用吧!

阿里云MongoDB备份服务

获取一致的数据快照