MongoDB秒級備份恢復方案技術(shù)創(chuàng)新，變革未來MongoDB秒級備份恢復方案技術(shù)創(chuàng)新，變革未來1?rm

-rf2017年1月你的數(shù)據(jù)庫備份了嗎？2017年2月你的數(shù)據(jù)庫備份有效嗎？Next?歷史的經(jīng)驗教訓rm-rf2017年1月2017年2月Next?歷史的經(jīng)驗2MongoDB復制集思考：3節(jié)點復制集為什么還需要備份？MongoDB復制集思考：3節(jié)點復制集為什么還需要備份？3MongoDB云數(shù)據(jù)庫備份/恢復PrimarySecondaryHiddenAliyun

OSS從hidden節(jié)點備份每天一次全量備份持續(xù)拉取oplog增量備份定期巡檢備份有效性恢復時克隆到新實例fullbackup20170317Insert

AInsert

BUpdate

CUpdate

Afullbackup20170318Delete

B時間序tailingoplogMongoDBReplica

Set備份抽檢備份恢復PrimarySecondaryHiddenMongoDBReplica

SetMongoDB云數(shù)據(jù)庫備份/恢復PrimarySeconda4DatabaseLayerFile

SystemLayerVolume/BlockLayercp/scprsynclvm

snapshotAmazon

EBSAliyun

ECSCloud

DiskcloudmanagerFile

Systemsnapshotmongodumpmongoexport物理備份邏輯備份全量備份方法DatabaseLayerFileSystemLa5邏輯備份流程

-

mongodumpdb1.collection1db1.collection2db2.collection3db2.collection4g1Achive

fileMongoDBserverg2CollectionBackup

goroutineg3MultiplexergoroutineAliyunOSSpipelineupload全量遍歷所有數(shù)據(jù)、備份、恢復慢對業(yè)務影響較大無需備份索引、恢復時重建通用性強邏輯備份流程-mongodumpdb1.collecti6file1.wtfile2.wtfile3.wtfile4.wtMongoDBdbpathAchive

fileAliyunOSSpipelineupload物理備份流程拷貝數(shù)據(jù)目錄所有文件，效率高備份、恢復快對業(yè)務影響較小跟數(shù)據(jù)庫版本、配置強關(guān)聯(lián)file1.wtfile2.wtfile3.wtfile4.7邏輯備份物理備份備份效率低數(shù)據(jù)庫接口讀取數(shù)據(jù)高拷貝物理文件恢復效率低下載備份集

+

導入數(shù)據(jù)

+

建立索引高下載備份集

+

啟動進程備份影響大直接與業(yè)務爭搶資源小備份集大小比原庫小無需備份索引數(shù)據(jù)與原庫相同兼容性兼容絕大部分版本可跨存儲引擎依賴存儲布局邏輯備份

vs

物理備份邏輯備份物理備份備份效率低高恢復效率低高備份影響大小備份集大8增量備份原理dataoplogPrimarydataoplogSecondary1client

write234456Insert

AUpdate

BDelete

CInsert

DDelete

Acapped

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

OSSbackup agent 持續(xù)拉取新的 oplogoplog tailable cursor增量備份AliyunOSSbackup agent 持續(xù)拉10全量備份增量備份任意時間點備份+=恢復至任意時間點全量備份增量備份任意時間點備份+=恢復至任意時間點11全量邏輯備份如何對應到時間點？全量物理備份如何對應到時間點？增量備份如何確保拉到所有的oplog？如何確保備份集可恢復？如何處理備份過程中的異常？問題與挑戰(zhàn)可正確恢復數(shù)據(jù)+對應到某個時間點有效備份集2要素全量邏輯備份如何對應到時間點？如何確保備份集可恢復？如何處理12支持在線修改oplog，配合

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

)邏輯備份傳統(tǒng)方法：移除或鎖定secondary節(jié)點停寫備份，加回去同步可能追不上改進方法：修改wiredtiger引擎，支持在線熱備份，不影響寫入物理備份修改MongoDB源碼支持設(shè)置

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

)增量備份MD5校驗避免傳輸過程中錯誤定期抽檢實例備份集，驗證備份集是否可恢復備份驗證備份失敗時自動failover重試hidden節(jié)點故障時，到secondary備份，最后嘗試primary異常處理解決方案支持在線修改oplog，配合mongodump–-opl13MongoDB

Shardingmongos負責路由，無狀態(tài)Config

Server

存儲元數(shù)據(jù)Shard

存儲實際用戶數(shù)據(jù)數(shù)據(jù)根據(jù)shardKey分散到各個shard自動在shard間遷移數(shù)據(jù)做負載均衡MongoDBShardingmongos負責路由，無狀態(tài)14Sharding備份策略Backup

fromShards+

CSBackup

fromMongos備份、恢復效率低恢復時數(shù)據(jù)重新分布支持異構(gòu)集群間恢復并行備份、恢復，效率高恢復出來的數(shù)據(jù)與原Sharding完全相同Sharding備份策略BackupfromShard15Shard恢復到任意時間點CS恢復到任意時間點Sharding恢復到任意時間點備份+=？Sharding備份挑戰(zhàn)Shard恢復到任意時間點CS恢復Sharding恢復到16Sharding備份挑戰(zhàn)–自動負載均衡Shard1chunk1chunk3chunk2moveChunkchunk1chunk3…Shard2chunk4moveChunkchunk2chunk4…chunk1->shard1chunk1->shard1chunk2->shard2chunk3->shard1chunk4->shard2ConfigServerchunk2->shard1chunk3->shard1moveChunk…chunk4->shard2時間序Sharding備份挑戰(zhàn)–自動負載均衡ConfigSer17解決方案傳統(tǒng)方案停止

Balancer負載可能不均衡出現(xiàn)熱點moveChunk改進后方案（節(jié)點間時鐘誤差不能太大）開啟 Balancer分析 Config server 遷移日志恢復時避開 chunk 遷移的時間區(qū)間moveChunk