备份机制

Mon, 01 Jan 0001 00:00:00 +0000

备份可以通过内置脚本调用，使用节点 crontab 定时执行，由 pgbackrest 管理，存储在备份仓库中，仓库可以是本地磁盘文件系统或 MinIO / S3，并支持不同的保留策略。

脚本

您可以使用 pg_dbsu 用户（默认为 postgres）执行 pgbackrest 命令创建备份：

pgbackrest --stanza=pg-meta --type=full backup # 为集群 pg-meta 创建全量备份

$ pgbackrest --stanza=pg-meta --type=full backup
2025-07-15 01:36:57.007 P00 INFO: backup command begin 2.54.2: --annotation=pg_cluster=pg-meta ...
2025-07-15 01:36:57.030 P00 INFO: execute non-exclusive backup start: backup begins after the requested immediate checkpoint completes
2025-07-15 01:36:57.105 P00 INFO: backup start archive = 000000010000000000000006, lsn = 0/6000028
2025-07-15 01:36:58.540 P00 INFO: new backup label = 20250715-013657F
2025-07-15 01:36:58.588 P00 INFO: full backup size = 44.5MB, file total = 1437
2025-07-15 01:36:58.589 P00 INFO: backup command end: completed successfully (1584ms)

$ pgbackrest --stanza=pg-meta --type=diff backup
2025-07-15 01:37:24.952 P00 INFO: backup command begin 2.54.2: ...
2025-07-15 01:37:24.985 P00 INFO: last backup label = 20250715-013657F, version = 2.54.2
2025-07-15 01:37:26.337 P00 INFO: new backup label = 20250715-013657F_20250715-013724D
2025-07-15 01:37:26.381 P00 INFO: diff backup size = 424.3KB, file total = 1437
2025-07-15 01:37:26.381 P00 INFO: backup command end: completed successfully (1431ms)

$ pgbackrest --stanza=pg-meta --type=incr backup
2025-07-15 01:37:30.305 P00 INFO: backup command begin 2.54.2: ...
2025-07-15 01:37:30.337 P00 INFO: last backup label = 20250715-013657F_20250715-013724D, version = 2.54.2
2025-07-15 01:37:31.356 P00 INFO: new backup label = 20250715-013657F_20250715-013730I
2025-07-15 01:37:31.403 P00 INFO: incr backup size = 8.3KB, file total = 1437
2025-07-15 01:37:31.403 P00 INFO: backup command end: completed successfully (1099ms)

$ pgbackrest --stanza=pg-meta info
stanza: pg-meta
 status: ok
 cipher: aes-256-cbc

 db (current)
 wal archive min/max (17): 000000010000000000000001/00000001000000000000000A

 full backup: 20250715-013657F
 timestamp start/stop: 2025-07-15 01:36:57+00 / 2025-07-15 01:36:58+00
 wal start/stop: 000000010000000000000006 / 000000010000000000000006
 database size: 44.5MB, database backup size: 44.5MB
 repo1: backup size: 8.7MB

 diff backup: 20250715-013657F_20250715-013724D
 timestamp start/stop: 2025-07-15 01:37:24+00 / 2025-07-15 01:37:26+00
 database size: 44.5MB, database backup size: 424.3KB
 repo1: backup size: 94KB
 backup reference total: 1 full

 incr backup: 20250715-013657F_20250715-013730I
 timestamp start/stop: 2025-07-15 01:37:30+00 / 2025-07-15 01:37:31+00
 database size: 44.5MB, database backup size: 8.3KB
 repo1: backup size: 504B
 backup reference total: 1 full, 1 diff

这里的 stanza 是数据库集群名称：pg_cluster，在默认配置中为 pg-meta。

3坏2应急处理

Sat, 11 Jan 2025 00:00:00 +0000

如果经典3节点高可用部署同时出现两台（多数主体）故障，系统通常无法自动完成故障切换，需要人工介入：

首先判断另外两台服务器的情况，如果短时间内可以拉起，优先选择拉起另外两台服务。否则进入 紧急止血流程

紧急止血流程假设您的管理节点故障，只有单台普通数据库节点存活，在这种情况下，最快的恢复操作流程为：

调整 HAProxy 配置，将流量指向主库。
关闭 Patroni，手动提升 PostgreSQL 从库为主库。

调整HAProxy配置

如果你通过其他方式绕开 HAProxy 访问集群，那么可以跳过这一步。如果你通过 HAProxy 方式访问数据库集群，那么你需要调整负载均衡配置，将读写流量手工指向主库。

编辑 /etc/haproxy/<pg_cluster>-primary.cfg 配置文件，其中 <pg_cluster> 为你的 PostgreSQL 集群名称，例如 pg-meta。
将健康检查配置选项注释，停止进行健康鉴擦好
将服务器列表中，其他两台故障的机器注释掉，只保留当前主库服务器。

listen pg-meta-primary
 bind *:5433
 mode tcp
 maxconn 5000
 balance roundrobin

 # 注释掉以下四行健康检查配置
 #option httpchk # <---- remove this
 #option http-keep-alive # <---- remove this
 #http-check send meth OPTIONS uri /primary # <---- remove this
 #http-check expect status 200 # <---- remove this

 default-server inter 3s fastinter 1s downinter 5s rise 3 fall 3 on-marked-down shutdown-sessions slowstart 30s maxconn 3000 maxqueue 128 weight 100
 server pg-meta-1 10.10.10.10:6432 check port 8008 weight 100

 # 注释掉其他两台故障的机器
 #server pg-meta-2 10.10.10.11:6432 check port 8008 weight 100 <---- comment this
 #server pg-meta-3 10.10.10.12:6432 check port 8008 weight 100 <---- comment this

配置调整完成后，先不着急执行 systemctl reload haproxy 重载生效，等待后续主库提升后一起执行。以上配置的效果是，HAProxy 将不再进行主库健康检查（默认使用 Patroni），而是直接将写入流量指向当前主库

任务，概念 on PIGSTY

备份机制

脚本

3坏2应急处理

调整HAProxy配置