1、MongoDB 秒级备份恢复方案技术创新，变革未来rm-rf2017年1月你的数据库备份了吗？2017年2月你的数据库备份有效吗？Next?历史的经验教训MongoDB复制集思考：3节点复制集为什么还需要备份？MongoDB云数据库备份/恢复PrimarySecondaryHiddenAliyun OSS从hidden节点备份每天一次全量备份持续拉取oplog增量备份定期巡检备份有效性恢复时克隆到新实例fullbackup 20170317Insert AInsert BUpdate CUpdate Afullbackup 20170318Delete B时间序tailing oplogMon
2、goDB Replica Set备份抽检备份恢复PrimarySecondaryHiddenMongoDB Replica SetDatabase LayerFile System LayerVolume/Block Layercp/scprsynclvm snapshot Amazon EBSAliyun ECS Cloud Diskcloud managerFile System snapshotmongodumpmongoexport物理 备份逻辑 备份全量备份方法逻辑备份流程-mongodumpdb1.collection1db1.collection2db2.collection3d
3、b2.collection4g1Achive fileMongoDB serverg 2Collection Backup goroutineg 3Multiplexer goroutineAliyun OSSpipeline upload全量遍历所有数据、备份、恢复慢对业务影响较大无需备份索引、恢复时重建通用性强file1.wtfile2.wtfile3.wtfile4.wtMongoDB dbpathAchive fileAliyun OSSpipeline upload物理备份流程拷贝数据目录所有文件，效率高备份、恢复快对业务影响较小跟数据库版本、配置强关联逻辑备逻辑备份份物理备物理备份
4、份备份效率低数据库接口读取数据高拷贝物理文件恢复效率低下载备份集+导入数据+建立索引高下载备份集+启动进程备份影响大直接与业务争抢资源小备份集大小比原库小无需备份索引数据与原库相同兼容性兼容绝大部分版本可跨存储引擎依赖存储布局逻辑备份 vs 物理备份增量备份原理dataoplogPrimarydataoplogSecondary1client write234456Insert AUpdate BDelete CInsert DDelete Acapped collection+idempotent增量备份Aliyun OSS backup agent 持续拉取新的 oplog oplog t
5、ailable cursor全量备份增量备份任意时间点备份+=恢复至任意时间点全量逻辑备份如何对应到时间点？全量物理备份如何对应到时间点？增量备份如何确保拉到所有的oplog？如何确保备份集可恢复？如何处理备份过程中的异常？问题与挑战可正确恢复数据+对应到某个时间点有效备份集2要素 支持在线修改oplog，配合 mongodump-oplog db.runCommand(collMod:“oplog.rs”,maxSize:1024000000 )逻辑备份 传统方法：移除或锁定secondary节点停写备份，加回去同步可能追不上 改进方法：修改wiredtiger引擎，支持在线热备份，不影响写
6、入物理备份 修改MongoDB源码支持设置 oplogDeleteGuard db.runCommand(collMod:“oplog.rs”,oplogDeleteGuard:1400000000 )增量备份 MD5校验避免传输过程中错误 定期抽检实例备份集，验证备份集是否可恢复备份验证 备份失败时自动failover重试 hidden节点故障时，到secondary备份，最后尝试primary异常处理解决方案MongoDB Shardingmongos负责路由，无状态Config Server 存储元数据Shard 存储实际用户数据数据根据shardKey分散到各个shard自动在shar
7、d间迁移数据做负载均衡Sharding备份策略Backup from Shards+CSBackup from Mongos备份、恢复效率低恢复时数据重新分布支持异构集群间恢复并行备份、恢复，效率高恢复出来的数据与原Sharding完全相同Shard恢复 到任意时间点CS恢复到任意时间点Sharding恢复到 任意时间点备份+=？Sharding备份挑战Sharding备份挑战自动负载均衡Shard1chunk1chunk3chunk2moveChunkchunk1chunk3Shard2chunk4moveChunkchunk2chunk4chunk1-shard1chunk1-shard1
8、chunk2-shard2 chunk3-shard1 chunk4-shard2Config Serverchunk2-shard1chunk3-shard1moveChunkchunk4-shard2时间序解决方案传统方案停止 Balancer负载可能不均衡出现热点move Chunk改进后方案（节点间时钟误差不能太大）开启 Balancer分析 Config server 迁移日志恢复时避开 chunk 迁移的时间区间move Chunkmove Chunkmove Chunk备份产品形态支持恢复到任意时间点支持实例覆盖性恢复支持根据备份集创建新实例备份集可下载，方便迁移默认保留最近7天备份备份时间段、周期可配置有备无患
