MongoDB-秒级备份恢复方案

MongoDB秒级备份恢复方案技术创新，变革未来MongoDB秒级备份恢复方案技术创新，变革未来1rm

-rf2017年1月你的数据库备份了吗？2017年2月你的数据库备份有效吗？Next?历史的经验教训rm-rf2017年1月2017年2月Next?历史的经验2MongoDB复制集思考：3节点复制集为什么还需要备份？MongoDB复制集思考：3节点复制集为什么还需要备份？3MongoDB云数据库备份/恢复PrimarySecondaryHiddenAliyun

OSS从hidden节点备份每天一次全量备份持续拉取oplog增量备份定期巡检备份有效性恢复时克隆到新实例fullbackup20170317Insert

AInsert

BUpdate

CUpdate

Afullbackup20170318Delete

B时间序tailingoplogMongoDBReplica

Set备份抽检备份恢复PrimarySecondaryHiddenMongoDBReplica

SetMongoDB云数据库备份/恢复PrimarySeconda4DatabaseLayerFile

SystemLayerVolume/BlockLayercp/scprsynclvm

snapshotAmazon

EBSAliyun

ECSCloud

DiskcloudmanagerFile

Systemsnapshotmongodumpmongoexport物理备份逻辑备份全量备份方法DatabaseLayerFileSystemLa5逻辑备份流程

-

mongodumpdb1.collection1db1.collection2db2.collection3db2.collection4g1Achive

fileMongoDBserverg2CollectionBackup

goroutineg3MultiplexergoroutineAliyunOSSpipelineupload全量遍历所有数据、备份、恢复慢对业务影响较大无需备份索引、恢复时重建通用性强逻辑备份流程-mongodumpdb1.collecti6file1.wtfile2.wtfile3.wtfile4.wtMongoDBdbpathAchive

fileAliyunOSSpipelineupload物理备份流程拷贝数据目录所有文件，效率高备份、恢复快对业务影响较小跟数据库版本、配置强关联file1.wtfile2.wtfile3.wtfile4.7逻辑备份物理备份备份效率低数据库接口读取数据高拷贝物理文件恢复效率低下载备份集

+

导入数据

+

建立索引高下载备份集

+

启动进程备份影响大直接与业务争抢资源小备份集大小比原库小无需备份索引数据与原库相同兼容性兼容绝大部分版本可跨存储引擎依赖存储布局逻辑备份

vs

物理备份逻辑备份物理备份备份效率低高恢复效率低高备份影响大小备份集大8增量备份原理dataoplogPrimarydataoplogSecondary1client

write234456Insert

AUpdate

BDelete

CInsert

DDelete

Acapped

collection+ idempotent…增量备份原理dataoplogPrimarydataoplo9增量备份Aliyun

OSSbackup agent 持续拉取新的 oplogoplog tailable cursor增量备份AliyunOSSbackup agent 持续拉10全量备份增量备份任意时间点备份+=恢复至任意时间点全量备份增量备份任意时间点备份+=恢复至任意时间点11全量逻辑备份如何对应到时间点？全量物理备份如何对应到时间点？增量备份如何确保拉到所有的oplog？如何确保备份集可恢复？如何处理备份过程中的异常？问题与挑战可正确恢复数据+对应到某个时间点有效备份集2要素全量逻辑备份如何对应到时间点？如何确保备份集可恢复？如何处理12支持在线修改oplog，配合

mongodump–-oplogdb.runCommand({collMod:“oplog.rs”,maxSize:1024000000}

)逻辑备份传统方法：移除或锁定secondary节点停写备份，加回去同步可能追不上改进方法：修改wiredtiger引擎，支持在线热备份，不影响写入物理备份修改MongoDB源码支持设置

oplogDeleteGuarddb.runCommand({collMod:“oplog.rs”,oplogDeleteGuard:1400000000}

)增量备份MD5校验避免传输过程中错误定期抽检实例备份集，验证备份集是否可恢复备份验证备份失败时自动failover重试hidden节点故障时，到secondary备份，最后尝试primary异常处理解决方案支持在线修改oplog，配合mongodump–-opl13MongoDB

Shardingmongos负责路由，无状态Config

Server

存储元数据Shard

存储实际用户数据数据根据shardKey分散到各个shard自动在shard间迁移数据做负载均衡MongoDBShardingmongos负责路由，无状态14Sharding备份策略Backup

fromShards+

CSBackup

fromMongos备份、恢复效率低恢复时数据重新分布支持异构集群间恢复并行备份、恢复，效率高恢复出来的数据与原Sharding完全相同Sharding备份策略BackupfromShard15Shard恢复到任意时间点CS恢复到任意时间点Sharding恢复到任意时间点备份+=？Sharding备份挑战Shard恢复到任意时间点CS恢复Sharding恢复到16Sharding备份挑战–自动负载均衡Shard1chunk1chunk3chunk2moveChunkchunk1chunk3…Shard2chunk4moveChunkchunk2chunk4…chunk1->shard1chunk1->shard1chunk2->shard2chunk3->shard1chunk4->shard2ConfigServerchunk2->shard1chunk3->shard1moveChunk…chunk4->shard2时间序Sharding备份挑战–自动负载均衡ConfigSer17解决方案传统方案停止

Balancer负载可能不均衡出现热点moveChunk改进后方案（节点间时钟误差不能太大）开启 Balancer分析 Config server 迁移日志恢复时避开 chunk 迁移的时间区间moveChunk