標籤:要求 執行命令 ack 時間 研究 show linux 資料 弊端
背景及原理
資料庫的備份是災難恢複的最後一道屏障,不管什麼類型的資料庫都需要設定Database Backup,MongoDB也不例外。MongoDB 3.0 後 ,資料庫可以採用Wiredtiger儲存引擎後(3.2 版本預設),在此環境下通過mongodump 備份後,產生的備份檔案要遠大於資料儲存檔案的大小。此外,一般MongoDB儲存的資料量比較大,備份檔案也比較大,佔用了很多磁碟空間。所以,研究如何?MongoDB備份壓縮很有必要。
是執行命令 db.stats() 查看某資料庫的資訊。
備份檔案的大小一般為dataSize的大小,所以我們希望壓縮備份,可以達到storageSize 或者更小。
一般的備份思路是先備份,後對備份檔案進行壓縮。之前,我們採用的就是這種方式,例如主要壓縮命令如下
tar -cf - ${targetpath}/${nowtime} | pigz -p 10 > ${targetpath}/${nowtime}.tgz
(命令解釋: targetpath}/${nowtime 為待壓縮的備份檔案;pigz 是Linux壓縮神器,可並行壓縮;-p是指定cpu的核心數。)
但是這種方式,產生備份檔案的過程中還是容易形成磁碟效能壓力和空間壓力。為我們某台Server 採用先備份後壓縮方式,形成的磁碟可用空間變化。
真正希望的是在備份的同時進行壓縮,這樣可用空間就比較平穩了。在MongoDB 3.2 中 引入了一種壓縮式備份【此mongodb版本必須不低於3.2】。可以使用gzip進行壓縮。這是通過在mongodump和mongorestore中引入一個新的指令行選項“- -gzip”實現的。
壓縮可用於目錄以及歸檔模型下建立的備份,壓縮還可以減少磁碟空間使用。
測試
測試環境:
測試伺服器 |
測試資料庫 |
連接埠 |
檔案路徑 |
172.X.X.245 |
執行個體全備 |
17219 |
/data/mongodb_back |
172.X.X.246 |
QQ_DingDing |
17218 |
/data/mongodb_back/QQ_DingDing |
Step 1 壓縮式備份的命令:
./mongodump --host 172.X.X.245 --port 17219 -u 使用者名稱 -p "密碼" --gzip --authenticationDatabase "admin" --out /data/mongodb_back
備份後檔案的大小,97M
這時候,查看備份檔案的格式都變成了.gz的格式
Step 2 將備份檔案copy至遠程機器上,進行還原:
以下命令是將在172.X.X.246,要求是將檔案從X.245 copy至本地
scp -r [email protected]:/data/mongodb_back/QQ_DingDing
step 3 執行還原的命令
執行的命令
./mongorestore --host 172.X.X.246 --port 17218 -d QQ_DingDing -u 使用者名稱 -p "密碼" --gzip --authenticationDatabase "admin" /data/mongodb_back/QQ_DingDing
還原後登入MongoDB,執行show dbs,查看此時 資料大小為500M。
補充說明
(1) 如果不採用壓縮式的備份,備份後的檔案會是多大呢?備份命令 :
./mongodump --host 172.X.X.245 --port 17219 -u 使用者名稱 -p "密碼" --authenticationDatabase "admin" --out /data/mongodb_back2
查看此種方法備份後的檔案大小--1.5G。
以此QQ_DingDing資料庫為例,其壓縮率為(檔案壓縮後的大小與壓縮前的大小之比):97M/1.5G=97/1536=6.3%
(2) 這種壓縮備份的方式的會不會帶來一些弊端:例如備份時間增長?(恢復增加?,請自測一下試試,嘻嘻 @@@)
以 某歸檔備份庫所在執行個體為例(storageSize 150G,dataSize 600G )
採用 先備份後壓縮的方式耗時1小時55分鐘
採用壓縮式備份(指定--gzip參數)的方式耗時 2小時33分鐘
產生的備份檔案大小基本相等,壓縮式備份方式產生的備份檔案略小
所以 壓縮式備份會導致備份時間增長。
但從空間使用的角度來講,我們仍然建議大家使用壓縮式備份,其壓縮比非常高(測試案例的壓縮比6.3%)。
MongoDB 如何?備份壓縮