作者：張洪
愛可生南區 DBA 團隊成員，主要負責mysql故障處理及相關技術支持。愛好旅遊，攝影。
本文來源：原創投稿
* 愛可生開源社區出品，原創內容未經授權不得隨意使用，轉載請聯繫小編並註明來源。
概述
架構
tpbm-agent是用於執行備份、恢復，刪除和其它操作的進程，它必須運行在集羣的每個mongod實例上。包括副本集中的secondary節點以及分片集羣中的config副本集。
所有pbm-agent都會監視PBM Control集合的更新，當PBM CLI對PBM Control集合產生更新時，將會在每個副本集上選擇一個secondary上的pbm-agent執行操作，如果沒有響應則會選擇Primary上的pbm-agent執行操作。
被選中的pbm-agent將會加鎖，避免同時觸發備份和恢復等互斥操作。操作完成後將會釋放鎖，並更新PBM Control集合
PBM CLI
PBM CLI是一個操作PBM的命令行工具，它使用PBM Control集合與pbm-agent進程通信。通過更新和讀取操作、日誌等相應的PBM Control集合來啓動和監視備份和恢復操作。同時，它也將PBM配置信息保存在PBM Control集合中。
PBM Control collections
PBM Control collections是存儲配置數據和備份狀態的特殊集合，分片環境存放在config副本集的admin數據庫中，副本集則保存在自身的admin數據庫中。主要包含以下集合：
-
a dmin.pbmBackups ：備份的日誌和狀態 -
admin.pbmAgents：pbm-agent的運行狀態 -
admin.pbmConfig：PBM的配置信息 -
admin.pbmCmd：用於定義和觸發操作 -
admin.pbmLock：pbm-agent同步鎖 -
admin.pbmLockOp：用於協調不互斥的操作，如執行備份、刪除備份等 -
admin.pbmLog：存儲pbm-agent的日誌信息 -
admin.pbmOpLog：存儲操作ID -
admin.pbmPITRChunks：存儲point-in-time恢復的oplog塊 -
admin.pbmPITRState：存儲point-in-time恢復增量備份的狀態 -
admin.pbmRestores：存儲還原歷史記錄和狀態 -
admin.pbmStatus：記錄PBM備份狀態
remote backup storge遠程備份存儲是保存備份文件的位置，可以是S3存儲，也可以是Filesystem。通過pbm list命令可以查看備份集。備份文件名稱都是以UTC備份開始時間作爲前綴，每個備份都有一個元數據文件。對於備份中的每個副本集：
-
有一 個mongodump格式的壓 縮歸檔文件，它是集合的轉儲 -
覆 蓋備份時間的o plog的BSON文件轉儲
安裝配置
# wget https://downloads.percona.com/downloads/percona-backup-mongodb/percona-backup-mongodb-2.0.3/binary/tarball/percona-backup-mongodb-2.0.3-x86_64.tar.gz
解壓PBM
# tar -xvf percona-backup-mongodb-2.0.3-x86_64.tar.gz
配置環境變量
# echo "export PATH=$PATH:/usr/local/percona-backup-mongodb-2.0.3-x86_64" >> /etc/profile
# source /etc/profile
在副本集上創建PBM用戶，如果是分片環境，則每個shard以及config都需要創建
# create pbm role
shard1:PRIMARY> db.getSiblingDB("admin").createRole({ "role": "pbmAnyAction",
"privileges": [
{ "resource": { "anyResource": true },
"actions": [ "anyAction" ]
}
],
"roles": []
});
# create pbm user
shard1:PRIMARY> db.getSiblingDB("admin").createUser({user: "pbmuser",
"pwd": "secretpwd",
"roles" : [
{ "db" : "admin", "role" : "readWrite", "collection": "" },
{ "db" : "admin", "role" : "backup" },
{ "db" : "admin", "role" : "clusterMonitor" },
{ "db" : "admin", "role" : "restore" },
{ "db" : "admin", "role" : "pbmAnyAction" }
]
});
配置remote backup storge，除mongos外，每個節點都需要存在對應的備份目錄
cat > /etc/pbm_config.yaml <<EOF
storage:
type: filesystem
filesystem:
path: /data/backup
EOF
將配置寫入到數據庫中，分片集羣需要填寫config的地址
pbm config --file /etc/pbm_config.yaml --mongodb-uri "mongodb://pbmuser:[email protected]:27018,10.186.65.66:27018,10.186.65.68:27018/?replicaSet=config"
啓動每個節點對應的pbm-agent
nohup pbm-agent --mongodb-uri "mongodb://pbmuser:[email protected]:27017" > /var/log/pbm-agent-27017.log 2>&1 &
爲了後續方便，不用每次輸入--mongodb-uri，可以把PBM_MONGODB_URI設置到環境變量中
# echo 'export PBM_MONGODB_URI="mongodb://pbmuser:[email protected]:27018,10.186.65.66:27018,10.186.65.68:27018/?replicaSet=config"' >> /etc/profile
# source /etc/profile
全量備份
全量備份即對整個集羣除mongos以外進行完整的備份，只需要執行一次，就能完成整個集羣的備份。備份命令如下：
pbm backup --type=logical --mongodb-uri "mongodb://pbmuser:[email protected]:27018,10.186.65.66:27018,10.186.65.68:27018/?replicaSet=config"
pbm支持備份壓縮，目前的算法有gzip、zstd、snappy、lz4，通過--compression選項指定。同時能指定對應的壓縮級別，通過--compression-level選項指定。不同算法的壓縮級別如下所示：
| 壓縮算法 | 壓縮級別 | 默認 |
|---|---|---|
| ztsd | 1-4 | 2 |
| snappy | NULL | NULL |
| lz4 | 1-16 | 1 |
| gzip or pgzip | -1,0,1,9 | -1 |
優先級
負責備份的pbm-agent默認會在從節點中隨機選出，規定時間內從節點沒有響應，則在主節點進行備份。現在可以通過指定每個節點的備份優先級來控制備份節點選擇，避免在一個機器承載多個實例的情況下備份集中在同一臺服務器導致IO性能不足。在配置文件中加入下列配置
backup:
priority:
"10.186.65.37:27017": 2
"10.186.65.37:27018": 1
"10.186.65.68:27017": 2
-
隱 藏節點：優先級爲2
-
secondary節點：優先級爲1 -
Primary節點：優先級爲0.5
pbm status --mongodb-uri
Cluster:
========
shard3:
- shard3/10.186.65.68:27017 [P]: pbm-agent v2.0.3 OK
shard1:
- shard1/10.186.65.37:27017 [P]: pbm-agent v2.0.3 OK
shard2:
- shard2/10.186.65.66:27017 [P]: pbm-agent v2.0.3 OK
config:
- config/10.186.65.37:27018 [P]: pbm-agent v2.0.3 OK
- config/10.186.65.66:27018 [S]: pbm-agent v2.0.3 OK
- config/10.186.65.68:27018 [S]: pbm-agent v2.0.3 OK
PITR incremental backup:
========================
Status [OFF]
Currently running:
==================
(none)
Backups:
========
FS /data/backup
Snapshots:
2023-02-22T07:18:40Z 4.66MB <logical> [restore_to_time: 2023-02-22T07:18:45Z]
備份完成後，可以通過pbm list查看所有備份集，也可以通過pbm describe-backup查看備份的具體信息
# pbm list
Backup snapshots:
2023-02-22T07:18:40Z <logical> [restore_to_time: 2023-02-22T07:18:45Z]
# pbm describe-backup 2023-02-22T07:18:40Z
name: "2023-02-22T07:18:40Z"
opid: 63f5c1d0a6375c868415cac4
type: logical
last_write_time: "2023-02-22T07:18:45Z"
last_transition_time: "2023-02-22T07:18:59Z"
mongodb_version: 4.0.28
pbm_version: 2.0.3
status: done
size_h: 4.7 MiB
replsets:
- name: shard2
status: done
last_write_time: "2023-02-22T07:18:44Z"
last_transition_time: "2023-02-22T07:18:55Z"
- name: shard3
status: done
last_write_time: "2023-02-22T07:18:44Z"
last_transition_time: "2023-02-22T07:18:59Z"
- name: shard1
status: done
last_write_time: "2023-02-22T07:18:44Z"
last_transition_time: "2023-02-22T07:18:57Z"
- name: config
status: done
last_write_time: "2023-02-22T07:18:45Z"
last_transition_time: "2023-02-22T07:18:48Z"
configsvr: true
pbm logs
進行查看，有下列選項可選：
-
-t：查 看最後N行 記錄 -
-e： 查看所有備份或指定 備份 -
-n：指 定節點或副本 集 -
-s：按 日誌級別進行過濾， 從低到高依次是D(debug)、I(Info)、W(Warning)、E(Error)、F(Fatal) -
-o：以 文本或JSON格 式顯示日誌信息 -
-i ：指定操作ID
# 查看特定備份的日誌
pbm logs --tail=200 --event=backup/2023-02-22T07:18:40Z
# 查看副本集shard1的日誌
pbm logs -n shard1 -s E
如果正在運行任務想要終止，可以使用pbm canal-backup取消
pbm cancel-backup
刪除快照備份可以使用pbm delete-backup，默認刪除前會進行二次確認，指定--force選項可以直接刪除。刪除oplog chunk可以執行pbm delete-pitr
pbm delete-backup --force 2023-02-22T07:18:40Z
--older-than
參數，傳遞下列格式的時間戳
-
%Y-% M-%DT%H:%M:%S (e.g. 20 20-04-20T13:13:20) -
% Y-%M-%D (e.g. 20 20-04-20)
增量備份
Point-in-Time Recovery可以將數據還原到指定時間點，期間會從備份快照中恢復數據庫，並重放oplog到指定時間點。Point-in-Time Recovery是v1.3.0加入的，需要手動啓用pitr.enabled參數
pbm config --set pitr.enabled=true
如果想要調整時間跨度，可以配置pitr.oplogSpanMin
pbm config --set pitr.oplogSpanMin=5
oplog備份也支持壓縮，可以配置pitr.compression
pbm config --set pitr.compression=gzip
數據恢復
-
從 1.x版本開始，Percona Backu p For MongoDB複製了Mongodump的行爲，還原時只清理備份中包含的集合，對於備份之後，還原之前創建的集合不進行清理，需要在還原前手動執行db.dropDatabase()清理 -
在 恢復運行過程中，阻 止客戶端訪問數據庫 -
分片備 份只能還原到分片集羣中，還原期 間將寫入分片primary節點 -
爲避 免恢復期間pbm-age nt內存消耗，V1.3.2可以針對恢復在配置文件設置下列參數
restore:
batchSize: 500
numInsertionWorkers: 10
mongos> sh.stopBalancer()
2. 關閉所有mongos，阻止客戶端訪問
3. 如果啓用了PITR，則禁用該功能
pbm config --set pitr.enabled=false
查看備份快照和PITR有效時間點
pbm list
Backup snapshots:
2023-02-22T07:18:40Z <logical> [restore_to_time: 2023-02-22T07:18:45Z]
PITR <on>:
2023-02-22T07:18:46Z - 2023-02-22T08:36:45Z
執行PITR恢復
pbm restore --time="2023-02-22T08:30:00"
恢復完成後重新啓用PITR和balance進程，並開啓mongos對外提供服務
mongos> sh.startBalancer()
pbm config --set pitr.enabled=true
pbm restore --time="2023-02-22T08:30:00" --replset-remapping="shard1=shard4,shard2=shard5"
性能
pbm提供了性能測試工具pbm-speed-test，默認採用半隨機數據進行測試，如果要基於現有集合進行測試，請設置--sample-collection選項
pbm-speed-test storage --compression=gzip --size-gb 100
Test started
100.00GB sent in 37m17s.
Avg upload rate = 45.78MB/s
-
在 分片集羣中進行一致性備 份和恢復 -
支持完 全備份/恢復、選擇性備份恢復 等多種粒度 -
支持基 於時間點的恢復
選擇性備份和恢復
-
備份 單個數據庫或特定集合，並從中恢 復所有數據 -
從單 個數據庫備份 恢復特定的集合 -
從全備 中恢復某些數據庫或集 合 -
從全 備中Point-in-recover y某些數據庫或集合
備份指定集合時，需要指定--ns選項，格式爲<database.collection>。分片環境的URI需要填寫config的地址
pbm backup --ns=test.col1
如果要備份整個test數據庫，可以改爲下列格式
pbm backup --ns=test.*
恢復指定數據庫或集合，恢復過程中不會影響現有集羣的可用性
pbm restore 2023-02-22T07:18:40Z --ns test.col1
基於時間點恢復數據庫或集合
pbm restore --base-snapshot 2023-02-22T07:18:40Z --time 2023-02-22T09:06:00 --ns test.col1
-
只 支持邏輯備份恢 復 -
不 支持分片集合
-
不支 持批量指定names pace -
不 支持Multi-collecti on事務 -
不能 備份恢復本地數據庫中 的系統集合 -
時間 點恢復需要通過完全備份 來作爲基礎
文章推薦：
關於SQLE
SQLE 獲取
| 類型 | 地址 |
|---|---|
| 版本庫 | https://github.com/actiontech/sqle |
| 文檔 | https://actiontech.github.io/sqle-docs-cn/ |
| 發佈信息 | https://github.com/actiontech/sqle/releases |
| 數據審覈插件開發文檔 | https://actiontech.github.io/sqle-docs-cn/3.modules/3.7_auditplugin/auditplugin_development.html |
本文分享自微信公衆號 - 愛可生開源社區（ActiontechOSS）。
如有侵權，請聯繫 [email protected] 刪除。
本文參與“OSC源創計劃”，歡迎正在閱讀的你也加入，一起分享。