作者:张洪
爱可生南区 DBA 团队成员,次要负责mysql故障解决及相干技术支持。喜好游览,摄影。
本文起源:原创投稿
*爱可生开源社区出品,原创内容未经受权不得随便应用,转载请分割小编并注明起源。
概述
Percona Backup for MongoDB(PBM)是一个针对MongoDB正本集和分片的一致性备份开源工具,它反对逻辑备份、物理备份、增量备份以及选择性备份和复原等个性,并且反对Point-in-Time复原到指定工夫点。
但十分惋惜的是物理备份相干性能目前仅实用于Percona Server for MongoDB的分支,因而上面次要围绕逻辑备份与Point-in-Time来开展,MongoDB Community版本要求4.0及以上。
架构
pbm-agent
pbm-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数据库中。
次要蕴含以下汇合:
- admin.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格局的压缩归档文件,它是汇合的转储
- 笼罩备份工夫的oplog的BSON文件转储
装置配置
下载PBM
# 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:secretpwd@10.186.65.37:27018,10.186.65.66:27018,10.186.65.68:27018/?replicaSet=config"
启动每个节点对应的pbm-agent
nohup pbm-agent --mongodb-uri "mongodb://pbmuser:secretpwd@10.186.65.37:27017" > /var/log/pbm-agent-27017.log 2>&1 &
为了后续不便,不必每次输出--mongodb-uri
,能够把PBM_MONGODB_URI设置到环境变量中
# echo 'export PBM_MONGODB_URI="mongodb://pbmuser:secretpwd@10.186.65.37:27018,10.186.65.66:27018,10.186.65.68:27018/?replicaSet=config"' >> /etc/profile
# source /etc/profile
全量备份
全备反对物理备份和逻辑备份,通过–type指定,可选项有physical和logical两种。因MongoDB社区版不反对物理备份,就只围绕逻辑备份来开展。
全量备份即对整个集群除mongos以外进行残缺的备份,只须要执行一次,就能实现整个集群的备份。备份命令如下:
pbm backup --type=logical --mongodb-uri "mongodb://pbmuser:secretpwd@10.186.65.37: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
不在配置文件中的节点优先级默认为1,如果没有设置任何优先级,下列类型的节点则优先被选中
- 暗藏节点:优先级为2
- secondary节点:优先级为1
- Primary节点:优先级为0.5
备份治理
查看pbm状态
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. 2020-04-20T13:13:20)
- %Y-%M-%D (e.g. 2020-04-20)
增量备份
Point-in-Time Recovery能够将数据还原到指定工夫点,期间会从备份快照中复原数据库,并重放oplog到指定工夫点。Point-in-Time Recovery是v1.3.0退出的,须要手动启用pitr.enabled参数
pbm config --set pitr.enabled=true
在启用Point-in-Time Recovery之后,pbm-agent会定期保留oplog chunk,一个chunk蕴含10分钟跨度的oplog事件,如果禁用工夫点复原或因备份快照操作的开始而中断,则工夫可能会更短。oplog保留在近程存储的pbmPitr子目录中,chunk的名称反映了开始工夫和完结工夫
如果想要调整时间跨度,能够配置pitr.oplogSpanMin
pbm config --set pitr.oplogSpanMin=5
oplog备份也反对压缩,能够配置pitr.compression
pbm config --set pitr.compression=gzip
数据恢复
复原注意事项
通过pbm store命令并指定还原工夫戳,在还原之前还须要留神以下几点:
- 从1.x版本开始,Percona Backup For MongoDB复制了Mongodump的行为,还原时只清理备份中蕴含的汇合,对于备份之后,还原之前创立的汇合不进行清理,须要在还原前手动执行db.dropDatabase()清理
- 在复原运行过程中,阻止客户端拜访数据库
- 分片备份只能还原到分片集群中,还原期间将写入分片primary节点
-
为防止复原期间pbm-agent内存耗费,V1.3.2能够针对复原在配置文件设置下列参数
restore: batchSize: 500 numInsertionWorkers: 10
分片集群复原
分片集群在做复原前,须要先实现以下步骤
-
进行balancer
mongos> sh.stopBalancer()
- 敞开所有mongos,阻止客户端拜访
-
如果启用了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
异机复原
从v1.8版本开始,能够将逻辑备份复原到具备雷同或更多shard的新环境中,并且这些shard的正本集名称能够与原环境不同。但咱们须要配置以下映射关系
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
pbm整体的性能绝对于mongodump并没有较大的晋升,次要还是体现在下列几个特点:
- 在分片集群中进行一致性备份和复原
- 反对齐全备份/复原、选择性备份复原等多种粒度
- 反对基于工夫点的复原
选择性备份和复原
选择性备份和复原性能能够针对指定的数据库或汇合,但目前还只是一个试验性功能,审慎应用。它具备以下场景选项:
- 备份单个数据库或特定汇合,并从中复原所有数据
- 从单个数据库备份复原特定的汇合
- 从全备中复原某些数据库或汇合
- 从全备中Point-in-recovery某些数据库或汇合
备份指定汇合时,须要指定--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
已知限度
- 只反对逻辑备份复原
- 不反对分片汇合
- 不反对批量指定namespace
- 不反对Multi-collection事务
- 不能备份复原本地数据库中的零碎汇合
- 工夫点复原须要通过齐全备份来作为根底
参考链接:https://docs.percona.com/percona-backup-mongodb/intro.html