PostgreSQL 灾备演练规范

核心概念

灾备演练是验证数据库灾难恢复能力的重要手段，涉及以下几个关键概念：

灾备演练：模拟各种灾难场景，测试数据库从故障中恢复的能力
故障切换测试：测试主备数据库之间的切换过程和效果
恢复时间目标（RTO）：系统从故障恢复到正常运行的最大可接受时间
恢复点目标（RPO）：故障发生后可容忍的数据丢失量
演练类型：全流程演练、部分流程演练、模拟演练

演练准备

1. 演练计划制定

演练目标：

验证RTO和RPO是否符合业务要求
测试灾备系统的可靠性和稳定性
评估运维团队的应急响应能力
发现灾备方案中的薄弱环节

演练范围：

涉及的数据库实例
演练的灾难场景
参与的人员和部门
演练的时间窗口

演练计划模板：

项目	内容
演练名称	PostgreSQL 灾备演练（2023年度）
演练目标	验证主备切换、PITR恢复、跨区域灾备等能力
演练时间	2023年12月15日 00:00-04:00
参与人员	DBA团队、运维团队、业务团队
演练场景	1. 主库硬件故障 2. 误删除数据 3. 跨区域灾备切换
回滚方案	1. 主备切换回滚 2. 数据恢复回滚 3. 服务切换回滚

2. 环境准备

演练环境：

生产环境的灾备系统
测试环境（用于预演）
监控系统（用于实时监控演练过程）

准备工作：

bash

# 1. 备份当前配置
cp /etc/postgresql/14/main/postgresql.conf /etc/postgresql/14/main/postgresql.conf.drill.bak
cp /etc/postgresql/14/main/pg_hba.conf /etc/postgresql/14/main/pg_hba.conf.drill.bak

# 2. 检查灾备状态
psql -c "SELECT * FROM pg_stat_replication;"
psql -c "SELECT pg_last_wal_receive_lsn(), pg_last_wal_replay_lsn();"

# 3. 准备测试数据
psql -c "CREATE TABLE drill_test (id serial PRIMARY KEY, name varchar(50), created_at timestamp DEFAULT now());"
psql -c "INSERT INTO drill_test (name) VALUES ('test1'), ('test2'), ('test3');"

3. 人员准备

角色与职责：

演练负责人：负责整体演练的组织和协调
DBA团队：负责数据库层面的演练操作
运维团队：负责基础设施和网络层面的支持
业务团队：负责业务验证和测试
监控人员：负责实时监控演练过程中的系统状态

演练流程

1. 主备切换演练

场景：主数据库服务器硬件故障，需要切换到备库

执行步骤：

bash

# 1. 模拟主库故障
# 在主库上执行
pg_ctl -D /data/postgres stop -m immediate

# 2. 验证主库故障
psql -h master_host -U postgres -c "SELECT now();" || echo "主库不可用"

# 3. 提升备库为主库
# 在备库上执行
pg_ctl -D /data/postgres promote

# 4. 验证备库提升成功
psql -h standby_host -U postgres -c "SELECT pg_is_in_recovery();"  # 应返回f

# 5. 更新应用连接配置
# 修改应用的数据库连接字符串，指向新的主库

# 6. 验证业务连续性
psql -h standby_host -U postgres -c "INSERT INTO drill_test (name) VALUES ('drill_test');"
psql -h standby_host -U postgres -c "SELECT count(*) FROM drill_test;"  # 应返回4

# 7. 重新配置新的备库
# 在新的主库上执行
pg_basebackup -h standby_host -U replicator -D /data/postgres_new_standby -Fp -Xs -z -P -R

# 8. 启动新的备库
pg_ctl -D /data/postgres_new_standby start

# 9. 验证新的主备关系
psql -h standby_host -U postgres -c "SELECT * FROM pg_stat_replication;"

2. PITR恢复演练

场景：误删除了重要业务表，需要使用PITR恢复到误操作前的时间点

执行步骤：

bash

# 1. 记录当前时间和事务ID
psql -c "SELECT now(), txid_current();"

# 2. 模拟误删除操作
psql -c "DROP TABLE important_table;"

# 3. 立即停止数据库写入（可选，用于最小化数据丢失）
pghba_conf="/etc/postgresql/14/main/pg_hba.conf"
echo "# Temporarily block writes" >> $pghba_conf
echo "host all all 0.0.0.0/0 reject" >> $pghba_conf
pg_ctl -D /data/postgres reload

# 4. 确定恢复时间点
# 找到误删除操作前的时间点
recovery_time="2023-12-15 10:30:00+08"

# 5. 执行PITR恢复
# 停止数据库
pg_ctl -D /data/postgres stop -m fast

