企业官网建设流程全解析

1. 项目概述：PG一主二从三鉴证架构解析

这个标题描述的是一个基于PostgreSQL（简称PG）的高可用数据库集群架构，采用repmgr作为复制管理工具。所谓"一主二从三鉴证"指的是：1个主库（Primary）、2个从库（Standby）和3个见证节点（Witness）组成的分布式数据库系统。这种架构在金融、电信等行业的核心业务系统中较为常见，能够同时满足数据高可用和读写分离的需求。

我在某银行核心系统升级项目中首次接触这种配置，当时需要实现全年99.99%的可用性目标。经过压力测试验证，这种架构在单机房故障时能实现30秒内自动切换，双机房故障时通过见证节点仲裁仍可维持服务。下面我会结合具体实施案例，拆解这套架构的每个技术环节。

2. 核心组件选型与原理

2.1 PostgreSQL版本选择

推荐使用PG 12及以上版本，主要考虑以下因素：

• 逻辑复制功能成熟（PG 10+）
• 声明式分区表性能优化（PG 11+）
• 增量备份性能提升（PG 12+）
• 并行查询增强（PG 13+）

我们在生产环境使用PG 13.4版本，该版本修复了之前版本中出现的WAL重放卡顿问题。特别提醒：不要盲目追求最新版本，建议选择次新的大版本（当前最新是PG 15，生产环境建议用PG 14）。

2.2 repmgr工具解析

repmgr是PG生态中最成熟的复制管理工具，主要功能包括：

• 自动故障检测与切换
• 节点角色管理
• 集群监控与可视化
• 配置同步维护

与Patroni等工具相比，repmgr的优势在于：

1. 轻量级，不依赖外部组件（如Etcd）
2. 配置简单，学习曲线平缓
3. 对PG原生复制支持更好

最新版repmgr 5.3新增了自动重建失效节点的功能，这在维护大型集群时非常实用。

3. 集群架构详细设计

3.1 网络拓扑规划

典型的三机房部署方案：

机房A：主库 + 见证节点 机房B：从库1 + 见证节点 机房C：从库2 + 见证节点

网络延迟要求：

• 节点间延迟 < 5ms（建议2ms内）
• 带宽 >= 1Gbps（建议10Gbps）

我们在实际部署时遇到过因跨机房延迟过高导致的复制延迟问题，后来通过调整TCP内核参数解决：

# /etc/sysctl.conf 调优 net.ipv4.tcp_slow_start_after_idle = 0 net.core.rmem_max = 16777216 net.core.wmem_max = 16777216

3.2 硬件资源配置

主库配置建议：

• CPU：16核以上（OLTP场景）
• 内存：数据热集的1.2倍
• 存储：RAID10 SSD（建议NVMe）

从库可以适当降低配置，但需注意：

• 只读查询可能消耗大量CPU
• 分析型查询需要足够内存
• 备库必须预留WAL存储空间

见证节点最低配置：

• 1核CPU
• 1GB内存
• 10GB存储

4. 详细配置实施步骤

4.1 基础环境准备

所有节点需要：

1. 统一时区（建议UTC）
2. 禁用SELinux
3. 配置SSH互信
4. 安装相同版本的PG和repmgr

推荐使用Ansible进行批量配置，以下为关键playbook片段：

- name: Install PostgreSQL yum: name: "postgresql13-server" state: present - name: Create pgdata directory file: path: "/var/lib/pgsql/13/data" state: directory owner: postgres group: postgres

4.2 PostgreSQL核心配置

postgresql.conf关键参数：

# 主库专用配置 wal_level = replica max_wal_senders = 10 hot_standby = on # 所有节点通用 max_connections = 500 shared_buffers = 8GB work_mem = 16MB maintenance_work_mem = 256MB

pg_hba.conf复制授权：

host replication repmgr 192.168.1.0/24 trust host replication postgres 192.168.1.0/24 trust

4.3 repmgr配置详解

repmgr.conf主库配置示例：

node_id=1 node_name='node1' conninfo='host=node1 dbname=repmgr user=repmgr connect_timeout=2' data_directory='/var/lib/pgsql/13/data' failover=automatic promote_command='repmgr standby promote -f /etc/repmgr.conf' follow_command='repmgr standby follow -f /etc/repmgr.conf'

见证节点特殊配置：

node_id=4 node_name='witness1' conninfo='host=witness1 dbname=repmgr user=repmgr' data_directory='/var/lib/pgsql/13/data' witness=on

5. 集群部署实操流程

5.1 初始主库搭建

