MongoDB数据库灾难恢复解决方案

1、MongoDB数据库灾难恢复解决方案AgendaRTO & RPO常规解决架构极端情况下如何恢复123RTO & RPO企业的生产系统架构需要解决一下风险：1、存在数据丢失风险2、存在数据服务长时间中断风险而相应地，系统业务等级划分与标准一般如下：等级标准说明核心系统（A）直接影响业务营收、财务、生产或全局使用 要求7*24h不能中断重要系统（B）直接影响业务营收、财务、生产或全局使用 要求5*12h不能中断一般系统（C）非核心、重要系统，局部使用管理系统 要求5*8h开发&测试环境（D）内部开发&测试系统，要求5*8hRTO & RPO衡量连续性水平主要指标是恢复时间目标（RTO）和恢复点目

2、标（RPO）。 恢复时间目标（RTO）：企业可容许服务中断的时长；恢复点目标（RPO）：指当服务恢复后，恢复得来的数据所对应时的间点。基于上面的原则，会通过以下的办法进行规划：连续性等级同城RPO同城RTO异地RPO异地RTO同城应用异地应用高核心系统 重要系统0或接近0 15分钟 15分钟 1小时数据块级同步复制 数据库本地热备数据逻辑异步复制 数据库本地热备低一般系统 5分钟 30分钟 30分钟 2小时数据块级异步复制 数据库本地热备数据逻辑异步复制 数据库本地热备AgendaRTO & RPO常规解决架构极端情况下如何恢复123常规解决架构-1Replicate setSharding

3、Cluster常规解决架构-2目标场景解决方案同城/异地容灾Replicate set + 一主多从误操作数据保护Replicate set + 一主多从 + Hidden Delay Node大规模并发系统Sharding Cluster + replicate set异地多活Sharding Cluster + Zone分区 + replicate setPoint-In-Time recovery（基于时间点恢复）Ops backup/Mongodump +oplog applyAgendaRTO & RPO常规解决架构极端情况下如何恢复123极端环境下的恢复由于各种“原因” ，经费没有

4、下来数据误删了，可我们没有可用备份单机环境下，repair等一系列操作后之后， mongo还是无 法启动但假如我们面对下面的数据丢失的场景时极端环境下的恢复我们真的没有办法了吗或许我们还可以用这个方法再挣扎一下极端环境下的恢复我们的救星在哪里？我们的救星在这里 那要怎么做？先把原来的数据文件目录拷贝走，避免二次伤害检查确认MongoDB中的WT版本，准备安装WT编译环境开始编译WT command line环境源码与材料准备 /wiredtiger/wiredtiger/google/snappy/releases/download/1.1.4/snappy-1.1.4.tar.gz/zlib

5、-1.2.11.tar.gz/3.1.0/command_line.html -操作手册开始编译WT command line环境源码安装cmake编译./bootstrap & make & make installsnappy编译(需要cmake)./configure./config.statusmake & make installzlib编译./configuremake & make installwiredtiger编译./configure -with-builtins=zlib,snappy make通过command line分析WT文件流程：找到需要分析的wt源文件进行文

6、件分析将WT文件dump出加载到恢复数据库环境启动恢复环境的mongodWT文件处理分析文件./wiredtiger-2.5.3/wt -v -h ./recovery_path/ -R salvage xxxxx/collection/75-2214465*.wt session.salvage 56468dump文件./wiredtiger-2.5.3/wt -v -h ./recovery_path/ -R dump -f ./target.dump xxxxx/collection/75-2214465*.wtload文件到./wiredtiger-2.5.3/wt -v -h ./recovery_path/ -R salvage xxxxx/collection/75-2214465*.wt sessio