关于mongodb:技术分享-PBM备份恢复

35次阅读

共计 7786 个字符，预计需要花费 20 分钟才能阅读完成。

作者：张洪

爱可生南区 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

分片集群复原

分片集群在做复原前，须要先实现以下步骤

  1. 进行 balancer

    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

异机复原

从 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

已知限度

  1. 只反对逻辑备份复原
  2. 不反对分片汇合
  3. 不反对批量指定 namespace
  4. 不反对 Multi-collection 事务
  5. 不能备份复原本地数据库中的零碎汇合
  6. 工夫点复原须要通过齐全备份来作为根底

参考链接：https://docs.percona.com/percona-backup-mongodb/intro.html

正文完
mongodb
发表至： mongodb
2023-03-23
 0
关于mongodb:技术分享-基于-mongo-cluster-的-PITR-恢复案例一则
关于mongodb:MongoDB高手课学习记录第二十四天
关于mongodb:mongoTemplate-常用实操
关于mongodb:活动报名-MongoDB-使用规范及最佳实践线上直播来啦