CNDBA社区
1 MongoDB 分片集群备份现存问题
在之前的博客我们了解了 分片集群环境的搭建和MongoDB的备份恢复，如下：
MongoDB 4.4 分片集群（3 shard） 搭建手册
https://www.cndba.cn/dave/article/107970MongoDB 备份与恢复 说明
https://www.cndba.cn/dave/article/107972
关于分片集群的备份，官方手册有一章专门进行了介绍。
https://www.mongodb.com/docs/manual/administration/backup-sharded-clusters/
该章节的核心思想就是：
对于4.2+ 的shared clusters, mongodump 和mongorestore 工具不能用来进行备份和恢复，因为mongodump 工具不能维护跨shard 事务的原子性。
对于4.2+ 的shared cluster，推荐使用如下3种方法：
- MongoDB Atlas,
- MongoDB Cloud Manager,
- MongoDB Ops Manager.
很明显，这3种功能都是企业版的MongoDB 才有的，社区版并不具备该功能。
对于4.2之前版本的shared clusters，备份恢复官网也有描述：
https://www.mongodb.com/docs/v3.6/tutorial/backup-sharded-cluster-with-database-dumps/
To create backups of a sharded cluster, you will stop the cluster balancer, take a backup of the config database, and then take backups of each shard in the cluster using mongodump to capture the backup data. To capture a more exact moment-in-time snapshot of the system, you will need to stop all application writes before taking the filesystem snapshots; otherwise the snapshot will only approximate a moment in time.
这里讲的很清楚，先关闭cluster lalancer，然后备份config database，最后使用mongodump 分别备份每个shard。
Shared cluster备份的难点是数据的一致性，即恢复出的数据能对应某个时间点，例如不能部分是1:00的数据，另一部分是1:01的数据。
在传统单机数据库中，我们一般不需要额外关注数据的一致性问题，备份工具会处理、保证备份完成时的一致性（例如通过记录备份期间的日志），然而MongoDB Sharding Cluster存在shard、configserver多个节点，获取备份数据的一致性，会受以下因素影响：
chunks迁移
balancer进程会监控各shard中chunks数量，如果shard间chunks的数量差异超过了阈值，balancer会自动迁移chunks以减少shard之间chunks数量的差异。
如果备份期间发生了chunks迁移，恢复后有可能造成数据的重复保存，即某个chunk存在两个shard上，也可能造成数据的丢失，即config server记录的信息与chunks实际所在shard不一致。对于这个问题，解决方法是禁用balancer，等备份完成后再开启，可以避免chunks迁移带来的影响。数据的写入
Sharded Cluster中各shard和config server是独立运行的，如果在某个时间点同时开始备份，结束的时间无法确保一致，另外如果在Secondary节点停止同步后再做备份，也很难保证停止同步的时间点是完全一致的。
2 开源的分片集群一致性备份工具
2.1 Percona Backup for MongoDB (PBM) 工具介绍
对于Sharded Cluster的备份，在2019年之前，有个开源的工具可以进行备份，该工具使用python 编写：
mongodb-consistent-backup
https://github.com/Percona-Lab/mongodb_consistent_backup
在percona的官网也有专门介绍这个背景：
MongoDB Consistent Backups
https://www.percona.com/blog/2016/07/25/mongodb-consistent-backups/
2019年10月以后，percona 使用golang 重写了该项目，目前该版本还在更新，之前python 版本的已经暂停更新：
该pbm 工具的官网地址：
Percona Backup for MongoDB (PBM)是一种分布式、低影响的解决方案，用于实现MongoDB分片集群和副本集的一致备份。 Percona Backup for MongoDB支持Percona Server for MongoDB和MongoDB Community Edition 3.6+版本。
PBM 工具包含如下组件：
- Pbm-agent： 在集群中的每个mongod节点运行，执行备份和恢复操作。
- pbm CLI：命令行工具，管理pbm-agents上执行的操作。
- PBM Control collections：存储在MongoDB的一个特殊的集合，用来记录配置数据和备份状态。
- Remote backup storage ： s3-compatible 或者文件系统类型的存储。
2.2 Percona Backup for MongoDB (PBM) 工具安装
Percona 官网上关于安装的链接：
https://docs.percona.com/percona-backup-mongodb/installation.html
安装有两种方法，一种是YUM 安装，另一种是源码安装。
我们的测试环境可以上外网，所以我们这里使用YUM 进行安装。
安装percona 的YUM 源：
[dave@www.cndba.cn_1 ~]# yum install https://repo.percona.com/yum/percona-release-latest.noarch.rpm -y
启用pbm 仓库：
[dave@www.cndba.cn_1 ~]# percona-release enable pbm release
* Enabling the Percona Backup MongoDB repository
<*> All done!
[dave@www.cndba.cn_1 ~]#
安装PBM：
[dave@www.cndba.cn_3 ~]# yum install percona-backup-mongodb -y
Loaded plugins: fastestmirror, langpacks
Loading mirror speeds from cached hostfile
pbm-release-x86_64 | 2.9 kB 00:00:00
pbm-release-x86_64/7/primary_db | 7.6 kB 00:00:00
Resolving Dependencies
--> Running transaction check
---> Package percona-backup-mongodb.x86_64 0:1.7.0-1.el7 will be installed
--> Finished Dependency Resolution
Dependencies Resolved
=========================================================================================================================================================
Package Arch Version Repository Size
=========================================================================================================================================================
Installing:
percona-backup-mongodb x86_64 1.7.0-1.el7 pbm-release-x86_64 16 M
Transaction Summary
=========================================================================================================================================================
Install 1 Package
Total download size: 16 M
Installed size: 67 M
Downloading packages:
warning: /var/cache/yum/x86_64/7/pbm-release-x86_64/packages/percona-backup-mongodb-1.7.0-1.el7.x86_64.rpm: Header V4 RSA/SHA256 Signature, key ID 8507efa5: NOKEY
Public key for percona-backup-mongodb-1.7.0-1.el7.x86_64.rpm is not installed
percona-backup-mongodb-1.7.0-1.el7.x86_64.rpm | 16 MB 00:00:58
Retrieving key from file:///etc/pki/rpm-gpg/PERCONA-PACKAGING-KEY
Importing GPG key 0x8507EFA5:
Userid : "Percona MySQL Development Team (Packaging key) <mysql-dev@percona.com>"
Fingerprint: 4d1b b29d 63d9 8e42 2b21 13b1 9334 a25f 8507 efa5
Package : percona-release-1.0-27.noarch (@/percona-release-latest.noarch)
From : /etc/pki/rpm-gpg/PERCONA-PACKAGING-KEY
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
Installing : percona-backup-mongodb-1.7.0-1.el7.x86_64 1/1
Verifying : percona-backup-mongodb-1.7.0-1.el7.x86_64 1/1
Installed:
percona-backup-mongodb.x86_64 0:1.7.0-1.el7
Complete!
[dave@www.cndba.cn_3 ~]#
2.3 注册pbm-agent 的systemctl服务
使用YUM 安装的PBM 会自动配置，所以可以跳过该步骤。
RHEL 和CentOS 环境下配置文件是：/etc/sysconfig/pbm-agent
[dave@www.cndba.cn_3 ~]# ll /etc/sysconfig/pbm-agent
-rw-r----- 1 root root 103 Apr 14 22:42 /etc/sysconfig/pbm-agent
[dave@www.cndba.cn_3 ~]#
创建systemd unit file：
[dave@www.cndba.cn_3 ~]# cat /usr/lib/systemd/system/pbm-agent.service
[Unit]
Description=pbm-agent
After=time-sync.target network.target
[Service]
EnvironmentFile=-/etc/sysconfig/pbm-agent
Type=simple
User=mongod
Group=mongod
PermissionsStartOnly=true
ExecStart=/usr/bin/pbm-agent
[Install]
WantedBy=multi-user.target
[dave@www.cndba.cn_3 ~]#
[dave@www.cndba.cn_3 ~]# systemctl daemon-reload
[dave@www.cndba.cn_3 ~]# systemctl status pbm-agent
● pbm-agent.service - pbm-agent
Loaded: loaded (/usr/lib/systemd/system/pbm-agent.service; enabled; vendor preset: disabled)
Active: inactive (dead)
[dave@www.cndba.cn_3 ~]#
2.4 初始化安装
官网的描述如下：
https://docs.percona.com/percona-backup-mongodb/initial-setup.html
实际上官网的描述有很多，在该步骤，我们只需要做3件事：
- Configure authentication in MongoDB
- Insert the config information for remote backup storage
- Start pbm-agent process
2.4.1 创建PBM 角色和用户
在所有shard 和 config server 副本集中创建PBM 角色和用户。
在shared cluster 中，直接连上mongos，并执行如下命令获取集群中的所有shard 信息：
[dave@www.cndba.cn_1 ~]# mongo --port 27000
MongoDB shell version v4.4.13
mongos> use admin
switched to db admin
mongos> db.auth('root','root')
1
mongos> show dbs
admin 0.000GB
cndba 0.007GB
config 0.003GB
mongos> db.getSiblingDB(“config”).shards.find({}, {“host”: true, “_id”: false})
uncaught exception: SyntaxError: illegal character :
@(shell):1:16
mongos> db.getSiblingDB("config").shards.find({}, {"host":true, "_id": false})
{ "host" : "shard1/172.31.185.120:27018,172.31.185.131:27018,172.31.185.165:27018" }
{ "host" : "shard2/172.31.185.120:27019,172.31.185.131:27019,172.31.185.165:27019" }
{ "host" : "shard3/172.31.185.120:27020,172.31.185.131:27020,172.31.185.165:27020" }
mongos>
因为我们这里的环境是3 shared，所以我们需要在4个shared 副本集中创建用户和角色。
我们这里只演示在一个shard 副本集上的操作，其他shard 上操作类似。
db.getSiblingDB("admin").createRole({ "role": "pbmAnyAction",
"privileges": [
{ "resource": { "anyResource": true },
"actions": [ "anyAction" ]
}
],
"roles": []
});
db.getSiblingDB("admin").createUser({user: "pbmbackup",
"pwd": "pbmbackup",
"roles" : [
{ "db" : "admin", "role" : "readWrite", "collection": "" },
{ "db" : "admin", "role" : "backup" },
{ "db" : "admin", "role" : "clusterMonitor" },
{ "db" : "admin", "role" : "restore" },
{ "db" : "admin", "role" : "pbmAnyAction" }
]
});
[dave@www.cndba.cn_3 ~]# mongo --port 27018
MongoDB shell version v4.4.13
shard1:PRIMARY> use admin
switched to db admin
shard1:PRIMARY> db.auth('root','root')
1
shard1:PRIMARY> db.getSiblingDB("admin").createRole({ "role": "pbmAnyAction",
... "privileges": [
... { "resource": { "anyResource": true },
... "actions": [ "anyAction" ]
... }
... ],
... "roles": []
... });
{
"role" : "pbmAnyAction",
"privileges" : [
{
"resource" : {
"anyResource" : true
},
"actions" : [
"anyAction"
]
}
],
"roles" : [ ]
}
shard1:PRIMARY> db.getSiblingDB("admin").createUser({user: "pbmbackup",
... "pwd": "pbmbackup",
... "roles" : [
... { "db" : "admin", "role" : "readWrite", "collection": "" },
... { "db" : "admin", "role" : "backup" },
... { "db" : "admin", "role" : "clusterMonitor" },
... { "db" : "admin", "role" : "restore" },
... { "db" : "admin", "role" : "pbmAnyAction" }
... ]
... });
Successfully added user: {
"user" : "pbmbackup",
"roles" : [
{
"db" : "admin",
"role" : "readWrite",
"collection" : ""
},
{
"db" : "admin",
"role" : "backup"
},
{
"db" : "admin",
"role" : "clusterMonitor"
},
{
"db" : "admin",
"role" : "restore"
},
{
"db" : "admin",
"role" : "pbmAnyAction"
}
]
}
shard1:PRIMARY>
2.4.2 配置备份存储
创建配置文件：
[dave@www.cndba.cn_1 etc]# pwd
/data/mongodb/etc
[dave@www.cndba.cn_1 etc]# cat pbm_config.yaml
storage:
type: filesystem
filesystem:
path: /data/mongodb/backup
[dave@www.cndba.cn_1 etc]#
在shared cluster 环境，连接到config server，并执行导入：
[dave@www.cndba.cn_1 etc]# pbm config --mongodb-uri="mongodb://pbmbackup:pbmbackup@127.0.0.1:27001/?authSource=admin&replicaSet=configdb" --file /data/mongodb/etc/pbm_config.yaml
pitr:
enabled: false
oplogSpanMin: 0
compression: s2
storage:
type: filesystem
filesystem:
path: /data/mongodb/backup
[dave@www.cndba.cn_1 etc]#
2.4.3 配置PBM_MONGODB_URI环境变量
在我们单台机器多个shard的情况下，这一步配置意义不是很大。
配置PBM_MONGODB_URI环境变量，配置的2个地方：/etc/sysconfig/pbm-agent 和 环境变量。
export PBM_MONGODB_URI="mongodb://pbmbackup:pbmbackup@localhost:27018/?authSource=admin&replicaSet=shard1"
[dave@www.cndba.cn_1 logs]# source ~/.bash_profile
[dave@www.cndba.cn_1 logs]# echo $PBM_MONGODB_URI
mongodb://pbmbackup:pbmbackup@localhost:27018/?authSource=admin&replicaSet=shard1
[dave@www.cndba.cn_1 logs]#
[dave@www.cndba.cn_1 logs]# cat /etc/sysconfig/pbm-agent
PBM_MONGODB_URI="mongodb://pbmbackup:pbmbackup@localhost:27018/?authSource=admin&replicaSet=shard1"
[dave@www.cndba.cn_1 logs]#
但为了演示方便，我们这里统一配置成shard1. 在实际始终中，还是需要指定—mongodb-uri来进行对应的连接。
2.4.4 启动pbm-agent 进程
如果安装官网手册，在启动pbm-agent之前还需要配置PBM_MONGODB_URI环境变量，配置的2个地方：/etc/sysconfig/pbm-agent 和 环境变量。
但因为我们的环境每个节点都有多个shard，所以这里会有冲突，所以简单点，我们直接启动多个pbm-agent 进程，在启动时指定环境变量。
我们现在每个节点都有4个shard。 在所有节点执行如下命令：
pbm-agent --mongodb-uri "mongodb://pbmbackup:pbmbackup@localhost:27018/?replSetName=shard1" >> /data/mongodb/logs/pbm_agent_shard1.log 2>&1 &
pbm-agent --mongodb-uri "mongodb://pbmbackup:pbmbackup@localhost:27019/?replSetName=shard2" >> /data/mongodb/logs/pbm_agent_shard2.log 2>&1 &
pbm-agent --mongodb-uri "mongodb://pbmbackup:pbmbackup@localhost:27020/?replSetName=shard3" >> /data/mongodb/logs/pbm_agent_shard3.log 2>&1 &
pbm-agent --mongodb-uri "mongodb://pbmbackup:pbmbackup@localhost:27001/?replSetName=configdb" >> /data/mongodb/logs/pbm_agent_configdb.log 2>&1 &
[dave@www.cndba.cn_1 logs]# pbm-agent --mongodb-uri "mongodb://pbmbackup:pbmbackup@localhost:27018/?replSetName=shard1" >> /data/mongodb/logs/pbm_agent_shard1.log 2>&1 &
[1] 23195
[dave@www.cndba.cn_1 logs]# pbm-agent --mongodb-uri "mongodb://pbmbackup:pbmbackup@localhost:27019/?replSetName=shard2" >> /data/mongodb/logs/pbm_agent_shard2.log 2>&1 &
[2] 23232
[dave@www.cndba.cn_1 logs]# pbm-agent --mongodb-uri "mongodb://pbmbackup:pbmbackup@localhost:27020/?replSetName=shard3" >> /data/mongodb/logs/pbm_agent_shard3.log 2>&1 &
[3] 23267
[dave@www.cndba.cn_1 logs]# pbm-agent --mongodb-uri "mongodb://pbmbackup:pbmbackup@localhost:27001/?replSetName=configdb" >> /data/mongodb/logs/pbm_agent_configdb.log 2>&1 &
[4] 23305
[dave@www.cndba.cn_1 logs]# ps -ef|grep pbm-agent
root 23195 10395 0 23:47 pts/0 00:00:00 pbm-agent --mongodb-uri mongodb://pbmbackup:pbmbackup@localhost:27018/?replSetName=shard1
root 23232 10395 0 23:47 pts/0 00:00:00 pbm-agent --mongodb-uri mongodb://pbmbackup:pbmbackup@localhost:27019/?replSetName=shard2
root 23267 10395 0 23:47 pts/0 00:00:00 pbm-agent --mongodb-uri mongodb://pbmbackup:pbmbackup@localhost:27020/?replSetName=shard3
root 23305 10395 0 23:47 pts/0 00:00:00 pbm-agent --mongodb-uri mongodb://pbmbackup:pbmbackup@localhost:27001/?replSetName=configdb
root 23339 10395 0 23:47 pts/0 00:00:00 grep --color=auto pbm-agent
[dave@www.cndba.cn_1 logs]#
查看pbm 状态：
[dave@www.cndba.cn_2 backup]# pbm status
Cluster:
========
configdb:
- configdb/172.31.185.120:27001: pbm-agent v1.7.0 OK
- configdb/172.31.185.165:27001: pbm-agent v1.7.0 OK
- configdb/172.31.185.131:27001: pbm-agent v1.7.0 OK
shard1:
- shard1/172.31.185.120:27018: pbm-agent v1.7.0 OK
- shard1/172.31.185.165:27018: pbm-agent v1.7.0 OK
- shard1/172.31.185.131:27018: pbm-agent v1.7.0 OK
shard2:
- shard2/172.31.185.120:27019: pbm-agent v1.7.0 OK
- shard2/172.31.185.165:27019: pbm-agent v1.7.0 OK
- shard2/172.31.185.131:27019: pbm-agent v1.7.0 OK
shard3:
- shard3/172.31.185.120:27020: pbm-agent v1.7.0 OK
- shard3/172.31.185.165:27020: pbm-agent v1.7.0 OK
- shard3/172.31.185.131:27020: pbm-agent v1.7.0 OK
PITR incremental backup:
========================
Status [OFF]
Currently running:
==================
(none)
Backups:
========
FS /data/mongodb/backup
Snapshots:
2022-05-05T00:14:34Z 429.15KB <logical> [complete: 2022-05-05T00:14:40]
2022-05-04T16:10:02Z 0.00B [ERROR: get file 2022-05-04T16:10:02Z_shard1.dump.gz: no such file] [2022-05-04T16:10:07]
2022-05-04T15:56:25Z 677.93KB [ERROR: get file 2022-05-04T15:56:25Z_shard3.dump.s2: no such file] [2022-05-04T15:56:29]
[dave@www.cndba.cn_2 backup]#
2.5 执行全量备份
https://docs.percona.com/percona-backup-mongodb/running.html
如果单台机器上有多个shard，那么所有调用pbm的地方，我们都需要手工指定mongodb-uri。
副本集的备份指定集群连接串，可以在从节点进行备份，备份任务会根据集群内的节点繁忙程度选择最适合转储的节点，就是说可能命令在节点1执行的，但是备份文件生成在节点2。
pbm只支持全量备份恢复，在备份过程中会记录备份时段内的oplog，会生成2个备份文件：
-rw------- 1 root root 85396 May 5 08:14 2022-05-05T00:14:34Z_shard2.dump.gz
-rw------- 1 root root 1268 May 5 08:14 2022-05-05T00:14:34Z_shard2.oplog.gz
Pbm 的备份分逻辑备份和物理备份，通过—type 参数控制，默认为逻辑备份：
pbm backup --type=TYPE
In logical backups, the completion time almost coincides with the backup finish time. To define the completion time, Percona Backup for MongoDB waits for the backup snapshot to finish on all cluster nodes. Then it captures the oplog from the backup start time up to that time.
In physical backups, the completion time is only a few seconds after the backup start time. By holding the $backupCursor open guarantees that the checkpoint data won’t change during the backup, and Percona Backup for MongoDB can define the completion time ahead.
备份shard1：
[dave@www.cndba.cn_3 ~]# pbm backup --mongodb-uri "mongodb://pbmbackup:pbmbackup@172.31.185.120:27018,172.31.185.165:27018,172.31.185.131:27018/?replicaSet=shard1"
Starting backup '2022-05-04T15:56:25Z'....
Backup '2022-05-04T15:56:25Z' to remote store '/data/mongodb/backup' has started
[dave@www.cndba.cn_3 ~]#
查看备份集：
[dave@www.cndba.cn_3 ~]# pbm list --mongodb-uri "mongodb://pbmbackup:pbmbackup@172.31.185.120:27018,172.31.185.165:27018,172.31.185.131:27018/?replicaSet=shard1"
Backup snapshots:
2022-05-04T15:56:25Z <logical> [complete: 2022-05-04T15:56:29]
PITR <off>:
[dave@www.cndba.cn_3 ~]#
因为我们之前配置了shard1的环境变量，也可以直接查看，不指定—mongodb-uri：
[dave@www.cndba.cn_3 ~]# pbm list
Backup snapshots:
2022-05-04T15:56:25Z <logical> [complete: 2022-05-04T15:56:29]
2022-05-04T16:10:02Z <logical> [complete: 2022-05-04T16:10:07]
PITR <off>:
[dave@www.cndba.cn_3 ~]#
查看备份：
[dave@www.cndba.cn_3 mongodb]# pbm list
Backup snapshots:
2022-05-04T15:56:25Z <logical> [complete: 2022-05-04T15:56:29]
2022-05-04T16:10:02Z <logical> [complete: 2022-05-04T16:10:07]
PITR <off>:
[dave@www.cndba.cn_3 mongodb]#
对shard1 进行压缩备份：
[dave@www.cndba.cn_1 backup]# pbm backup --compression=gzip
Starting backup '2022-05-05T00:14:34Z'....
Backup '2022-05-05T00:14:34Z' to remote store '/data/mongodb/backup' has started
[dave@www.cndba.cn_1 backup]# pbm list
Backup snapshots:
2022-05-04T15:56:25Z <logical> [complete: 2022-05-04T15:56:29]
2022-05-04T16:10:02Z <logical> [complete: 2022-05-04T16:10:07]
2022-05-05T00:14:34Z <logical> [complete: 2022-05-05T00:14:40]
PITR <off>:
[dave@www.cndba.cn_1 backup]#
备份文件就生成在节点3 和节点2上：
[dave@www.cndba.cn_3 backup]# ll
total 272
-rw------- 1 root root 168919 May 5 08:14 2022-05-05T00:14:34Z_configdb.dump.gz
-rw------- 1 root root 8641 May 5 08:14 2022-05-05T00:14:34Z_configdb.oplog.gz
-rw------- 1 root root 3760 May 5 08:14 2022-05-05T00:14:34Z.pbm.json
-rw------- 1 root root 85432 May 5 08:14 2022-05-05T00:14:34Z_shard3.dump.gz
-rw------- 1 root root 1276 May 5 08:14 2022-05-05T00:14:34Z_shard3.oplog.gz
[dave@www.cndba.cn_3 backup]# pbm list
Backup snapshots:
2022-05-04T15:56:25Z <logical> [complete: 2022-05-04T15:56:29]
2022-05-04T16:10:02Z <logical> [complete: 2022-05-04T16:10:07]
2022-05-05T00:14:34Z <logical> [complete: 2022-05-05T00:14:40]
PITR <off>:
[dave@www.cndba.cn_3 backup]#
[dave@www.cndba.cn_2 backup]# ll
total 5320
-rw------- 1 root root 263178 May 4 23:56 2022-05-04T15:56:25Z_configdb.dump.s2
-rw------- 1 root root 11654 May 4 23:56 2022-05-04T15:56:25Z_configdb.oplog.s2
-rw------- 1 root root 3701 May 4 23:56 2022-05-04T15:56:25Z.pbm.json
-rw------- 1 root root 210097 May 4 23:56 2022-05-04T15:56:25Z_shard1.dump.s2
-rw------- 1 root root 1409 May 4 23:56 2022-05-04T15:56:25Z_shard1.oplog.s2
-rw------- 1 root root 206463 May 4 23:56 2022-05-04T15:56:25Z_shard2.dump.s2
-rw------- 1 root root 1395 May 4 23:56 2022-05-04T15:56:25Z_shard2.oplog.s2
-rw------- 1 root root 154636 May 5 00:10 2022-05-04T16:10:02Z_configdb.dump.gz
-rw------- 1 root root 8481 May 5 00:10 2022-05-04T16:10:02Z_configdb.oplog.gz
-rw------- 1 root root 3703 May 5 00:10 2022-05-04T16:10:02Z.pbm.json
-rw------- 1 root root 85406 May 5 00:10 2022-05-04T16:10:02Z_shard2.dump.gz
-rw------- 1 root root 1240 May 5 00:10 2022-05-04T16:10:02Z_shard2.oplog.gz
-rw------- 1 root root 87244 May 5 08:14 2022-05-05T00:14:34Z_shard1.dump.gz
-rw------- 1 root root 1271 May 5 08:14 2022-05-05T00:14:34Z_shard1.oplog.gz
-rw------- 1 root root 85396 May 5 08:14 2022-05-05T00:14:34Z_shard2.dump.gz
-rw------- 1 root root 1268 May 5 08:14 2022-05-05T00:14:34Z_shard2.oplog.gz
drwxr-xr-x 2 root root 128 May 4 11:14 admin
drwxr-xr-x 2 root root 109 May 4 11:28 cndba
-rw-r--r-- 1 root root 103 May 4 11:14 oplog.bson
-rw-r--r-- 1 root root 1188904 May 4 11:08 user.csv
-rw-r--r-- 1 root root 3088895 May 4 10:58 user.json
[dave@www.cndba.cn_2 backup]# pbm list
Backup snapshots:
2022-05-04T15:56:25Z <logical> [complete: 2022-05-04T15:56:29]
2022-05-04T16:10:02Z <logical> [complete: 2022-05-04T16:10:07]
2022-05-05T00:14:34Z <logical> [complete: 2022-05-05T00:14:40]
PITR <off>:
[dave@www.cndba.cn_2 backup]#
在上面的测试中，我们发现虽然我们只备份了shard1，但是实际上是4个shard 都进行了备份:shard1、shard2、shard3、configdb。 分别存储在节点2和节点3的远程备份目录中。
PBM 的官网有相关描述，如下：
In sharded clusters, one of pbm-agent processes for every shard and the config server replica set writes backup snapshots into the remote backup storage directly. For logical backups, pbm-agents also write oplog slices.
根据官网的描述，可以看出，对于Shard cluster，BPM 是依据pbm-agent 来进行备份的。 只要副本集上启动了pbm-agent 都会进行备份。 所以使用PBM 进行备份，只需要在任意节点对任意shard 进行备份即可， 主要是pbm-agent的启动。
2.6 备份全量恢复
如果是同环境的恢复，PBM 有如下注意事项：
- Stop the balancer.
- Shut down all mongos nodes to stop clients from accessing the database while restore is in progress. This ensures that the final restored data doesn’t differ from the backed-up data.
- Disable point-in-time recovery if it is enabled. To learn more about point-in-time recovery。
PBM 的恢复，也是同时对所有shard 进行恢复的。 在任意节点执行即可，Pbm-agent 进程会自动将数据写入到cluster中的primary 节点。
2.6.1 恢复前期要求准备
连上mongos：
[dave@www.cndba.cn_3 backup]# mongo -port 27000
MongoDB shell version v4.4.13
connecting to: mongodb://127.0.0.1:27000/?compressors=disabled&gssapiServiceName=mongodb
Implicit session: session { "id" : UUID("21a7378b-2e69-4f30-90e4-dae14548e615") }
MongoDB server version: 4.4.13
mongos> use admin
switched to db admin
mongos> db.auth('root','root')
1
mongos> sh.getBalancerState()
true
mongos> sh.isBalancerRunning()
false
mongos> sh.stopBalancer()
{
"ok" : 1,
"operationTime" : Timestamp(1651711372, 3),
"$clusterTime" : {
"clusterTime" : Timestamp(1651711372, 3),
"signature" : {
"hash" : BinData(0,"O6nkZPRHI9ZEEFAQDDRg5iHFYYs="),
"keyId" : NumberLong("7093529851058978835")
}
}
}
mongos>
注：启用：sh.setBalancerState(true)
[dave@www.cndba.cn_3 backup]# pbm config --set pitr.enabled=false
[pitr.enabled=false]
[dave@www.cndba.cn_3 backup]#
[dave@www.cndba.cn_1 backup]# supervisorctl stop mongos
mongos: stopped
[dave@www.cndba.cn_1 backup]#
[dave@www.cndba.cn_2 backup]# supervisorctl stop mongos
mongos: stopped
[dave@www.cndba.cn_2 backup]#
[dave@www.cndba.cn_3 backup]# supervisorctl stop mongos
mongos: stopped
[dave@www.cndba.cn_3 backup]#
2.6.2 恢复数据库
因为pbm-agent 是自动在在primary 节点上进行恢复，而primary 又是分散的。 所以在每台节点上都需要保存4个shard 的备份文件，否则执行备份时会提示备份不存在。
在恢复之前，需要先将分散的shard备份文件整合到一台机器：
[dave@www.cndba.cn_2 backup]# scp ./2022-05-05T00/:14/:34Z_* mongodb1:`pwd`
[dave@www.cndba.cn_2 backup]# ll
total 5588
-rw------- 1 root root 263178 May 4 23:56 2022-05-04T15:56:25Z_configdb.dump.s2
-rw------- 1 root root 11654 May 4 23:56 2022-05-04T15:56:25Z_configdb.oplog.s2
-rw------- 1 root root 3701 May 4 23:56 2022-05-04T15:56:25Z.pbm.json
-rw------- 1 root root 210097 May 4 23:56 2022-05-04T15:56:25Z_shard1.dump.s2
-rw------- 1 root root 1409 May 4 23:56 2022-05-04T15:56:25Z_shard1.oplog.s2
-rw------- 1 root root 206463 May 4 23:56 2022-05-04T15:56:25Z_shard2.dump.s2
-rw------- 1 root root 1395 May 4 23:56 2022-05-04T15:56:25Z_shard2.oplog.s2
-rw------- 1 root root 154636 May 5 00:10 2022-05-04T16:10:02Z_configdb.dump.gz
-rw------- 1 root root 8481 May 5 00:10 2022-05-04T16:10:02Z_configdb.oplog.gz
-rw------- 1 root root 3703 May 5 00:10 2022-05-04T16:10:02Z.pbm.json
-rw------- 1 root root 85406 May 5 00:10 2022-05-04T16:10:02Z_shard2.dump.gz
-rw------- 1 root root 1240 May 5 00:10 2022-05-04T16:10:02Z_shard2.oplog.gz
-rw------- 1 root root 168919 May 5 08:50 2022-05-05T00:14:34Z_configdb.dump.gz
-rw------- 1 root root 8641 May 5 08:50 2022-05-05T00:14:34Z_configdb.oplog.gz
-rw------- 1 root root 87244 May 5 08:14 2022-05-05T00:14:34Z_shard1.dump.gz
-rw------- 1 root root 1271 May 5 08:14 2022-05-05T00:14:34Z_shard1.oplog.gz
-rw------- 1 root root 85396 May 5 08:14 2022-05-05T00:14:34Z_shard2.dump.gz
-rw------- 1 root root 1268 May 5 08:14 2022-05-05T00:14:34Z_shard2.oplog.gz
-rw------- 1 root root 85432 May 5 08:50 2022-05-05T00:14:34Z_shard3.dump.gz
-rw------- 1 root root 1276 May 5 08:50 2022-05-05T00:14:34Z_shard3.oplog.gz
drwxr-xr-x 2 root root 128 May 4 11:14 admin
drwxr-xr-x 2 root root 109 May 4 11:28 cndba
-rw-r--r-- 1 root root 103 May 4 11:14 oplog.bson
-rw-r--r-- 1 root root 1188904 May 4 11:08 user.csv
-rw-r--r-- 1 root root 3088895 May 4 10:58 user.json
[dave@www.cndba.cn_2 backup]#
[dave@www.cndba.cn_2 backup]# pbm restore 2022-05-05T00:14:34Z
Starting restore from '2022-05-05T00:14:34Z'...Restore of the snapshot from '2022-05-05T00:14:34Z' has started
[dave@www.cndba.cn_2 backup]# pbm list
Backup snapshots:
2022-05-04T15:56:25Z <logical> [complete: 2022-05-04T15:56:29]
2022-05-04T16:10:02Z <logical> [complete: 2022-05-04T16:10:07]
2022-05-05T00:14:34Z <logical> [complete: 2022-05-05T00:14:40]
PITR <off>:
[dave@www.cndba.cn_2 backup]#
查看恢复状态：
[dave@www.cndba.cn_2 backup]# pbm status
Cluster:
========
configdb:
- configdb/172.31.185.120:27001: pbm-agent v1.7.0 OK
- configdb/172.31.185.165:27001: pbm-agent v1.7.0 OK
- configdb/172.31.185.131:27001: pbm-agent v1.7.0 OK
shard1:
- shard1/172.31.185.120:27018: pbm-agent v1.7.0 OK
- shard1/172.31.185.165:27018: pbm-agent v1.7.0 OK
- shard1/172.31.185.131:27018: pbm-agent v1.7.0 OK
shard2:
- shard2/172.31.185.120:27019: pbm-agent v1.7.0 OK
- shard2/172.31.185.165:27019: pbm-agent v1.7.0 OK
- shard2/172.31.185.131:27019: pbm-agent v1.7.0 OK
shard3:
- shard3/172.31.185.120:27020: pbm-agent v1.7.0 OK
- shard3/172.31.185.165:27020: pbm-agent v1.7.0 OK
- shard3/172.31.185.131:27020: pbm-agent v1.7.0 OK
PITR incremental backup:
========================
Status [OFF]
Currently running:
==================
(none)
Backups:
========
FS /data/mongodb/backup
Snapshots:
2022-05-05T00:14:34Z 429.15KB <logical> [complete: 2022-05-05T00:14:40]
2022-05-04T16:10:02Z 0.00B [ERROR: get file 2022-05-04T16:10:02Z_shard1.dump.gz: no such file] [2022-05-04T16:10:07]
2022-05-04T15:56:25Z 677.93KB [ERROR: get file 2022-05-04T15:56:25Z_shard3.dump.s2: no such file] [2022-05-04T15:56:29]
[dave@www.cndba.cn_2 backup]#
这里看到恢复已经完成。
查看pbm 日志：
[dave@www.cndba.cn_2 backup]# pbm logs
2022-05-05T01:22:56Z I [shard2/172.31.185.131:27019] [restore/2022-05-05T00:14:34Z] restoring users and roles
2022-05-05T01:22:56Z I [shard2/172.31.185.131:27019] [restore/2022-05-05T00:14:34Z] moving to state dumpDone
2022-05-05T01:22:57Z I [shard1/172.31.185.131:27018] [restore/2022-05-05T00:14:34Z] restoring users and roles
2022-05-05T01:22:57Z I [shard1/172.31.185.131:27018] [restore/2022-05-05T00:14:34Z] moving to state dumpDone
2022-05-05T01:22:57Z I [shard3/172.31.185.165:27020] [restore/2022-05-05T00:14:34Z] restoring users and roles
2022-05-05T01:22:57Z I [shard3/172.31.185.165:27020] [restore/2022-05-05T00:14:34Z] moving to state dumpDone
2022-05-05T01:22:58Z I [configdb/172.31.185.120:27001] [restore/2022-05-05T00:14:34Z] restoring users and roles
2022-05-05T01:22:58Z I [configdb/172.31.185.120:27001] [restore/2022-05-05T00:14:34Z] moving to state dumpDone
2022-05-05T01:22:59Z I [shard2/172.31.185.131:27019] [restore/2022-05-05T00:14:34Z] starting oplog replay
2022-05-05T01:23:00Z I [shard2/172.31.185.131:27019] [restore/2022-05-05T00:14:34Z] oplog replay finished on {1651709678 5}
2022-05-05T01:23:00Z I [shard2/172.31.185.131:27019] [restore/2022-05-05T00:14:34Z] restore finished successfully
2022-05-05T01:23:00Z I [shard1/172.31.185.131:27018] [restore/2022-05-05T00:14:34Z] starting oplog replay
2022-05-05T01:23:00Z I [shard3/172.31.185.165:27020] [restore/2022-05-05T00:14:34Z] starting oplog replay
2022-05-05T01:23:00Z I [shard1/172.31.185.131:27018] [restore/2022-05-05T00:14:34Z] oplog replay finished on {1651709678 8}
2022-05-05T01:23:00Z I [shard1/172.31.185.131:27018] [restore/2022-05-05T00:14:34Z] restore finished successfully
2022-05-05T01:23:00Z I [shard3/172.31.185.165:27020] [restore/2022-05-05T00:14:34Z] oplog replay finished on {1651709678 8}
2022-05-05T01:23:00Z I [shard3/172.31.185.165:27020] [restore/2022-05-05T00:14:34Z] restore finished successfully
2022-05-05T01:23:00Z I [configdb/172.31.185.120:27001] [restore/2022-05-05T00:14:34Z] starting oplog replay
2022-05-05T01:23:00Z I [configdb/172.31.185.120:27001] [restore/2022-05-05T00:14:34Z] oplog replay finished on {1651709680 22}
2022-05-05T01:23:01Z I [configdb/172.31.185.120:27001] [restore/2022-05-05T00:14:34Z] restore finished successfully
[dave@www.cndba.cn_2 backup]#
2.6.3 启动mongos 和 balancer
[dave@www.cndba.cn_1 ~]# supervisorctl start mongos
mongos: started
[dave@www.cndba.cn_1 ~]#
[dave@www.cndba.cn_1 ~]# mongo -port 27000
MongoDB shell version v4.4.13
connecting to: mongodb://127.0.0.1:27000/?compressors=disabled&gssapiServiceName=mongodb
Implicit session: session { "id" : UUID("8af45fe0-9cf0-461f-9f25-c69ac27862e2") }
MongoDB server version: 4.4.13
mongos> use admin
switched to db admin
mongos> db.auth('root','root')
1
mongos> sh.setBalancerState(true)
{
"ok" : 1,
"operationTime" : Timestamp(1651714319, 6),
"$clusterTime" : {
"clusterTime" : Timestamp(1651714319, 6),
"signature" : {
"hash" : BinData(0,"Sezv0kB5YZfaYn/WALJIx4Y/gJI="),
"keyId" : NumberLong("7093529851058978835")
}
}
}
mongos> sh.getBalancerState()
true
mongos>
2.7 全量备份恢复小结
经过以上的测试，有以下几点注意事项。
- PBM_MONGODB_URI环境变量配置任意节点都可以，因为PBM 是根据pbm-agent 来自动进行备份恢复。
- Pbm对任意节点发起的备份恢复命令都会对启动pbm-agent的所有节点执行。
- Pbm 远程存储目录建议使用共享存储，挂在所有节点的相同位置。 如果使用本地文件系统，那么在恢复的时候需要保障每个节点有完整的备份文件。 否则会提示找不到备份文件。
2.8 基于时间点的恢复(Point-in-Time Recovery)
2.8.1 理论说明
https://docs.percona.com/percona-backup-mongodb/point-in-time-recovery.html
Point-in-Time Recovery 可以将数据库恢复到指定的时间点。Point-in-Time Recovery 目前仅支持逻辑备份。
PITR 包含2个步骤：
- 从全量备份恢复数据库，pbm会自动选择最近的备份来恢复。
- 从oplog slices应用备份之后到指定点之间的所有events。
启用Point-in-Time Recovery：
$ pbm config —set pitr.enabled=true
启用时间点恢复功能后，pbm-agent会定期连续保存oplog的分片（slices），默认情况下，一个oplog slices 包含10分钟的oplog事件。 但在开始保存oplog之前，需要有一个pbm的全量备份。 所以oplog 的保存可以理解是一种增量备份。
可以使用如下命令修改pbm-agent生成oplog slices 的周期，单位分钟：
[dave@www.cndba.cn_3 ~]# pbm config --set pitr.oplogSpanMin=5
[pitr.oplogSpanMin=5]
启用置换可以使用pbm list 命令查看，因为刚启动，所以PITR 为空，可以等oplog slices的生成周期后在查看：
[dave@www.cndba.cn_3 ~]# pbm list
Backup snapshots:
2022-05-04T15:56:25Z <logical> [complete: 2022-05-04T15:56:29]
2022-05-04T16:10:02Z <logical> [complete: 2022-05-04T16:10:07]
2022-05-05T00:14:34Z <logical> [complete: 2022-05-05T00:14:40]
PITR <off>:
[dave@www.cndba.cn_3 ~]#
2.8.2 全量备份
因为我们之前的备份已经恢复过了，无法在继续使用，所以我们这里重新做一次备份。
[dave@www.cndba.cn_2 backup]# pbm backup
Starting backup '2022-05-05T02:20:25Z'....
Backup '2022-05-05T02:20:25Z' to remote store '/data/mongodb/backup' has started
[dave@www.cndba.cn_2 backup]# pbm status
Cluster:
========
configdb:
- configdb/172.31.185.120:27001: pbm-agent v1.7.0 OK
- configdb/172.31.185.165:27001: pbm-agent v1.7.0 OK
- configdb/172.31.185.131:27001: pbm-agent v1.7.0 OK
shard1:
- shard1/172.31.185.120:27018: pbm-agent v1.7.0 OK
- shard1/172.31.185.165:27018: pbm-agent v1.7.0 OK
- shard1/172.31.185.131:27018: pbm-agent v1.7.0 OK
shard2:
- shard2/172.31.185.120:27019: pbm-agent v1.7.0 OK
- shard2/172.31.185.165:27019: pbm-agent v1.7.0 OK
- shard2/172.31.185.131:27019: pbm-agent v1.7.0 OK
shard3:
- shard3/172.31.185.120:27020: pbm-agent v1.7.0 OK
- shard3/172.31.185.165:27020: pbm-agent v1.7.0 OK
- shard3/172.31.185.131:27020: pbm-agent v1.7.0 OK
PITR incremental backup:
========================
Status [OFF]
Currently running:
==================
Snapshot backup "2022-05-05T02:20:25Z", started at 2022-05-05T02:20:26Z. Status: oplog backup. [op id: 62733469a10bdde8a26cd5a6]
Backups:
========
FS /data/mongodb/backup
Snapshots:
2022-05-05T02:20:25Z 0.00B [running: dumpDone / 2022-05-05T02:20:33]
2022-05-05T00:14:34Z 0.00B [ERROR: get file 2022-05-05T00:14:34Z_shard3.dump.gz: no such file] [2022-05-05T00:14:40]
2022-05-04T16:10:02Z 0.00B [ERROR: get file 2022-05-04T16:10:02Z_shard1.dump.gz: no such file] [2022-05-04T16:10:07]
2022-05-04T15:56:25Z 0.00B [ERROR: get file 2022-05-04T15:56:25Z_shard1.dump.s2: no such file] [2022-05-04T15:56:29]
[dave@www.cndba.cn_2 backup]#
2.8.3 启用PITR
[dave@www.cndba.cn_1 backup]# pbm config
pitr:
enabled: false
oplogSpanMin: 5
compression: s2
storage:
type: filesystem
filesystem:
path: /data/mongodb/backup
[dave@www.cndba.cn_1 backup]# pbm config --set pitr.enabled=true
[pitr.enabled=true]
[dave@www.cndba.cn_1 backup]# pbm config
pitr:
enabled: true
oplogSpanMin: 5
compression: s2
storage:
type: filesystem
filesystem:
path: /data/mongodb/backup
[dave@www.cndba.cn_1 backup]#
为了方便测试，我们这里修改PITR 周期：
[dave@www.cndba.cn_1 backup]# pbm config --set pitr.oplogSpanMin=2
[pitr.oplogSpanMin=2]
[dave@www.cndba.cn_1 backup]# pbm config
pitr:
enabled: true
oplogSpanMin: 2
compression: s2
storage:
type: filesystem
filesystem:
path: /data/mongodb/backup
[dave@www.cndba.cn_1 backup]#
2.8.4 执行PITR 恢复
查看oplog slice信息：
[dave@www.cndba.cn_1 backup]# pbm list
Backup snapshots:
2022-05-04T15:56:25Z <logical> [complete: 2022-05-04T15:56:29]
2022-05-04T16:10:02Z <logical> [complete: 2022-05-04T16:10:07]
2022-05-05T00:14:34Z <logical> [complete: 2022-05-05T00:14:40]
2022-05-05T02:20:25Z <logical> [complete: 2022-05-05T02:20:32]
PITR <on>:
2022-05-05T02:20:33 - 2022-05-05T02:32:59
[dave@www.cndba.cn_1 backup]#
这里我们可以恢复到2022-05-05T02:20:33 到 2022-05-05T02:32:59 之间的任意时间。
全量恢复和PITR 增量备份时不兼容的，不能同时运行，所以在执行恢复之前，必须先禁用PITR恢复：
[dave@www.cndba.cn_1 backup]# pbm config --set pitr.enabled=false
[pitr.enabled=false]
[dave@www.cndba.cn_1 backup]# pbm config
pitr:
enabled: false
oplogSpanMin: 2
compression: s2
storage:
type: filesystem
filesystem:
path: /data/mongodb/backup
[dave@www.cndba.cn_1 backup]#
复制PITR 的oplog slices：
oplog slices备份也会存储到备份目录的pbmPitr目录中。
[dave@www.cndba.cn_3 pbmPitr]# pwd
/data/mongodb/backup/pbmPitr
[dave@www.cndba.cn_3 pbmPitr]# ll
total 0
drwx------ 3 root root 22 May 5 10:25 configdb
drwx------ 3 root root 22 May 5 10:25 shard1
drwx------ 3 root root 22 May 5 10:25 shard2
drwx------ 3 root root 22 May 5 10:25 shard3
[dave@www.cndba.cn_3 pbmPitr]#
因为我们现在不是共享存储，需要先把pbmPitr目录同步到所有节点。 然后才能执行恢复：
[dave@www.cndba.cn_3 backup]# scp -r pbmPitr mongodb1:`pwd`
dave@www.cndba.cn_1's password:
20220505022032-1.20220505022509-13.oplog.s2 100% 38KB 9.8MB/s 00:00
20220505022509-13.20220505022709-7.oplog.s2 100% 19KB 6.3MB/s 00:00
20220505022709-7.20220505022909-7.oplog.s2 100% 19KB 3.9MB/s 00:00
20220505022909-7.20220505023109-7.oplog.s2 100% 19KB 6.8MB/s 00:00
20220505023109-7.20220505023309-6.oplog.s2 100% 20KB 8.0MB/s 00:00
20220505023309-6.20220505023509-4.oplog.s2 100% 20KB 8.6MB/s 00:00
20220505023509-4.20220505023709-6.oplog.s2 100% 20KB 8.9MB/s 00:00
20220505023709-6.20220505023909-4.oplog.s2 100% 19KB 8.1MB/s 00:00
20220505023909-4.20220505024024-9.oplog.s2 100% 14KB 6.4MB/s 00:00
20220505022032-1.20220505022509-1.oplog.s2 100% 1286 551.8KB/s 00:00
20220505022509-1.20220505022719-1.oplog.s2 100% 678 324.0KB/s 00:00
20220505022719-1.20220505022919-1.oplog.s2 100% 276 151.5KB/s 00:00
20220505022919-1.20220505023119-1.oplog.s2 100% 872 480.0KB/s 00:00
20220505023119-1.20220505023319-1.oplog.s2 100% 276 150.8KB/s 00:00
20220505023319-1.20220505023519-1.oplog.s2 100% 594 323.5KB/s 00:00
20220505023519-1.20220505023709-1.oplog.s2 100% 649 347.2KB/s 00:00
20220505023709-1.20220505023909-1.oplog.s2 100% 276 155.8KB/s 00:00
20220505023909-1.20220505024019-1.oplog.s2 100% 623 283.3KB/s 00:00
20220505022032-1.20220505022459-1.oplog.s2 100% 1211 522.7KB/s 00:00
20220505022459-1.20220505022659-1.oplog.s2 100% 572 258.6KB/s 00:00
20220505022659-1.20220505022859-1.oplog.s2 100% 276 170.4KB/s 00:00
20220505022859-1.20220505023057-3.oplog.s2 100% 949 571.5KB/s 00:00
20220505023057-3.20220505023259-1.oplog.s2 100% 481 291.5KB/s 00:00
20220505023259-1.20220505023459-1.oplog.s2 100% 766 324.7KB/s 00:00
20220505023459-1.20220505023659-1.oplog.s2 100% 574 367.7KB/s 00:00
20220505023659-1.20220505023859-1.oplog.s2 100% 275 186.3KB/s 00:00
20220505023859-1.20220505024019-1.oplog.s2 100% 791 509.7KB/s 00:00
20220505022032-1.20220505022459-1.oplog.s2 100% 1485 734.9KB/s 00:00
20220505022459-1.20220505022709-1.oplog.s2 100% 645 328.8KB/s 00:00
20220505022709-1.20220505022909-1.oplog.s2 100% 276 114.1KB/s 00:00
20220505022909-1.20220505023058-1.oplog.s2 100% 942 559.4KB/s 00:00
20220505023058-1.20220505023259-1.oplog.s2 100% 479 230.4KB/s 00:00
20220505023259-1.20220505023459-1.oplog.s2 100% 684 390.7KB/s 00:00
20220505023459-1.20220505023659-1.oplog.s2 100% 630 414.5KB/s 00:00
20220505023659-1.20220505023859-1.oplog.s2 100% 275 185.7KB/s 00:00
20220505023859-1.20220505024019-1.oplog.s2 100% 754 446.6KB/s 00:00
[dave@www.cndba.cn_3 backup]#
执行PITR 恢复：
[dave@www.cndba.cn_1 backup]# pbm restore --time="2022-05-05T02:30:33"
Starting restore to the point in time '2022-05-05T02:30:33'...Restore to the point in time '2022-05-05T02:30:33' has started
2.8.5 PITR 恢复后的注意事项
PITR 恢复之后，之前的全量备份快照和oplog slices 都失效了，需要重新执行全量备份，并启用PITR。
[dave@www.cndba.cn_1 backup]# pbm backup
Starting backup '2022-05-05T02:51:39Z'....
Backup '2022-05-05T02:51:39Z' to remote store '/data/mongodb/backup' has started
[dave@www.cndba.cn_1 backup]# pbm config --set pitr.enabled=true
[pitr.enabled=true]
[dave@www.cndba.cn_1 backup]# pbm config
pitr:
enabled: true
oplogSpanMin: 2
compression: s2
storage:
type: filesystem
filesystem:
path: /data/mongodb/backup
[dave@www.cndba.cn_1 backup]#
2.9 删除全量备份和PITR 备份
2.9.1 查看备份信息
[dave@www.cndba.cn_1 backup]# pbm list
Backup snapshots:
2022-05-04T15:56:25Z <logical> [complete: 2022-05-04T15:56:29]
2022-05-04T16:10:02Z <logical> [complete: 2022-05-04T16:10:07]
2022-05-05T00:14:34Z <logical> [complete: 2022-05-05T00:14:40]
2022-05-05T02:20:25Z <logical> [complete: 2022-05-05T02:20:32]
2022-05-05T02:51:39Z <logical> [complete: 2022-05-05T02:51:43]
PITR <on>:
2022-05-05T02:20:33 - 2022-05-05T02:40:19
[dave@www.cndba.cn_1 backup]#
2.9.2 删除备份
[dave@www.cndba.cn_1 backup]# pbm list
Backup snapshots:
2022-05-04T15:56:25Z <logical> [complete: 2022-05-04T15:56:29]
2022-05-04T16:10:02Z <logical> [complete: 2022-05-04T16:10:07]
2022-05-05T00:14:34Z <logical> [complete: 2022-05-05T00:14:40]
2022-05-05T02:20:25Z <logical> [complete: 2022-05-05T02:20:32]
2022-05-05T02:51:39Z <logical> [complete: 2022-05-05T02:51:43]
PITR <on>:
2022-05-05T02:20:33 - 2022-05-05T02:40:19
[dave@www.cndba.cn_1 backup]# pbm delete-backup 2022-05-04T15:56:25Z
Are you sure you want delete backup(s)? [y/N] yes
Waiting for delete to be done ...[done]
Backup snapshots:
2022-05-04T16:10:02Z <logical> [complete: 2022-05-04T16:10:07]
2022-05-05T00:14:34Z <logical> [complete: 2022-05-05T00:14:40]
2022-05-05T02:20:25Z <logical> [complete: 2022-05-05T02:20:32]
2022-05-05T02:51:39Z <logical> [complete: 2022-05-05T02:51:43]
PITR <on>:
2022-05-05T02:20:33 - 2022-05-05T02:40:19
2022-05-05T02:51:44 - 2022-05-05T02:59:56
[dave@www.cndba.cn_1 backup]# pbm list
Backup snapshots:
2022-05-04T16:10:02Z <logical> [complete: 2022-05-04T16:10:07]
2022-05-05T00:14:34Z <logical> [complete: 2022-05-05T00:14:40]
2022-05-05T02:20:25Z <logical> [complete: 2022-05-05T02:20:32]
2022-05-05T02:51:39Z <logical> [complete: 2022-05-05T02:51:43]
PITR <on>:
2022-05-05T02:20:33 - 2022-05-05T02:40:19
2022-05-05T02:51:44 - 2022-05-05T02:59:56
[dave@www.cndba.cn_1 backup]#
2.9.3 删除PITR
[dave@www.cndba.cn_1 backup]# pbm delete-pitr --older-than 2022-05-05T02:30:33
Are you sure you want delete chunks? [y/N] yes
Waiting for delete to be done ...[done]
Backup snapshots:
2022-05-04T16:10:02Z <logical> [complete: 2022-05-04T16:10:07]
2022-05-05T00:14:34Z <logical> [complete: 2022-05-05T00:14:40]
2022-05-05T02:20:25Z <logical> [complete: 2022-05-05T02:20:32]
2022-05-05T02:51:39Z <logical> [complete: 2022-05-05T02:51:43]
PITR <on>:
2022-05-05T02:20:33 - 2022-05-05T02:40:19
2022-05-05T02:51:44 - 2022-05-05T02:59:56
[dave@www.cndba.cn_1 backup]#
版权声明：本文为博主原创文章，未经博主允许不得转载。
