2. 首页 > PostgreSQL教程 > 正文

PostgreSQL教程FG333-PostgreSQL数据库灾难恢复：企业级跨机房主从方案设计与实施

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

目录大纲

Part01-基础概念与理论知识

Part02-生产环境规划与建议

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

Part04-生产案例与实战讲解

Part05-风哥经验总结与分享

内容简介

本文章详细介绍PostgreSQL数据库的企业级灾难恢复方案，重点关注跨机房主从复制架构。风哥教程参考PostgreSQL官方文档Server
Administration部分的高可用性和复制相关内容，提供实用的灾难恢复策略和实战案例。

Part01-基础概念与理论知识

1.1 灾难恢复概述

灾难恢复是指在发生自然灾害、人为错误或系统故障等灾难事件后，恢复数据库服务的过程。企业级灾难恢复方案需要考虑以下因素：

  • 恢复时间目标（RTO）：从灾难发生到系统恢复的最大可接受时间
  • 恢复点目标（RPO）：灾难发生后可接受的数据丢失量
  • 可靠性：确保恢复过程的可靠性
  • 可测试性：定期测试灾难恢复流程

1.2 跨机房主从复制原理

PostgreSQL跨机房主从复制基于WAL（Write-Ahead Log）机制，原理如下：

  • 主库将事务写入WAL日志
  • 备库通过流式复制从主库获取WAL日志
  • 备库应用WAL日志，保持与主库数据一致
  • 跨机房复制需要考虑网络延迟和带宽

1.3 灾难恢复等级

灾难恢复等级通常分为：

  • Level 0：无灾难恢复计划
  • Level 1：本地备份，手动恢复
  • Level 2：本地热备份，自动恢复
  • Level 3：异地热备份，自动恢复
  • Level 4：多站点集群，自动故障切换

Part02-生产环境规划与建议

2.1 跨机房架构规划

跨机房架构规划包括：

  • 主机房：生产环境，处理所有读写请求
  • 备机房：灾备环境，实时复制主库数据
  • 网络连接：主备机房之间需要高速、可靠的网络连接
  • 防火墙：配置适当的防火墙规则，确保主备之间的通信

2.2 网络规划

网络规划包括：

  • 网络带宽：根据数据量和复制频率确定所需带宽
  • 网络延迟：最小化主备机房之间的网络延迟
  • 网络冗余：实施多路径网络，确保网络可靠性
  • 网络监控：实时监控网络状态，及时发现问题

2.3 存储规划

存储规划包括：

  • 存储容量：备库存储容量应不小于主库
  • 存储性能：备库存储性能应与主库相当
  • 存储冗余：实施RAID等冗余方案，提高存储可靠性
  • 存储监控：监控存储使用情况，及时预警

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

3.1 跨机房主从复制配置

# 1. 主库配置
vi /postgresql/fgdata/postgresql.conf

# 启用归档模式
archive_mode = on
archive_command = ‘cp %p /postgresql/archive/%f’
# 启用复制
wal_level = replica
max_wal_senders = 10
max_replication_slots = 10
hot_standby = on
# 2. 配置pg_hba.conf允许复制连接
vi /postgresql/fgdata/pg_hba.conf

# 允许备库连接进行复制
host replication replica 192.168.2.0/24 md5
# 3. 重启主库
systemctl restart postgresql-18

Job for postgresql-18.service restarted successfully.

# 4. 在备库上执行基础备份
pg_basebackup -h 192.168.1.100 -U replica -D /postgresql/fgdata -P -X stream

pg_basebackup: initiating base backup, waiting for checkpoint to complete
pg_basebackup: checkpoint completed
pg_basebackup: write-ahead log start point: 0/1234567
pg_basebackup: starting background WAL receiver
30000/30000 kB (100%), 1/1 tablespace
pg_basebackup: write-ahead log end point: 0/1234567
pg_basebackup: base backup completed

# 5. 在备库上创建recovery.conf文件
vi /postgresql/fgdata/recovery.conf

standby_mode = ‘on’
primary_conninfo = ‘host=192.168.1.100 port=5432 user=replica password=replica_pass’
recovery_target_timeline = ‘latest’
# 6. 启动备库
systemctl start postgresql-18

Job for postgresql-18.service started successfully.

3.2 故障切换方案

# 1. 监控主库状态
psql -h 192.168.1.100 -U postgres -c “SELECT pg_is_in_recovery();”

pg_is_in_recovery
—————–
f
(1 row)

# 2. 当主库故障时，提升备库为主库
psql -h 192.168.2.100 -U postgres -c “SELECT pg_promote();”

