MongoDB秒級備份恢復方案

1、MongoDB 秒級備份恢復方案技術(shù)創(chuàng)新，變革未來rm -rf2017年1月你的數(shù)據(jù)庫備份了嗎？2017年2月你的數(shù)據(jù)庫備份有效嗎？Next?歷史的經(jīng)驗教訓MongoDB復制集思考：3節(jié)點復制集為什么還需要備份？MongoDB云數(shù)據(jù)庫備份/恢復PrimarySecondaryHiddenAliyun OSS從hidden節(jié)點備份每天一次全量備份持續(xù)拉取oplog增量備份定期巡檢備份有效性恢復時克隆到新實例fullbackup 20170317Insert AInsert BUpdate CUpdate Afullbackup 20170318Delete B時間序tailing oplogMo

2、ngoDB Replica Set備份抽檢備份恢復PrimarySecondaryHiddenMongoDB Replica SetDatabase LayerFile System LayerVolume/Block Layercp/scprsynclvm snapshot Amazon EBSAliyun ECS Cloud Diskcloud managerFile System snapshotmongodumpmongoexport物理 備份邏輯 備份全量備份方法邏輯備份流程 - mongodumpdb1.collection1db1.collection2db2.collectio

3、n3db2.collection4g1Achive fileMongoDB serverg 2Collection Backup goroutineg 3Multiplexer goroutineAliyun OSSpipeline upload全量遍歷所有數(shù)據(jù)、備份、恢復慢對業(yè)務影響較大無需備份索引、恢復時重建通用性強file1.wtfile2.wtfile3.wtfile4.wtMongoDB dbpathAchive fileAliyun OSSpipeline upload物理備份流程拷貝數(shù)據(jù)目錄所有文件，效率高備份、恢復快對業(yè)務影響較小跟數(shù)據(jù)庫版本、配置強關(guān)聯(lián)邏輯備份物理備份備份效率

4、低數(shù)據(jù)庫接口讀取數(shù)據(jù)高拷貝物理文件恢復效率低下載備份集 + 導入數(shù)據(jù) + 建立索引高下載備份集 + 啟動進程備份影響大直接與業(yè)務爭搶資源小備份集大小比原庫小無需備份索引數(shù)據(jù)與原庫相同兼容性兼容絕大部分版本可跨存儲引擎依賴存儲布局邏輯備份 vs 物理備份增量備份原理dataoplogPrimarydataoplogSecondary1client write234456Insert AUpdate BDelete CInsert DDelete Acapped collection +idempotent增量備份Aliyun OSSbackupagent持續(xù)拉取新的oplogoplogtaila

5、blecursor全量備份增量備份任意時間點備份+=恢復至任意時間點全量邏輯備份如何對應到時間點？全量物理備份如何對應到時間點？ 增量備份如何確保拉到所有的oplog？如何確保備份集可恢復？如何處理備份過程中的異常？問題與挑戰(zhàn)可正確恢復數(shù)據(jù)+對應到某個時間點有效備份集2要素支持在線修改oplog，配合 mongodump -oplogdb.runCommand( collMod: “oplog.rs”, maxSize: 1024000000 )邏輯備份傳統(tǒng)方法：移除或鎖定secondary節(jié)點停寫備份，加回去同步可能追不上改進方法：修改wiredtiger引擎，支持在線熱備份，不影響寫入物理

6、備份修改MongoDB源碼支持設置 oplogDeleteGuarddb.runCommand( collMod: “oplog.rs”, oplogDeleteGuard: 1400000000 )增量備份MD5校驗避免傳輸過程中錯誤定期抽檢實例備份集，驗證備份集是否可恢復備份驗證備份失敗時自動failover重試hidden節(jié)點故障時，到secondary備份，最后嘗試primary異常處理解決方案MongoDB Shardingmongos負責路由，無狀態(tài)Config Server 存儲元數(shù)據(jù)Shard 存儲實際用戶數(shù)據(jù)數(shù)據(jù)根據(jù)shardKey分散到各個shard自動在shard間遷移數(shù)

7、據(jù)做負載均衡Sharding備份策略Backup from Shards + CSBackup from Mongos備份、恢復效率低恢復時數(shù)據(jù)重新分布支持異構(gòu)集群間恢復并行備份、恢復，效率高恢復出來的數(shù)據(jù)與原Sharding完全相同Shard恢復 到任意時間點CS恢復到任意時間點Sharding恢復到 任意時間點備份+=？Sharding備份挑戰(zhàn)Sharding備份挑戰(zhàn)自動負載均衡Shard1chunk1chunk3chunk2moveChunkchunk1chunk3Shard2chunk4moveChunkchunk2chunk4chunk1-shard1chunk1-shard1chunk2-shard2 chunk3-shard1 chunk4-shard2Config Serverchunk2-shard1chunk3-shard1moveChunkchunk4-shard2時間序解決方案傳統(tǒng)方案停止 Balancer負載可能不均衡出現(xiàn)熱點move Chunk改進后方案（節(jié)點間時鐘誤差不能太大）開啟Balancer分析Configserver遷移日志