标签：04 MongoDB 备份 34 Percona 2022 pbm Backup 20T12

2022年4月发布的Percona Backup for MongoDB(PBM)的1.7.0版本开始支持物理备份。

pbm的物理备份是基于backupCursors feature of PSMDB实现的，这也即意味着要想使用物理备份，你必须使用Percona Server for Mongodb。

备份

在每个复制集上，pbm使用$backupCursor来遍历需要拷贝归档备份的文件列表。获得列表后，下一步是确保集群一致。每个复制集发布一个观察到的最新操作的集群时间。备份leader选出最近的一个。这就是备份元数据中的备份时间戳(last_write_ts)。在备份时间上达成一致后，pbm-agent在每个集群节点上打开$backupCursorExtend。这个游标只有在该节点到达给定时间戳才会返回结果。因此，返回的日志列表(hournals)会包含一致的备份时间戳。至此，我们就有了要备份的文件列表。在每个节点拷贝到存储中，保存元数据，关闭游标，这就是备份的过程。如果想了解备份游标，可以参看https://www.percona.com/blog/2021/06/07/experimental-feature-backupcursorextend-in-percona-server-for-mongodb/

当然，pbm内部做的了更多的工作，选择恰当的节点做备份，在集群之间操作的协调，记录日志，错误处理等等。

备份的恢复时间戳

还原任何一个备份，pbm会将集群返回到一个特定的时间点。这里讨论的时间，不是墙上时钟，而是mongodb集群的逻辑时钟。因此，基于时间点的点，在所有节点上都是一致的。逻辑备份或物理备份，时间被记录在pbm status输出的pbm list的conplete部分。比如：

2022-04-19T15:36:14Z 22.29GB <physical> [complete: 2022-04-19T15:36:16]2022-04-19T14:48:40Z 10.03GB <logical> [complete: 2022-04-19T14:58:38]

这个时间不是备份结束的时间，而是集群状态被捕获的时间。在pbm的逻辑备份中，恢复时间戳接近于备份完成时间。为了定义这些，pbm需要等待，直到所有节点上的快照结束。然后，从备份开始时间开始，启动捕获oplog。

保持游标打开，可以确保在备份期间检查点数据不会变化。这样pbm可以提前定义正确的完成时间。

还原

恢复需要考虑一些点。

首先，备份中的文件可能包含一些目标时间(commonBackupTimestamp)之外的文件。要处理这个问题，pbm使用复制子系统的一个特殊的函数，设置oplog被还原的限制，通过设置oplogTruncateAfterPoint的值，该变量在local db的replset.oplogTruncateAfterPoint集合中。

除了oplogTruncateAfterPoint之外，数据库需要做一些其他的修改，在启动前清理干净。这需要多次以standalone的模式重启psmdb。

这反过来又给pbm操作带来了一些麻烦。为了在所有代理之间通信和协调其工作，PBM依赖于PSMDB本身。但是一旦集群被关闭，PBM必须切换到通过存储进行通信。此外，在standalone运行期间，PBM无法将其日志存储在数据库中。因此，在还原期间的某个时间点，pbm-agent日志仅在agent的stderr中可用。而且pbm日志将无法访问它们。我们计划通过物理备份GA来解决这个问题。

此外，我们必须决定副本集中的恢复策略。一种方法是恢复一个节点，然后删除其余节点上的所有数据，让PSMDB复制完成这项工作。尽管它更容易一些，但这意味着在InitialSync完成之前，集群将几乎没有用处。此外，此阶段的逻辑复制几乎忽略了物理还原为表带来的所有速度优势（稍后）。因此，我们着手恢复副本集中的每个节点。并确保在集群启动后，没有节点会发现任何差异并且不会启动ReSync。

与PBM的逻辑备份一样，当前可以将物理一次恢复到具有相同拓扑的集群，这意味着备份中的副本集名称应该与目标集群匹配。虽然从下一个 PBM 版本开始的逻辑备份不会成为问题。稍后此功能也将扩展到物理备份。除此之外，集群中的副本集数量可能会多于备份中的副本集，反之亦然。这意味着应该恢复备份中的所有数据。

性能评审

使用以下环境：

·三节点的复制集。每个节点都是mongod+pbm-agent，16GB，8vCPU

·存储：nyc3.digitaloceanspaces.com

·数据量：随机产生的，大小1mb的文档

 

一般来说，逻辑备份对小型数据库（几百兆）更有利。由于在这样的规模上，物理文件带来的数据之上的额外开销仍然会产生影响。基本上，在逻辑备份期间仅读取/写入用户数据意味着需要通过网络传输的数据更少。但是随着数据库的增长，逻辑读取（select）和写入（insert）的开销成为逻辑备份的瓶颈。至于物理备份，速度几乎总是只受限于进出远程存储的网络带宽。在我们的测试中，物理备份的恢复时间与数据集大小呈线性相关，而逻辑恢复时间呈非线性增长。拥有的数据越多，replay所有数据和重建索引所需的时间就越长。例如，对于600GB 数据集，物理还原所用时间比逻辑还原少 5 倍。