pg_promote
———–
t
(1 row)

# 3. 验证备库已提升为主库
psql -h 192.168.2.100 -U postgres -c “SELECT pg_is_in_recovery();”

pg_is_in_recovery
—————–
f
(1 row)

3.3 监控与告警

# 1. 监控复制延迟
psql -h 192.168.2.100 -U postgres -c “SELECT slot_name, pg_wal_lsn_diff(pg_current_wal_lsn(), restart_lsn)
AS lag_bytes FROM pg_replication_slots;”

slot_name | lag_bytes
———–+———–
replica | 0

# 2. 配置Prometheus监控
vi /etc/prometheus/prometheus.yml

scrape_configs:
– job_name: ‘postgresql’
static_configs:
– targets: [‘192.168.1.100:9187’, ‘192.168.2.100:9187’]
metrics_path: ‘/metrics’
scrape_interval: 15s

Part04-生产案例与实战讲解

4.1 跨机房主从实战案例

某企业跨机房主从复制案例：

# 1. 主库（北京机房）配置
vi /postgresql/fgdata/postgresql.conf

wal_level = replica
max_wal_senders = 5
max_replication_slots = 5
hot_standby = on
archive_mode = on
archive_command = ‘cp %p /postgresql/archive/%f’
# 2. 备库（上海机房）配置
pg_basebackup -h 10.0.0.100 -U replica -D /postgresql/fgdata -P -X stream

pg_basebackup: initiating base backup, waiting for checkpoint to complete
pg_basebackup: checkpoint completed
pg_basebackup: write-ahead log start point: 0/2345678
pg_basebackup: starting background WAL receiver
50000/50000 kB (100%), 1/1 tablespace
pg_basebackup: write-ahead log end point: 0/2345678
pg_basebackup: base backup completed

4.2 故障切换实战案例

主库故障切换案例：

# 1. 检查主库状态（北京机房）
ping 10.0.0.100

PING 10.0.0.100 (10.0.0.100) 56(84) bytes of data.
From 10.0.0.1 icmp_seq=1 Destination Host Unreachable

# 2. 提升备库为主库（上海机房）
psql -h 10.0.0.200 -U postgres -c “SELECT pg_promote();”

pg_promote
———–
t
(1 row)

# 3. 更新应用连接字符串，指向新的主库
vi /fgapp/config/database.yml

production:
adapter: postgresql
host: 10.0.0.200
port: 5432
database: fgedudb
username: fgedu
password: fgedu_pass

4.3 灾难恢复演练案例

灾难恢复演练案例：

# 1. 定期进行灾难恢复演练
# 步骤1：停止主库服务
systemctl stop postgresql-18

Job for postgresql-18.service stopped successfully.

# 步骤2：提升备库为主库
psql -h 192.168.2.100 -U postgres -c “SELECT pg_promote();”

pg_promote
———–
t
(1 row)

# 步骤3：验证新主库状态
psql -h 192.168.2.100 -U postgres -c “SELECT pg_is_in_recovery();”

pg_is_in_recovery
—————–
f
(1 row)

Part05-风哥经验总结与分享

5.1 企业级灾难恢复最佳实践

  • 实施跨机房主从复制，确保数据安全
  • 定期进行灾难恢复演练，验证恢复流程
  • 监控复制延迟，及时发现问题
  • 建立完善的故障切换流程和文档
  • 考虑使用自动化工具（如Patroni）管理高可用

5.2 灾难恢复维护建议

  • 定期检查主备库状态，确保复制正常
  • 监控存储使用情况，避免空间不足
  • 定期备份WAL日志，确保可以进行PITR恢复
  • 更新复制用户密码，提高安全性
  • 测试备份的有效性，确保可以恢复

5.3 灾难恢复演练策略

灾难恢复演练策略：

  1. 制定演练计划：明确演练目标、步骤和时间
  2. 通知相关人员：提前通知所有相关人员
  3. 执行演练：按照计划执行故障切换
  4. 记录演练过程：详细记录演练中的问题和解决方法
  5. 评估演练结果：分析演练效果，找出改进点
  6. 更新演练计划：根据演练结果更新演练计划
风哥提示：灾难恢复是企业级数据库架构的重要组成部分，需要定期测试和更新，确保在真正的灾难发生时能够快速恢复服务。

更多视频教程www.fgedu.net.cn

学习交流加群风哥微信: itpux-com

学习交流加群风哥QQ113257174

更多学习教程公众号风哥教程itpux_com

from PostgreSQL视频:www.itpux.com

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

相关推荐

联系我们

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

微信号：itpux-com

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