# 清理数据目录
rm -rf /data/postgres/*

# 恢复基础备份
pg_basebackup -h backup_server -U replicator -D /data/postgres -Fp -Xs -z -P

# 创建recovery.conf文件
cat > /data/postgres/recovery.conf << EOF
restore_command = 'cp /backup/wal/%f %p'
recovery_target_time = '$recovery_time'
recovery_target_inclusive = false
EOF

# 启动数据库
pg_ctl -D /data/postgres start

# 6. 验证恢复结果
psql -c "SELECT * FROM important_table LIMIT 10;"  # 表应被恢复

# 7. 恢复正常运行
# 恢复pg_hba.conf
cp /etc/postgresql/14/main/pg_hba.conf.drill.bak /etc/postgresql/14/main/pg_hba.conf
pg_ctl -D /data/postgres reload

3. 跨区域灾备演练

场景：主区域发生自然灾害，需要切换到跨区域的灾备中心

执行步骤：

bash

# 1. 模拟主区域故障
# 断开主区域与灾备区域的网络连接

# 2. 验证主区域不可用
ping -c 3 master_region_host || echo "主区域不可达"

# 3. 激活跨区域灾备库
# 在跨区域灾备库上执行
pg_ctl -D /data/postgres promote

# 4. 更新DNS或负载均衡配置
# 将业务流量导向跨区域灾备库

# 5. 验证跨区域服务可用性
psql -h cross_region_host -U postgres -c "SELECT now();"
psql -h cross_region_host -U postgres -c "INSERT INTO drill_test (name) VALUES ('cross_region_test');"

# 6. 验证数据一致性
# 比较跨区域灾备库与预期数据的一致性
psql -h cross_region_host -U postgres -c "SELECT count(*) FROM important_table;"  # 应与预期一致

演练评估

1. 评估指标

RTO和RPO验证：

实际RTO：从故障发生到系统恢复正常运行的时间
实际RPO：故障发生后实际丢失的数据量
与目标值的偏差：实际值与目标值的差异百分比

系统性能：

恢复后的数据库性能指标
资源使用率（CPU、内存、I/O）
响应时间

操作准确性：

演练步骤的执行准确性
命令的正确性
回滚操作的准确性

2. 评估报告

报告模板：

项目	目标值	实际值	偏差	结论
RTO	≤ 30分钟	25分钟	-5分钟	达标
RPO	≤ 5分钟	3分钟	-2分钟	达标
主备切换成功率	100%	100%	0%	达标
PITR恢复成功率	100%	100%	0%	达标
跨区域切换成功率	100%	100%	0%	达标

问题记录与改进：

问题描述	影响	根本原因	改进措施
主备切换过程中监控告警延迟	延长了故障发现时间	监控系统配置问题	调整监控告警阈值和通知机制
PITR恢复时间较长	超过了预期RTO	存储I/O性能瓶颈	升级存储设备，优化恢复流程

最佳实践

1. 生产环境演练建议

定期演练：至少每季度进行一次完整的灾备演练
多样化场景：覆盖不同类型的灾难场景
逐步扩大范围：从测试环境到生产环境，从部分流程到全流程
文档化：详细记录演练过程和结果
培训与分享：定期组织培训，分享演练经验
持续改进：根据演练结果持续优化灾备方案

2. 常见问题处理

问题1：演练过程中出现意外故障 解决方法：立即启动回滚方案，恢复系统到演练前状态
问题2：演练时间超过预期 解决方法：分析超时原因，优化演练流程，调整时间窗口
问题3：演练结果不符合预期 解决方法：深入分析根本原因，调整灾备方案，重新进行演练

常见问题（FAQ）

Q1：如何确定合适的演练频率？

A1：根据业务重要性和系统变化频率确定：

核心业务系统：每季度至少一次
重要业务系统：每半年至少一次
一般业务系统：每年至少一次
系统发生重大变更后：立即进行一次演练

Q2：演练会影响生产业务吗？

A2：合理规划的演练不会影响生产业务：

选择业务低峰期进行演练
使用在线切换方式（如PostgreSQL的switchover）
提前通知业务部门，做好应急预案
在测试环境进行预演

Q3：如何准备有效的回滚方案？

A3：回滚方案应包括：

详细的回滚步骤和命令
回滚所需的资源和工具
回滚的时间窗口和影响范围
回滚后的验证方法
回滚责任人和联系方式

Q4：演练结束后需要做哪些工作？

A4：演练结束后应：

恢复系统到正常状态
清理演练过程中产生的测试数据
收集和整理演练日志和监控数据
召开演练总结会议
编写演练报告
制定改进计划

Q5：如何评估演练的有效性？

A5：从以下几个方面评估：

RTO和RPO是否符合目标
演练步骤的执行是否顺畅
参与人员的响应是否及时
系统恢复后的性能是否正常
业务验证是否通过
是否发现了灾备方案中的薄弱环节

PostgreSQL 灾备演练规范 ​

核心概念 ​

演练准备 ​

1. 演练计划制定 ​

2. 环境准备 ​

3. 人员准备 ​

演练流程 ​

1. 主备切换演练 ​

2. PITR恢复演练 ​

3. 跨区域灾备演练 ​

演练评估 ​

1. 评估指标 ​

2. 评估报告 ​

最佳实践 ​

1. 生产环境演练建议 ​

2. 常见问题处理 ​

常见问题（FAQ） ​

Q1：如何确定合适的演练频率？ ​

Q2：演练会影响生产业务吗？ ​

Q3：如何准备有效的回滚方案？ ​

Q4：演练结束后需要做哪些工作？ ​

Q5：如何评估演练的有效性？ ​

PostgreSQL 灾备演练规范

核心概念

演练准备

1. 演练计划制定

2. 环境准备

3. 人员准备

演练流程

1. 主备切换演练

2. PITR恢复演练

3. 跨区域灾备演练

演练评估

1. 评估指标

2. 评估报告

最佳实践

1. 生产环境演练建议

2. 常见问题处理

常见问题（FAQ）

Q1：如何确定合适的演练频率？

Q2：演练会影响生产业务吗？

Q3：如何准备有效的回滚方案？

Q4：演练结束后需要做哪些工作？

Q5：如何评估演练的有效性？