2. 首页 > PostgreSQL教程 > 正文

PostgreSQL教程FG307-PostgreSQL高可用集群配置

教程整理：风哥教程  |  更新时间：2026-01-22  |  教程分类：PostgreSQL教程  |  文档学习：26

本文档风哥主要介绍PostgreSQL高可用集群配置，包括高可用架构、主从复制、PgPool-II配置以及故障转移等内容。风哥教程参考PostgreSQL官方文档Server Administration部分，适合DBA人员在生产环境中使用。

Part01-基础概念与理论知识

1.1 PostgreSQL高可用概述

PostgreSQL高可用是指通过各种技术手段，确保数据库系统在面对硬件故障、软件故障或网络故障时，能够持续提供服务，减少停机时间，提高系统的可靠性和可用性。

PostgreSQL高可用的重要性：

  • 业务连续性：确保业务在故障后能够快速恢复
  • 数据安全：防止数据丢失或损坏
  • 用户体验：减少服务中断对用户的影响
  • 合规要求：满足行业合规性要求
  • 降低风险：减少系统故障带来的风险

1.2 PostgreSQL高可用架构

PostgreSQL高可用架构主要包括以下几种：

  • 主从复制：一个主节点和多个从节点，主节点负责写入，从节点负责读取
  • 流复制：基于WAL日志的实时复制，提供近实时的数据同步
  • 级联复制：从节点作为其他从节点的主节点，减少主节点的负担
  • 多主复制：多个主节点，都可以进行写入操作
  • 集群解决方案：如Patroni、Repmgr等，提供自动故障转移

1.3 PostgreSQL高可用组件

PostgreSQL高可用系统的主要组件包括：

# 高可用组件
1. 主节点：负责处理所有写入操作
2. 从节点：复制主节点的数据，处理读取操作
3. 复制机制：如流复制、逻辑复制等
4. 故障检测：监控节点状态，检测故障
5. 故障转移：当主节点故障时，自动将从节点提升为主节点
6. 负载均衡：分发客户端请求，提高系统性能
7. 监控系统：监控集群状态，及时发现问题
8. 管理工具：如PgPool-II、Patroni、Repmgr等
风哥提示：了解PostgreSQL高可用的架构和组件，是构建高可用集群的基础。更多视频教程www.fgedu.net.cn

Part02-生产环境规划与建议

2.1 高可用规划

在生产环境中，合理的高可用规划是确保系统可靠性的关键：

# 高可用规划原则
1. 可用性目标：确定系统的可用性目标，如99.9%或99.99%
2. 故障场景：识别可能的故障场景，如硬件故障、软件故障、网络故障等
3. 恢复时间：确定可接受的恢复时间目标（RTO）
4. 数据丢失：确定可接受的数据丢失目标（RPO）
5. 资源需求：评估所需的硬件、软件和网络资源
6. 成本预算：考虑高可用方案的成本

# 高可用规划示例
– 主从架构：1主2从
– 复制方式：流复制
– 故障转移：自动故障转移
– 负载均衡：PgPool-II
– 监控：Prometheus + Grafana

2.2 高可用需求分析

高可用需求分析应包括以下内容：

  • 业务需求：了解业务对可用性的要求
  • 数据重要性：评估数据的重要性和价值
  • 性能需求：考虑系统的性能要求
  • 可扩展性：考虑系统的可扩展性需求
  • 维护需求：考虑系统的维护需求

2.3 高可用架构设计

高可用架构设计应考虑以下因素：

# 高可用架构设计
1. 节点分布：将节点分布在不同的物理位置，避免单点故障
2. 网络设计：确保网络连接的可靠性和带宽
3. 存储设计：使用可靠的存储设备，如RAID
4. 监控设计：建立完善的监控系统
5. 故障转移设计：设计合理的故障转移策略
6. 测试计划：制定详细的测试计划，验证高可用方案

# 高可用架构示例
– 主节点：192.168.1.10
– 从节点1：192.168.1.11
– 从节点2：192.168.1.12
– PgPool-II：192.168.1.13
– 负载均衡：192.168.1.14