但在较小的数据库大小上，差异可以忽略不计——几分钟。因此，逻辑备份的主要好处不仅仅在于性能。这是灵活性。逻辑备份允许部分备份/恢复数据库（在 PBM 的路线图上）。可以选择要使用的特定数据库和/或集合。由于物理备份直接与数据库存储引擎文件一起使用，它们在一个全有或全无的框架中运行。

 

练习

pbm配置

从1.7.0版本开始，运行首先将pbm-agent进程的用户必须要能读写psmdb的数据目录。从1.7.0版本开始，将用户从pbm换成了mongod。

此外，要记住，要想使用物理备份，psmdb的版本必须是 4.2.15-16、4.4.6-8或者更高的版本。从这些版本才引入热备份和备份游标。

创建备份

新版本的pbm，用户可以指定是物理备份还是逻辑备份。缺省是逻辑备份：

> pbm backupStarting backup '2022-04-20T11:12:53Z'....Backup '2022-04-20T11:12:53Z' to remote store 's3://https://storage.googleapis.com/pbm-bucket' has started​> pbm backup -t physicalStarting backup '2022-04-20T12:34:06Z'....Backup '2022-04-20T12:34:06Z' to remote store 's3://https://storage.googleapis.com/pbm-bucket' has started​> pbm status -s cluster -s backupsCluster:========rs0:  - rs0/mongo1.perconatest.com:27017: pbm-agent v1.7.0 OK  - rs0/mongo2.perconatest.com:27017: pbm-agent v1.7.0 OK  - rs0/mongo3.perconatest.com:27017: pbm-agent v1.7.0 OKBackups:========S3 us-east-1 s3://https://storage.googleapis.com/pbm-bucket  Snapshots:    2022-04-20T12:34:06Z 797.38KB <physical> [complete: 2022-04-20T12:34:09]    2022-04-20T11:12:53Z 13.66KB <logical> [complete: 2022-04-20T11:12:58]

基于时间点恢复

当前仅支持逻辑备份的时间点恢复。这意味着pbm-agent需要一个逻辑备份快照才能开始定期保存oplog的连续切片。仍然可以在启用PITR时进行物理备份，它不会破坏或更改oplog保存过程。

到特定时间点的恢复过程还将使用相应的逻辑备份快照和oplog切片，这些切片将在备份之上重放。

检查日志

在物理备份期间，pbm日志可以通过pbm logs命令查看

> pbm logs -e backup/2022-04-20T12:34:06Z2022-04-20T12:34:07Z I [rs0/mongo2.perconatest.com:27017] [backup/2022-04-20T12:34:06Z] backup started2022-04-20T12:34:12Z I [rs0/mongo2.perconatest.com:27017] [backup/2022-04-20T12:34:06Z] uploading files2022-04-20T12:34:54Z I [rs0/mongo2.perconatest.com:27017] [backup/2022-04-20T12:34:06Z] uploading done2022-04-20T12:34:56Z I [rs0/mongo2.perconatest.com:27017] [backup/2022-04-20T12:34:06Z] backup finished

至于restore，pbm logs命令不提供有关从物理备份restore的信息。这是由restore过程的特殊性引起的，将在即将推出的PBM版本中得到改进。但是，pbm-agent 仍然在本地保存日志，因此可以检查有关每个节点上的还原过程的信息：

> sudo journalctl -u pbm-agent.service | grep restorepbm-agent[12560]: 2022-04-20T19:37:56.000+0000 I [restore/2022-04-20T12:34:06Z] restore started.......pbm-agent[12560]: 2022-04-20T19:38:22.000+0000 I [restore/2022-04-20T12:34:06Z] copying backup data.......pbm-agent[12560]: 2022-04-20T19:38:39.000+0000 I [restore/2022-04-20T12:34:06Z] preparing data.......pbm-agent[12560]: 2022-04-20T19:39:12.000+0000 I [restore/2022-04-20T12:34:06Z] restore finished <nil>pbm-agent[12560]: 2022-04-20T19:39:12.000+0000 I [restore/2022-04-20T12:34:06Z] restore finished successfully

从备份中还原

从物理备份还原过程类似于逻辑备份，但在PBM完成还原后需要几个额外的步骤。

> pbm restore 2022-04-20T12:34:06ZStarting restore from '2022-04-20T12:34:06Z'.....Restore of the snapshot from '2022-04-20T12:34:06Z' has started. Leader: mongo1.perconatest.com:27017/rs0

启动还原过程后，pbm cli会返回leader节点的id，这样可以通过检查pbm-agent leader节点的日志来跟踪还原过程。此外，状态被写入远程存储的元数据文件。状态文件被创建在存储的根路径，格式为：

.pbm.restore/<restore_timestamp>.json

在还原期间也可以用-w标记，这样会阻塞当前的shell会话等待还原过程结束。

> pbm restore 2022-04-20T12:34:06Z -wStarting restore from '2022-04-20T12:34:06Z'....Started physical restore. Leader: mongo2.perconatest.com:27017/rs0Waiting to finish...........................Restore successfully finished!

 

在还原结束后，需要完成以下步骤：

·重启所有的mongod节点

·重启pbm-agent

·运行以下命令，重新同步存储的备份列表

$ pbm config --force-resync

 

标签：04,MongoDB,备份,34,Percona,2022,pbm,Backup,20T12
来源： https://www.cnblogs.com/abclife/p/16320530.html

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。