PostgreSQL高可用：流复制+pgpool+pg_rman配置与故障切换实践

简介针对 PostgreSQL 数据库的高可用与读写分离需求这份文档以流复制搭配 pgpool-II 为主线为数据库运维及架构人员提供了一套从原理到实践的完整部署方案。内容先解析 WAL 日志在主备节点间的传输与复用机制包括 walwriter 周期刷新、walsender 发送、walreceiver 接收以及 startup 进程应用日志的完整链路并明确同步复制与异步复制的适用场景和选择建议随后介绍 pgpool-II 的连接池、负载均衡、复制自动切换和连接限制功能。文档为 docx 格式共 1 个文件压缩包约 773KB虽然体量不大但正文包含版本记录与完整目录覆盖环境准备、主库参数配置、备库初始化、pgpool 配置、启动验证与故障演练等关键环节并含资源调整、防火墙/SELinux、时钟同步、sysctl 等基础准备条目方便按章节直接落地。这份方案目前已有 466 人学习适合有 PostgreSQL 基础、想快速搭建主从高可用环境的读者作为参考资料。1. 从流复制到高可用这份方案文档到底解决了什么问题先给结论PostgreSQL 自身只解决数据同步不解决故障切换。主库宕机后备库不会自动接管客户端连接也不会自动转移。真正让这套架构变成“高可用”的是 pgpool 的 watchdog 和虚拟 IP 漂移机制。而文档里的方案本质上是把流复制、pgpool、pg_rman 三件套串成一条完整的链路——流复制保证 WAL 日志实时从主库传到备库pgpool 负责连接池、读写分离和故障时的自动切换pg_rman 负责离线备份兜底覆盖误操作和恶意破坏场景。这套方案特别适合 RHEL/CentOS 下不能联网安装软件包的客户环境文档里还专门配套了离线安装脚本。适合谁看正在搭 PG 主备、但还没搞定 pgpool 配置的 DBA 或运维工程师尤其是卡在 failover 不生效、虚拟 IP 不飘移这类问题上的人。2. 环境准备与选型先搞懂版本差异再动手改系统参数2.1 版本选型3.6 和 4.1 的 pgpool 配置完全是两套写法文档里给出了两套版本的对应关系。旧版本组合是 PostgreSQL 10.3 pgpool-II-3.6.14新版本组合是 PostgreSQL 12.2 pgpool-II-4.1.1操作系统覆盖 CentOS 6.5 和 CentOS 7.5。这里有一个容易翻车的点pgpool 3.6 和 4.1 的配置文件格式差异很大如果你在网上搜到的是 3.x 的配置教程直接套到 4.x 上启动必报错。4.x 版本把后端节点信息挪到了pgpool.conf里但参数名和 3.x 不一样比如 3.x 用的是backend_hostname14.x 虽然保留了类似写法但增加了很多 watchdog 相关的独立配置段。我的建议是新环境一律用新版本组合旧版本组合只用于维护存量系统。PostgreSQL 12 和 10 在流复制上的差异主要在标识文件——10 用recovery.conf12 改用standby.signal这个后面专节展开。2.2 系统参数调整sysctl、limits、时钟同步一个都不能少在装 PostgreSQL 之前操作系统层有六件事要做顺序不要乱关闭防火墙、关闭 SELinux、配置 hosts、配置 NTP 时钟同步、调整 sysctl、调整 limit 资源限制。防火墙和 SELinux 不关后面 pgpool 连接测试会报各种玄学错误比如连接超时或者认证失败但实际上根本不是密码问题。sysctl 配置里最关键的几个参数# /etc/sysctl.conf 追加以下内容 vm.overcommit_memory 0 kernel.shmmax 68719476736 kernel.shmall 4294967296 fs.file-max 6815744 net.core.rmem_max 16777216 net.core.wmem_max 16777216 net.ipv4.ip_local_port_range 9000 65500执行sysctl -p使配置生效。这里面kernel.shmmax和kernel.shmall决定共享内存上限如果你的 PG 配置了shared_buffers为 2GB 以上共享内存参数必须跟着调否则 PG 启动直接报 Cannot allocate memory。ip_local_port_range影响客户端连接时的端口分配连接数大的场景必须放开。然后是 limit 配置# /etc/security/limits.conf 追加 postgres soft nofile 65535 postgres hard nofile 65535 postgres soft nproc 65535 postgres hard nproc 65535注意这里用postgres用户单独设置不要只改全局的*因为 PG 服务进程是以 postgres 用户运行的。nofile限制的是文件描述符数量连接数高时不够用会报 Too many open filesnproc限制的是进程数。还有时钟同步主备库时间差超过一定阈值WAL 日志的时间戳对不上同步虽然不会中断但排查问题时时间线混乱非常痛苦。配置好 NTP 后执行ntpdate -u 时间服务器手动校准一次再启动chronyd或ntpd服务。2.3 目录规划与权限安装路径、数据目录、归档目录分开放文档里要求创建 postgres 用户并设置密码然后配置安装文件夹。这里有个实践中的细节安装目录、数据目录、归档目录、备份目录最好分成四个独立的路径。# 创建用户 useradd postgres passwd postgres # 规划目录结构 mkdir -p /opt/postgresql/pgdata # 数据目录 mkdir -p /opt/postgresql/archive # WAL 归档目录 mkdir -p /opt/postgresql/backup # pg_rman 备份目录 mkdir -p /opt/pgpool # pgpool 工作目录 # 目录权限 chown -R postgres:postgres /opt/postgresql chmod 750 /opt/postgresql/pgdata /opt/postgresql/archive目录权限这里很多人会忽略。pgdata目录权限必须设置为 700 或 750并且属主必须是 postgres 用户否则 PG 初始化时直接拒绝执行。archive 目录要确保 postgres 用户有写权限因为归档进程是在 postgres 用户下运行的。另外不要把数据目录放在/home/postgres下因为 home 目录的权限和挂载点可能有问题放在/opt或/data这类独立挂载点更稳妥。3. 安装 PostgreSQL 并配置流复制按 12.X 版本的做法来3.1 编译安装前的依赖准备与初始化RHEL 环境不能联网所以要先准备好依赖包。文档的附件里有“RHEL 安装环境获取脚本”它的作用是在能联网的机器上先把所有依赖和 rpm 包缓存下来再拷到客户环境离线安装。安装 PG 前必要的依赖包包括readline-devel、zlib-devel、gcc、make、flex、bison等。编译安装的流程比较固定# 解压源码包 tar -xzf postgresql-12.2.tar.gz cd postgresql-12.2 # 配置编译选项 ./configure --prefix/opt/postgresql/pg12 --with-pgport5432 # 编译安装 make -j 4 make install--prefix指定安装路径--with-pgport指定默认端口。如果你不指定--prefix默认装到/usr/local/pgsql后面环境变量和管理都要按这个路径来所以建议从一开始就固定好安装路径。编译时间取决于机器配置-j 4表示用 4 核并行编译。编译安装完后PG 的可执行文件在/opt/postgresql/pg12/bin下共享库在/opt/postgresql/pg12/lib下这些路径后续都要配置到环境变量里。3.2 初始化数据库与主库配置三个关键文件初始化数据库用initdb命令注意必须以 postgres 用户执行而且数据目录必须为空。# 切换到 postgres 用户 su - postgres # 设置环境变量 export PGHOME/opt/postgresql/pg12 export PGDATA/opt/postgresql/pgdata export PATH$PGHOME/bin:$PATH export LD_LIBRARY_PATH$PGHOME/lib:$LD_LIBRARY_PATH # 初始化数据目录 initdb -D $PGDATA -E UTF8 --localeen_US.UTF-8-E UTF8指定数据库编码--locale指定区域。这里有个容易忽略的点如果你用server encoding默认的SQL_ASCII后面创建中文数据会乱码或者报错。初始化完成后需要修改postgresql.conf和pg_hba.conf两个文件。主库上 12.X 版本的关键参数如下# postgresql.conf 关键参数master 节点 listen_addresses 0.0.0.0 port 5432 wal_level replica max_wal_senders 10 wal_keep_size 1024 hot_standby on synchronous_commit off synchronous_standby_names wal_level设置为replica表示启用流复制所需的 WAL 级别信息max_wal_senders决定最多允许多少个备库连接wal_keep_size表示保留多少 MB 的 WAL 日志在 pg_wal 目录中防止备库追不上主库时日志被回收。hot_standby允许备库接受只读查询这配合 pgpool 做读写分离必须开启。同步复制模式下需要设置synchronous_standby_names为备库名非空并且synchronous_commit on但异步模式更适合大多数业务因为同步模式下主库事务提交要等备库确认网络延迟直接变成写入延迟。然后是pg_hba.conf这里配置的是访问控制规则容易踩坑的是忘了加流复制用户的规则# pg_hba.conf 追加 host replication replica 192.168.1.0/24 md5 host all all 192.168.1.0/24 md5第一条是允许流复制用户从内网网段连接做 WAL 拉取第二条是允许应用连接。注意replication这个关键字是固定写法不是数据库名。规则顺序很重要pg_hba.conf从上往下匹配第一条匹配就停止所以把精确的 replication 规则放在所有规则前面避免被all规则抢先匹配导致权限不对。3.3 创建流复制用户并启动主库配置好文件后启动主库并创建专用的复制用户不要用超级用户 postgres 做流复制安全性和可维护性都差。# 启动主库 pg_ctl -D $PGDATA -l /opt/postgresql/pg12/log/pg.log start # 创建流复制用户 psql -U postgres -c CREATE USER replica REPLICATION LOGIN PASSWORD replica_password;流复制用户需要REPLICATION权限这个权限只能通过CREATE USER ... REPLICATION授予普通CREATEROLE权限不够。创建完成后在主库上执行SELECT * FROM pg_stat_replication;此时应该空因为备库还没连上来。3.4 备库部署基础备份的取法与 12.X 的标识文件备库的搭建方式不是重新 initdb而是从主库拉一份基础备份。常用工具是pg_basebackup这是 PG 自带的物理备份工具专门用于搭建流复制备库。# 在备库执行需要在备库上先创建好数据目录的空目录 pg_basebackup -h 192.168.1.10 -p 5432 -U replica -D /opt/postgresql/pgdata -P -R -X stream参数说明-h主库 IP-U流复制用户-D备库数据目录-P显示进度-R自动生成 standby 配置-X stream表示在备份过程中使用流复制方式传输 WAL 日志。这里-R参数非常关键——它会在备库数据目录下自动生成standby.signal文件并且在postgresql.conf末尾追加primary_conninfo配置。如果忘记加-R备库不知道自己是备库启动后会和主库抢数据导致数据不一致。12.X 版本和旧版本的核心区别就在标识文件上。旧版本10.x 及以前在备库数据目录下放一个recovery.conf文件内容包含standby_mode on和primary_conninfo而 12.X 把这个文件取消了改成了standby.signal空文件加postgresql.conf里的primary_conninfo参数。反过来主库上如果是从旧版本升级过来的需要确认recovery.done文件是否存在12.X 版本主库不再需要这个文件。这个差异是很多从 10 升 12 的项目翻车的重灾区——旧的recovery.conf还留在数据目录里PG 12 启动时直接报错拒绝启动。备库启动前还要确保postgresql.conf里配置好了primary_conninfo# 备库 postgresql.conf primary_conninfo host192.168.1.10 port5432 userreplica passwordreplica_password application_namestandby1application_name必须设置因为后面配置同步复制时synchronous_standby_names匹配的就是这个名字。备库启动后回到主库执行-- 在主库执行查看备库是否已连接 SELECT client_addr, state, sync_state FROM pg_stat_replication;看到state streaming且sync_state async说明流复制已经建立。测试一下在主库建一张表插入数据在备库查询如果数据可见备库以只读方式运行说明流复制链路是通的。4. 安装配置 pgpool从连接池到自动故障转移的完整流程4.1 安装 pgpool 与注册数据库函数pgpool 需要安装在两台节点上主库节点和备库节点各一个因为 failover 后虚拟 IP 要能从故障节点飘移到存活节点。编译安装的方式和 PG 类似# 解压源码包 tar -xzf pgpool-II-4.1.1.tar.gz cd pgpool-II-4.1.1 # 编译安装 ./configure --prefix/opt/pgpool --with-pgsql/opt/postgresql/pg12 make -j 4 make install--with-pgsql参数指定 PG 的安装路径因为 pgpool 需要链接 PG 的客户端库。安装完成后还需要在 PG 中注册 pgpool 提供的函数这些函数用于健康检查和 watchdog 状态查询。pgpool 源码包的sql目录下有针对不同 PG 版本的 SQL 脚本需要在主库上执行# 以 postgres 用户在主库执行 pgpool 的 SQL 函数 cd /opt/pgpool psql -U postgres -f /opt/pgpool/share/pgpool-II/insert_lock.sql psql -U postgres -f /opt/pgpool/share/pgpool-II/pgpool-recovery.sql psql -U postgres -f /opt/pgpool/share/pgpool-II/pgpool_adm.sqlinsert_lock.sql用于解决并发插入时的锁问题pgpool-recovery.sql提供在线恢复功能所需的函数pgpool_adm.sql提供集群管理函数。这些脚本只需要在主库执行一次备库通过流复制自动同步。4.2 pgpool.conf 核心参数解析4.X 版本的配置逻辑pgpool 的配置文件是pgpool.conf在/opt/pgpool/etc目录下。4.X 版本的核心配置逻辑和 3.X 差异很大重点说 4.X 的写法。一个最小可用的集群配置包含三部分后端节点定义、watchdog 定义、负载均衡策略。# pgpool.conf 核心参数节点 1 listen_addresses 0.0.0.0 port 9999 socket_dir /tmp pcp_listen_addresses 0.0.0.0 pcp_port 9898 pcp_socket_dir /tmp # 后端节点定义主库和备库 backend_hostname0 192.168.1.10 backend_port0 5432 backend_weight0 1 backend_flag0 ALWAYS_PRIMARY backend_hostname1 192.168.1.11 backend_port1 5432 backend_weight1 1 backend_flag1 ALLOW_TO_FAILOVERbackend_flag0设置为ALWAYS_PRIMARY是 4.X 新增的它告诉 pgpool 节点 0 始终是主库节点failover 时不会把节点 0 当作备库切换目标。ALLOW_TO_FAILOVER表示允许节点 1 在节点 0 故障时被提升为主库。这个参数不配置failover 可能不会触发自动切换。然后是负载均衡和复制模式的配置# 复制模式与负载均衡 replication_mode off load_balance_mode on master_slave_mode on master_slave_sub_mode stream # 连接池 connection_cache on max_pool 4 max_init_children 32 max_connections 0master_slave_mode on表示使用流复制模式master_slave_sub_mode stream指定流复制子类型这个必须和 PG 的流复制方式对应。load_balance_mode on开启读写分离SELECT 查询会分发到两台节点INSERT/UPDATE/DELETE 只在主库执行。connection_cache on开启连接池max_pool是每个子进程缓存的最大连接数max_init_children是允许的并发连接数这里如果设置得太小应用并发打满后 pgpool 会把连接排队而不是拒绝队列过长就会导致应用侧超时。watchdog 部分是高可用的核心4.X 配置如下# watchdog 配置节点 1 use_watchdog on wd_port 9000 wd_hostname 192.168.1.10 wd_interval 5 # 虚拟 IP 配置 delegate_IP 192.168.1.100 if_cmd_path /sbin if_up_cmd ip addr add $_IP_$/24 brd $_IP_$ dev eth0 if_down_cmd ip addr del $_IP_$/24 dev eth0 # watchdog 对端节点 wd_lifecycle_check_port 9694 wd_remote_0_host 192.168.1.11 wd_remote_0_port 9000use_watchdog on启用 watchdog 进程delegate_IP是虚拟 IP客户端连接时连这个 IP不直接连后端节点。if_up_cmd和if_down_cmd是虚拟 IP 绑定和释放的命令$_IP_$是 pgpool 内部变量会自动替换成delegate_IP的地址。两个 pgpool 节点通过 watchdog 互相监控当前持有 VIP 的节点故障后另一个节点执行if_up_cmd把 VIP 绑到自己网卡上。这套机制里心跳端口和虚拟 IP 的配置错误是 failover 不生效的主要原因。4.3 pcp.conf、pool_passwd、failover 脚本的配套设置pgpool 还有三个配置文件要一起配好pcp.conf是 pcp 命令的认证文件pool_passwd是数据库用户的密码文件failover脚本是切换时执行的动作。# 生成 pcp.conf使用 pg_md5 生成加密密码 /opt/pgpool/bin/pg_md5 -p -u postgres # 输入密码得到 MD5 值写入 pcp.conf echo postgres:生成的md5值 /opt/pgpool/etc/pcp.conf # 生成 pool_passwd /opt/pgpool/bin/pg_md5 -m -u postgres -p 数据库密码pg_md5 -m模式会生成pool_passwd文件pgpool 客户端连接时用它做密码认证。如果不生成这个文件客户端通过 pgpool 连接数据库时只能免密访问或者直接失败。然后配置 failover 脚本# /opt/pgpool/etc/failover.sh #!/bin/bash # 参数说明$1 故障节点的编号$2 故障节点的主机名$3 故障节点的端口 # $4 被提升为主库的节点编号$5 被提升节点的主机名$6 被提升节点的端口 PGPOOL/opt/pgpool/bin PGPOOL_CONF/opt/pgpool/etc/pgpool.conf LOGDIR/opt/pgpool/log echo date: failover triggered, failed node: $1, promoted node: $4 $LOGDIR/failover.log # 可以在这里增加告警脚本比如调用 zabbix 接口或发送邮件failover 脚本的执行权限必须配置好chmod x /opt/pgpool/etc/failover.sh同时在pgpool.conf中指定failover_command /opt/pgpool/etc/failover.sh %d %h %p %D %m %M %H %Pfailover_command中%d是故障节点编号%h是故障节点主机名%p是故障节点端口%D是故障节点数据目录%m是被提升的节点编号%M是被提升节点主机名%H是被提升节点端口。脚本里的日志输出可以帮你确认 failover 是否真的被触发这在排查pgpool 没有切换问题时是第一手证据。4.4 启动服务并验证集群状态两个节点配置好后先在备库节点启动 pgpool再启动主库节点上的 pgpool这样可以避免备库节点抢占虚拟 IP。# 在节点 2备库所在节点启动 /opt/pgpool/bin/pgpool -f /opt/pgpool/etc/pgpool.conf # 在节点 1主库所在节点启动 /opt/pgpool/bin/pgpool -f /opt/pgpool/etc/pgpool.conf启动后检查状态# 查看 pgpool 进程 ps -ef | grep pgpool # 通过 pcp 命令查看后端节点状态 /opt/pgpool/bin/pcp_node_info -h 192.168.1.100 -p 9898 -U postgrespcp_node_info会输出两个节点的状态status字段应该是up或primary。如果显示down检查 pgpool 所在节点到对应 PG 节点的网络连通性和认证配置。客户端连接测试# 通过 pgpool 连接数据库虚拟 IP psql -h 192.168.1.100 -p 9999 -U postgres -d postgres连接成功后执行SHOW pool_nodes;可以看到每个后端节点的状态和负载权重。如果SHOW pool_nodes能正常返回两行且状态为 up说明 pgpool 集群已经就绪读写分离链路已经打通。5. 避坑指南pgpool 部署与 эксплуатации 中五个踩过的坑5.1 standby.signal 缺失导致备库数据被写入现象备库启动后主库pg_stat_replication中看不到备库进程但是备库日志显示 database system is not in standby mode最后备库也能正常接受写入。原因12.X 版本中备库身份依赖standby.signal文件识别如果搭建备库时用了pg_basebackup但忘记加-R参数或者手动复制数据目录时丢了standby.signal备库会以普通主库模式启动两个节点同时可写数据分叉。解决确认备库数据目录下有standby.signal文件没有则手动创建touch $PGDATA/standby.signal同时检查postgresql.conf的primary_conninfo是否配置正确然后重启备库。5.2 pgpool 连接报 all backend nodes are down现象客户端通过 pgpool 连接数据库报all backend nodes are down但节点上 PG 进程实际在运行。原因这个报错说明 pgpool 的健康检查失败但它连接的不是 PG 的 5432 端口而是 pgpool.conf 中配置的backend_hostname0和backend_port0。最常见的失误是backend_hostname0写成了localhost而 pgpool 和 PG 不在同一台机器上或者backend_port0写成了 pgpool 自己的 9999 端口。解决用telnet测试 pgpool 所在机器到后端节点的 5432 端口是否通检查pg_hba.conf中是否允许 pgpool 所在机器的 IP 通过认证确认backend_hostname0填写的是真实 IP 而不是 localhost。5.3 主库切换后回切导致两个集群分叉现象主库 A 故障pgpool 自动将备库 B 提升为主库业务恢复。后来 A 修复完成重启 A结果 A 和 B 都认为自己是主库数据开始分流。原因PG 的流复制是单向的A 恢复后不会自动变成 B 的备库必须手动重新搭建备库。这是很多初用者最容易忽略的坑——pgpool 只能帮你切换不能帮你回切。解决回切流程是先在 A 上清空数据目录重新执行pg_basebackup从 B 拉取基础备份配置standby.signal和primary_conninfo指向 B让 A 以备库身份加入集群然后再做一次 failover 把主库权切回 A。这个过程没有捷径我也是在线上环境吃过一次亏才彻底记住。5.4 pgpool 启动报 could not open configuration file现象启动 pgpool 时报找不到配置文件路径确认无误但仍然报错。原因pgpool 对配置文件路径敏感如果使用相对路径启动它会在当前目录查找而 pgpool 安装进/opt/pgpool后配置文件在/opt/pgpool/etc下从其他目录启动自然找不到。解决启动时强制使用绝对路径/opt/pgpool/bin/pgpool -f /opt/pgpool/etc/pgpool.conf -a /opt/pgpool/etc/pool_hba.conf-a参数指定pool_hba.conf的路径如果不指定pgpool 默认在编译路径下找而你如果用编译时的默认路径安装可能和实际解压路径不一致。5.5 虚拟 IP 漂移不生效看日志发现 arping 失败现象主库节点宕机后watchdog 状态显示切到了备库节点但客户端访问虚拟 IP 仍然不通。原因虚拟 IP 配置里if_up_cmd中的网卡名写错了。在 RHEL 7 上网卡名可能是ens160而不是eth0ip addr add命令执行失败后 VIP 根本绑不上去。解决先确认网卡名ip a命令查看然后修改if_up_cmd /sbin/ip addr add $_IP_$/24 brd $_IP_$ dev ens160 if_down_cmd /sbin/ip addr del $_IP_$/24 dev ens160修改后重启 pgpool再在主库节点手动执行ip addr add 192.168.1.100/24 dev ens160测试一遍绑定命令是否报错。这个问题的隐蔽之处在于 pgpool 日志中 watchdog 状态明明已经是STANDBY或PRIMARY但 VIP 就是不通排查时容易忽略 is_up_cmd 里的命令是实际在操作系统层执行的。6. 验证与备份用一场 Failover 测试和一套离线脚本收尾6.1 Failover 测试的标准操作流程配置完成不等于方案可用故障切换必须实际演练过一次才能确认配置正确。文档的第十章给出了完整的测试路径我强烈建议你按照这个顺序做不要跳步。第一步关闭主库的 PG 进程模拟数据库故障# 在主库节点执行模拟 PG 进程崩溃 su - postgres -c /opt/postgresql/pg12/bin/pg_ctl -D /opt/postgresql/pgdata stop -m immediate注意用immediate而不是fastimmediate模拟的是异常终止不会做干净的关闭流程更接近真实故障场景。执行后观察备库节点的 pgpool 日志和 failover 脚本日志确认failover.sh被执行、备库 PG 被提升为主库。正常情况下大约 10 到 20 秒内完成切换。第二步检查虚拟 IP 是否漂移到备库节点# 在备库节点执行 ip addr show | grep 192.168.1.100如果 VIP 已经绑定在备库网卡上说明漂移成功。第三步通过 pgpool 连接数据库验证读写功能psql -h 192.168.1.100 -p 9999 -U postgres -d postgres -c CREATE TABLE test_failover(id int); psql -h 192.168.1.100 -p 9999 -U postgres -d postgres -c INSERT INTO test_failover VALUES (1);写入如果能成功执行说明新主库已经完全接管业务。第四步恢复原主库节点为备库按 5.3 的描述重新执行pg_basebackup加入集群这时不能直接启动原主库必须先确认它的角色是备库。整个测试做完这套高可用方案才算真正闭环。6.2 pg_rman 备份的初始化与验证pg_rman 是 PostgreSQL 的备份工具特点是不用停库支持全量备份和归档日志备份。安装和使用有几个关键步骤。文档里特别提醒了版本问题——pg_rman 是独立于 PG 发布的必须选择和 PG 版本匹配的版本版本不匹配会导致备份时报 incompatible version 错误。初始化备份目录# 配置环境变量 export PATH/opt/pg_rman/bin:$PATH export PGDATA/opt/postgresql/pgdata export BACKUP_PATH/opt/postgresql/backup # 创建备份目录并初始化 mkdir -p /opt/postgresql/backup pg_rman init -B /opt/postgresql/backup-B参数指定备份目录pg_rman init会创建备份目录结构和系统表。然后验证归档模式是否开启-- 查看归档状态 SHOW archive_mode; SHOW archive_command; SHOW wal_level;archive_mode必须为onarchive_command不能为空wal_level必须为replica或logical。如果archive_mode是off需要在postgresql.conf中设置archive_mode on并配置archive_command然后重启 PG。执行全量备份pg_rman backup -B /opt/postgresql/backup --full -C -P--full指定全量备份-C压缩备份文件-P显示进度。备份完成后执行验证pg_rman validate -B /opt/postgresql/backupvalidate是备份流程中容易跳过的步骤但它决定了备份能否用于恢复。validate会检查备份集完整性确认所有 WAL 归档都可用。如果验证不通过备份文件多点少点很难发现真正需要恢复时就直接翻车。日常做全量备份时我的习惯是周一全量、每天做归档备份这样恢复点最多丢失一天的量。6.3 离线脚本的配合用法文档附带三个脚本配置安装环境脚本、安装 postgreSQL 和 pg_rman 的脚本、RHEL 安装环境获取脚本。这三个脚本的配合逻辑是从联网环境收集 rpm 包到离线环境解压安装。基础做法是在能联网的 RHEL 机器上配置 yum 源并开启keepcache1把安装过程中下载的所有 rpm 包缓存到本地然后打包拷到客户环境离线环境下用rpm -ivh *.rpm批量安装。这比在客户环境用yum install逐个试要快得多也避免了依赖包缺失时在离线环境下无从下手的局面。脚本细节不用自己写但建议拿到脚本后先在测试环境完整跑一遍确认收集的包覆盖了 PG 编译所需的所有依赖因为不同客户的 RHEL 小版本差异可能导致依赖包清单不同。我记得第一次在客户现场跑这套脚本时就因为 RHEL 7.5 和 7.9 的依赖差异少拷了一个libicuPG 编译到一半报错现场又没有网络只能联系人重新打包再跑一次从那以后我每次都会先在本地搭一个同版本虚拟机把脚本全流程走一遍再进客户环境希望帮到你。本文还有配套的精品资源点击获取