风哥教程针对风哥教程针对风哥教程针对生产环境建议：根据业务需求和资源情况，设计合理的高可用架构，确保系统的可靠性和可用性。学习交流加群风哥微信: itpux-com

Part03-生产环境项目实施方案

3.1 主从复制配置

3.1.1 配置主节点

# 配置主节点
$ sudo vi /postgresql/fgdata/postgresql.conf

# 启用复制
listen_addresses = ‘*’
max_wal_senders = 10
wal_level = replica
max_replication_slots = 10
hot_standby = on

# 重启PostgreSQL
$ sudo systemctl restart postgresql

# 创建复制用户
$ psql -U postgres -c “CREATE ROLE replicator REPLICATION LOGIN PASSWORD ‘password’;”

# 配置pg_hba.conf
$ sudo vi /postgresql/fgdata/pg_hba.conf

# 添加复制权限
host replication replicator 192.168.1.11/32 md5
host replication replicator 192.168.1.12/32 md5

# 重启PostgreSQL
$ sudo systemctl restart postgresql

# 验证主节点状态
$ psql -U postgres -c “SELECT * FROM pg_stat_replication;”

3.1.2 配置从节点

# 停止从节点PostgreSQL
$ sudo systemctl stop postgresql

# 清理数据目录
$ sudo rm -rf /postgresql/fgdata/*

# 从主节点复制数据
$ pg_basebackup -h 192.168.1.10 -U replicator -D /postgresql/fgdata -F p -X stream -P

# 创建recovery.conf文件
$ sudo vi /postgresql/fgdata/recovery.conf

standby_mode = ‘on’
primary_conninfo = ‘host=192.168.1.10 port=5432 user=replicator password=password’
trigger_file = ‘/postgresql/fgdata/trigger_file’

# 启动从节点PostgreSQL
$ sudo systemctl start postgresql

# 验证从节点状态
$ psql -U postgres -c “SELECT pg_is_in_recovery();”
pg_is_in_recovery
——————-
t

# 验证复制状态
$ psql -U postgres -c “SELECT * FROM pg_stat_wal_receiver;”

3.2 PgPool-II配置

3.2.1 安装PgPool-II

# 在CentOS/RHEL上安装PgPool-II
$ sudo yum install epel-release
$ sudo yum install pgpool-II-pg18

# 在Ubuntu/Debian上安装PgPool-II
$ sudo apt update
$ sudo apt install pgpool2

# 验证安装
$ pgpool –version
pgpool-II version 4.5.0 (built with PostgreSQL 18.3)

3.2.2 配置PgPool-II

# 编辑PgPool-II配置文件
$ sudo vi /etc/pgpool-II/pgpool.conf

# 基本配置
listen_addresses = ‘*’
port = 9999

# 后端服务器配置
backend_hostname0 = ‘192.168.1.10’
backend_port0 = 5432
backend_weight0 = 1
backend_data_directory0 = ‘/postgresql/fgdata’
backend_flag0 = ‘ALLOW_TO_FAILOVER’

backend_hostname1 = ‘192.168.1.11’
backend_port1 = 5432
backend_weight1 = 1
backend_data_directory1 = ‘/postgresql/fgdata’
backend_flag1 = ‘ALLOW_TO_FAILOVER’

backend_hostname2 = ‘192.168.1.12’
backend_port2 = 5432
backend_weight2 = 1
backend_data_directory2 = ‘/postgresql/fgdata’
backend_flag2 = ‘ALLOW_TO_FAILOVER’

# 负载均衡配置
load_balance_mode = on

# 连接池配置
connection_cache = on
max_pool = 4
num_init_children = 64
max_connections = 200

# 认证配置
auth_type = md5
auth_file = ‘/etc/pgpool-II/pool_hba.conf’

# 故障转移配置
failover_command = ‘/etc/pgpool-II/failover.sh’

# 创建故障转移脚本
$ sudo vi /etc/pgpool-II/failover.sh
#!/bin/bash
# failover.sh
# from:www.itpux.com.qq113257174.wx:itpux-com
# web: `http://www.fgedu.net.cn`

PGHOME=/postgresql/fgapp
LOGFILE=/var/log/pgpool/failover.log
echo “Failover started at $(date)” >> $LOGFILE

# 故障转移逻辑
echo “Failed node: $1” >> $LOGFILE
echo “New primary: $2” >> $LOGFILE

# 启动PgPool-II
$ sudo systemctl start pgpool-II
$ sudo systemctl enable pgpool-II

# 验证PgPool-II状态
$ sudo systemctl status pgpool-II

3.3 故障转移配置

3.3.1 配置自动故障转移

# 配置Repmgr
$ sudo yum install repmgr18

# 配置主节点
$ sudo vi /etc/repmgr.conf

node_id=1
node_name=’node1′
conninfo=’host=192.168.1.10 port=5432 user=repmgr dbname=repmgr’
data_directory=’/postgresql/fgdata’

# 创建repmgr数据库
$ psql -U postgres -c “CREATE DATABASE repmgr;”
$ psql -U postgres -c “CREATE USER repmgr SUPERUSER LOGIN PASSWORD ‘password’;”
$ psql -U postgres -d repmgr -c “CREATE EXTENSION repmgr;”

# 注册主节点
$ repmgr -f /etc/repmgr.conf primary register

# 配置从节点
$ sudo vi /etc/repmgr.conf

node_id=2
node_name=’node2′
conninfo=’host=192.168.1.11 port=5432 user=repmgr dbname=repmgr’
data_directory=’/postgresql/fgdata’

# 注册从节点
$ repmgr -f /etc/repmgr.conf standby clone –primary-host=192.168.1.10 –primary-user=repmgr
$ repmgr -f /etc/repmgr.conf standby register

# 验证集群状态
$ repmgr -f /etc/repmgr.conf cluster show
ID | Name | Role | Status | Upstream | Location | Priority | Timeline | Connection string
—-+——-+———+———–+———-+———-+———-+———-+————————————————————————————
1 | node1 | primary | * running | | default | 100 | 1 | host=192.168.1.10 port=5432 user=repmgr dbname=repmgr
2 | node2 | standby | running | node1 | default | 100 | 1 | host=192.168.1.11 port=5432 user=repmgr dbname=repmgr

风哥提示：配置自动故障转移是确保高可用集群可靠性的关键，需要仔细配置和测试。学习交流加群风哥QQ113257174

Part04-生产案例与实战讲解

4.1 主从复制案例

4.1.1 主从复制配置实战

# 主从复制配置实战

# 1. 配置主节点
$ sudo vi /postgresql/fgdata/postgresql.conf

listen_addresses = ‘*’
max_wal_senders = 10
wal_level = replica
max_replication_slots = 10
hot_standby = on

$ sudo systemctl restart postgresql

# 2. 创建复制用户
$ psql -U postgres -c “CREATE ROLE replicator REPLICATION LOGIN PASSWORD ‘password’;”

# 3. 配置pg_hba.conf
$ sudo vi /postgresql/fgdata/pg_hba.conf
host replication replicator 192.168.1.11/32 md5

$ sudo systemctl restart postgresql

# 4. 配置从节点
$ sudo systemctl stop postgresql
$ sudo rm -rf /postgresql/fgdata/*
$ pg_basebackup -h 192.168.1.10 -U replicator -D /postgresql/fgdata -F p -X stream -P

# 5. 创建recovery.conf
$ sudo vi /postgresql/fgdata/recovery.conf
standby_mode = ‘on’
primary_conninfo = ‘host=192.168.1.10 port=5432 user=replicator password=password’
trigger_file = ‘/postgresql/fgdata/trigger_file’

$ sudo systemctl start postgresql

# 6. 验证复制状态
# 在主节点上
$ psql -U postgres -c “SELECT * FROM pg_stat_replication;”
pid | usesysid | usename | fgapplication_name | client_addr | client_hostname | client_port | backend_start | backend_xmin | state | sent_lsn | write_lsn | flush_lsn | replay_lsn | write_lag | flush_lag | replay_lag | sync_priority | sync_state
——+———-+————+——————+————-+—————–+————-+—————+————–+——-+———–+———–+———–+————+———–+———–+————+—————+————
1234 | 16385 | replicator | walreceiver | 192.168.1.11 | | 54321 | 2026-04-06 10:00:00+00 | | streaming | 0/12345678 | 0/12345678 | 0/12345678 | 0/12345678 | | | | 0 | async

# 在从节点上
$ psql -U postgres -c “SELECT pg_is_in_recovery();”
pg_is_in_recovery
——————-
t

$ psql -U postgres -c “SELECT * FROM pg_stat_wal_receiver;”
pid | status | receive_start_lsn | receive_start_tli | received_lsn | received_tli | last_msg_send_time | last_msg_receipt_time | latest_end_lsn | latest_end_time | slot_name | sender_host | sender_port | sender_pid
——+——–+——————-+——————-+————-+————-+———————+———————–+—————-+——————+———–+————-+————-+————
5678 | streaming | 0/12345678 | 1 | 0/12345678 | 1 | 2026-04-06 10:01:00+00 | 2026-04-06 10:01:00+00 | 0/12345678 | 2026-04-06 10:01:00+00 | | 192.168.1.10 | 5432 | 1234

4.2 PgPool-II高可用案例

4.2.1 PgPool-II高可用配置

# PgPool-II高可用配置

# 1. 安装PgPool-II
$ sudo yum install epel-release
$ sudo yum install pgpool-II-pg18

# 2. 配置PgPool-II
$ sudo vi /etc/pgpool-II/pgpool.conf

listen_addresses = ‘*’
port = 9999

backend_hostname0 = ‘192.168.1.10’
backend_port0 = 5432
backend_weight0 = 1
backend_data_directory0 = ‘/postgresql/fgdata’
backend_flag0 = ‘ALLOW_TO_FAILOVER’

backend_hostname1 = ‘192.168.1.11’
backend_port1 = 5432
backend_weight1 = 1
backend_data_directory1 = ‘/postgresql/fgdata’
backend_flag1 = ‘ALLOW_TO_FAILOVER’

load_balance_mode = on
connection_cache = on
max_pool = 4
num_init_children = 64
max_connections = 200

# 3. 配置认证
$ sudo vi /etc/pgpool-II/pool_hba.conf
host all all 0.0.0.0/0 md5

# 4. 启动PgPool-II
$ sudo systemctl start pgpool-II
$ sudo systemctl enable pgpool-II

# 5. 验证PgPool-II状态
$ sudo systemctl status pgpool-II

# 6. 测试负载均衡
$ for i in {1..10}; do psql -h 192.168.1.13 -p 9999 -U fgedu -d fgedudb -c “SELECT inet_server_addr();”; done
inet_server_addr
——————
192.168.1.10
192.168.1.11
192.168.1.10
192.168.1.11
192.168.1.10
192.168.1.11
192.168.1.10
192.168.1.11
192.168.1.10
192.168.1.11

4.3 故障转移案例

4.3.1 故障转移测试

# 故障转移测试

# 1. 模拟主节点故障
$ sudo systemctl stop postgresql

# 2. 查看故障转移过程
$ tail -f /var/log/pgpool/pgpool.log
2026-04-06 10:05:00 UTC LOG: watchdog: Node 192.168.1.10:5432 is down
2026-04-06 10:05:01 UTC LOG: failover: starting failover
2026-04-06 10:05:02 UTC LOG: failover: selecting a new primary node
2026-04-06 10:05:03 UTC LOG: failover: new primary is 192.168.1.11:5432
2026-04-06 10:05:04 UTC LOG: failover: executing failover command: /etc/pgpool-II/failover.sh 0 1
2026-04-06 10:05:05 UTC LOG: failover: failover command completed successfully
2026-04-06 10:05:06 UTC LOG: failover: updating backend information
2026-04-06 10:05:07 UTC LOG: failover: failover completed successfully

# 3. 验证新主节点
$ psql -h 192.168.1.11 -U fgedu -d fgedudb -c “SELECT pg_is_in_recovery();”
pg_is_in_recovery
——————-
f

# 4. 重新加入原主节点
$ sudo systemctl start postgresql
$ repmgr -f /etc/repmgr.conf standby follow

# 5. 验证集群状态
$ repmgr -f /etc/repmgr.conf cluster show
ID | Name | Role | Status | Upstream | Location | Priority | Timeline | Connection string
—-+——-+———+———–+———-+———-+———-+———-+————————————————————————————
1 | node1 | standby | running | node2 | default | 100 | 2 | host=192.168.1.10 port=5432 user=repmgr dbname=repmgr
2 | node2 | primary | * running | | default | 100 | 2 | host=192.168.1.11 port=5432 user=repmgr dbname=repmgr

风哥教程针对风哥教程针对风哥教程针对生产环境建议：定期测试故障转移流程，确保在主节点故障时能够自动切换到从节点，减少服务中断时间。更多学习教程公众号风哥教程itpux_com

Part05-风哥经验总结与分享

5.1 高可用配置最佳实践

PostgreSQL高可用配置的最佳实践：

  • 合理规划：根据业务需求和资源情况，设计合理的高可用架构
  • 多节点部署：部署多个节点，避免单点故障
  • 网络隔离：确保节点之间的网络连接可靠
  • 存储冗余：使用RAID等技术提高存储可靠性
  • 监控完善：建立完善的监控系统，及时发现问题
  • 定期测试：定期测试故障转移流程，确保系统可靠性
  • 文档化：记录高可用配置和故障处理流程
  • 培训准备：对运维人员进行培训，确保能够处理故障

5.2 风哥经验分享

风哥提示：在多年的PostgreSQL管理经验中，我发现高可用配置是确保业务连续性的关键。以下是我的几点经验：

1. 架构设计要合理：根据业务需求选择合适的高可用架构，避免过度设计或设计不足
2. 节点分布要分散：将节点分布在不同的物理位置，避免单点故障
3. 监控系统要完善：建立实时监控系统，及时发现和解决问题
4. 故障转移要测试：定期测试故障转移流程，确保在故障时能够快速切换
5. 备份策略要结合：高可用和备份策略相结合，确保数据安全
6. 运维流程要规范：建立规范的运维流程，确保系统的可靠性

通过合理的高可用配置，可以显著提高系统的可靠性和可用性，为业务提供更好的支持。from PostgreSQL视频:www.itpux.com

5.3 常见问题与解决方案

PostgreSQL高可用集群常见问题与解决方案：

# 常见问题1：复制延迟
症状：从节点数据与主节点数据存在延迟
解决方案：
– 检查网络连接是否正常
– 检查主节点负载是否过高
– 调整复制参数，如wal_sender_timeout
– 考虑使用更快的存储设备

# 常见问题2：故障转移失败
症状：主节点故障后，无法自动故障转移到从节点
解决方案：
– 检查故障转移脚本是否正确配置
– 检查从节点状态是否正常
– 检查网络连接是否正常
– 验证repmgr或PgPool-II配置是否正确

# 常见问题3：脑裂
症状：集群中出现多个主节点
解决方案：
– 配置仲裁机制
– 使用STONITH（Shoot The Other Node In The Head）
– 确保网络连接可靠
– 配置合理的心跳检测

# 常见问题4：性能下降
症状：高可用集群性能低于单节点
解决方案：
– 优化PgPool-II配置
– 合理分配读写请求
– 确保网络带宽充足
– 考虑使用更快的存储设备

# 常见问题5：监控失效
症状：监控系统无法及时发现故障
解决方案：
– 配置多维度监控
– 确保监控系统自身的高可用
– 设置合理的告警阈值
– 定期测试监控系统

持续改进：高可用配置是一个持续优化的过程，需要根据业务需求和系统状态不断调整。建议建立高可用管理的标准流程，定期评估和优化高可用架构，以适应业务发展的需要。

本文由风哥教程整理发布,仅用于学习测试使用,转载注明出处:http://www.fgedu.net.cn/10327.html

相关推荐

联系我们

在线咨询：点击这里给我发消息

微信号：itpux-com

工作日：9:30-18:30，节假日休息