1. 初始化数据库：

sudo postgresql-13-setup initdb

2. 启动服务并创建复制用户：

CREATE USER repmgr WITH SUPERUSER REPLICATION; CREATE DATABASE repmgr OWNER repmgr;

3. 注册主节点：

repmgr primary register -f /etc/repmgr.conf

5.2 从库部署步骤

1. 克隆主库数据：

repmgr standby clone -h node1 -U repmgr -d repmgr \ --recovery-conf-only -f /etc/repmgr.conf

2. 启动从库并注册：

pg_ctl start -D /var/lib/pgsql/13/data repmgr standby register -f /etc/repmgr.conf

3. 验证复制状态：

SELECT * FROM pg_stat_replication;

5.3 见证节点配置

1. 创建空数据目录：

mkdir -p /var/lib/pgsql/13/data chown postgres:postgres /var/lib/pgsql/13/data

2. 注册见证节点：

repmgr witness register -h node1 -f /etc/repmgr.conf

3. 启动见证服务：

repmgrd -d -f /etc/repmgr.conf

6. 运维管理与故障处理

6.1 日常监控命令

查看集群状态：

repmgr cluster show

检查复制延迟：

SELECT now() - pg_last_xact_replay_timestamp() AS replication_lag;

监控工具推荐：

• pgMonitor（开源方案）
• Prometheus + Grafana（自定义监控）

6.2 常见故障处理

场景1：主库宕机自动切换

处理流程：

1. repmgrd检测到主库不可达
2. 触发选举新主库（需至少1个见证节点确认）
3. 剩余从库自动指向新主库

手动干预命令：

repmgr standby switchover -f /etc/repmgr.conf

场景2：脑裂问题处理

症状：出现两个主库 解决方法：

1. 停掉错误的主库
2. 在正确的主库执行：

repmgr standby follow -f /etc/repmgr.conf

6.3 备份恢复策略

物理备份方案：

# 基础备份 pg_basebackup -h node1 -U repmgr -D /backup/pg -Ft -Xs -P # WAL归档配置 archive_mode = on archive_command = 'rsync -a %p backup_server:/wal_archive/%f'

时间点恢复示例：

pg_restore -j 4 -C -d postgres /backup/pg/base.tar cp /wal_archive/* /pg_wal/ touch /var/lib/pgsql/13/data/recovery.signal

7. 性能优化实践

7.1 复制性能调优

关键参数调整：

max_wal_senders = 10 wal_keep_size = 10GB max_slot_wal_keep_size = 20GB synchronous_commit = remote_apply

监控复制延迟：

SELECT client_addr, state, pg_wal_lsn_diff(sent_lsn, write_lsn) AS write_lag, pg_wal_lsn_diff(sent_lsn, flush_lsn) AS flush_lag, pg_wal_lsn_diff(sent_lsn, replay_lsn) AS replay_lag FROM pg_stat_replication;

7.2 查询负载均衡

读写分离配置：

# 在从库设置 hot_standby_feedback = on max_standby_streaming_delay = 30s

应用层路由策略：

• 写操作直连主库
• 读操作轮询从库
• 关键读操作可指定主库

7.3 连接池配置

推荐使用pgbouncer配置：

[databases] mydb = host=node1 port=5432 dbname=mydb [pgbouncer] pool_mode = transaction max_client_conn = 1000 default_pool_size = 50

8. 安全加固措施

8.1 网络层安全

推荐配置：

• 使用SSL加密复制连接
• 限制管理网络访问
• 启用防火墙规则

ssl配置示例：

# postgresql.conf ssl = on ssl_cert_file = '/etc/ssl/certs/server.crt' ssl_key_file = '/etc/ssl/private/server.key' # pg_hba.conf hostssl all all 192.168.1.0/24 scram-sha-256

8.2 审计日志配置

logging_collector = on log_directory = 'pg_log' log_filename = 'postgresql-%Y-%m-%d.log' log_connections = on log_disconnections = on log_statement = 'ddl'

8.3 定期维护任务

推荐crontab任务：

# 每天凌晨清理旧日志 0 2 * * * find /var/lib/pgsql/13/data/pg_log -mtime +30 -delete # 每周分析所有数据库 0 3 * * 0 vacuumdb -a -z

这套架构我们已经稳定运行3年多，经历过多次硬件故障和机房网络中断的考验。最严重的一次是主库SSD阵列损坏，系统在28秒内完成了自动切换，业务几乎无感知。对于关键业务系统，这种"一主二从三鉴证"的架构确实能提供企业级的高可用保障。