PostgreSQL 应急计划制定

应急计划概述

PostgreSQL应急计划是数据库运维的重要组成部分，用于指导DBA在发生数据库故障或灾难时，快速、有序地进行响应和恢复，最大限度地减少数据丢失和业务中断时间。

应急计划的重要性

减少业务中断：快速响应和恢复可以降低故障对业务的影响
保护数据安全：确保数据完整性和可用性
提高团队协作：明确的角色和职责可以提高故障处理效率
符合合规要求：许多行业法规要求制定和测试应急计划
降低恢复成本：提前准备可以减少恢复过程中的资源消耗

应急计划的组成部分

1. 应急团队组织架构

团队角色与职责

角色	职责
应急总指挥	负责整体协调和决策，批准重大操作
DBA负责人	领导DBA团队进行故障诊断和恢复
系统管理员	负责服务器和基础设施的支持
网络管理员	负责网络连接和防火墙配置
应用开发人员	负责应用程序相关的故障诊断和恢复
业务代表	评估故障对业务的影响，提供业务优先级
沟通协调员	负责内部和外部沟通，发布故障信息

联系方式与备用联系方式

角色	姓名	电话	邮箱	备用联系方式
应急总指挥	张三	13800138000	zhangsan@example.com	13900139000
DBA负责人	李四	13700137000	lisi@example.com	13600136000

2. 风险评估与优先级

常见故障类型与影响

故障类型	发生概率	影响范围	恢复时间	优先级
数据库崩溃	中	全部业务	30分钟-2小时	高
WAL损坏	低	全部业务	2-4小时	高
复制延迟	高	只读业务	10分钟-1小时	中
慢查询风暴	中	全部业务	15分钟-1小时	中
磁盘空间不足	高	写入业务	30分钟-2小时	中
连接数超限	中	新连接	5-30分钟	低

数据分类与保护级别

数据类型	保护级别	备份频率	恢复时间目标(RTO)	恢复点目标(RPO)
核心业务数据	最高	每日全量+每小时增量	30分钟	15分钟
重要业务数据	高	每日全量+每4小时增量	1小时	1小时
一般业务数据	中	每日全量	2小时	4小时
日志数据	低	每日归档	4小时	8小时

3. 应急响应流程

故障检测与报告

自动检测：
- 监控工具（Prometheus + Grafana）检测到异常
- 告警系统发送告警信息（邮件、短信、电话）
- 告警信息包含故障类型、发生时间、影响范围等
人工报告：
- 业务用户或应用管理员报告故障
- 报告人提供故障现象、影响范围、发生时间等信息
- 沟通协调员记录故障信息

故障分类与评估

初步分类：
- 根据故障现象和告警信息，初步判断故障类型
- 确定故障影响范围和严重程度
- 通知相关团队成员
详细评估：
- DBA团队进行故障诊断
- 确定故障根本原因
- 评估恢复时间和数据丢失风险
- 制定恢复方案

恢复方案制定与批准

方案制定：
- 根据故障类型和影响范围，制定恢复方案
- 考虑多种恢复选项，评估每种选项的优缺点
- 确定恢复步骤和所需资源
方案批准：
- 恢复方案提交给应急总指挥批准
- 重大恢复操作需要业务代表确认
- 记录批准信息和决策过程

恢复执行与验证

恢复执行：
- 按照恢复方案执行恢复操作
- 记录恢复过程中的关键步骤和时间
- 遇到问题及时调整方案
恢复验证：
- 验证数据库服务是否正常启动
- 检查数据完整性和一致性
- 验证应用程序是否能正常访问数据库
- 执行基本的功能测试

故障关闭与总结

故障关闭：
- 恢复完成后，关闭故障事件
- 通知相关方故障已解决
- 更新监控系统状态
故障总结：
- 召开故障分析会议
- 记录故障根本原因、恢复过程和经验教训
- 提出改进措施

4. 资源准备

硬件资源

资源类型	数量	配置	用途	存放位置
备用服务器	2	8核16G 500G SSD	数据库恢复和测试	机房A备用区域
存储设备	1	1TB SSD	临时数据存储	机房A存储区域
网络设备	1	千兆交换机	备用网络连接	机房A网络机柜

软件资源

软件类型	版本	用途	存储位置
PostgreSQL	14.5	数据库软件	备份服务器
pgAdmin	6.18	数据库管理工具	备份服务器
pgBadger	12.0	日志分析工具	备份服务器
监控工具	Prometheus 2.37 + Grafana 9.0	监控和告警	监控服务器

文档资源

文档类型	版本	用途	存储位置
数据库架构图	2023-01-01	了解数据库架构	内部文档系统
备份恢复手册	2023-01-01	指导备份和恢复操作	内部文档系统
应急计划	2023-01-01	指导故障响应	内部文档系统
配置文件	2023-01-01	数据库和服务器配置	备份服务器

外部资源

资源类型	联系方式	响应时间	用途
硬件供应商	400-123-4567	4小时	硬件故障维修
云服务提供商	400-789-0123	24/7	云资源支持
外部DBA顾问	13800138000	2小时	复杂故障咨询

5. 恢复策略与方案

数据库崩溃恢复

场景：数据库进程异常终止或服务器崩溃

恢复步骤：

检查故障原因：

bash

# 查看数据库日志
tail -n 100 /var/lib/postgresql/14/main/log/postgresql-$(date +%Y-%m-%d)_000000.log

# 检查系统日志
tail -n 100 /var/log/syslog
tail -n 100 /var/log/messages

尝试重启数据库：

bash

systemctl start postgresql-14

# 检查启动状态
systemctl status postgresql-14

如果重启失败，使用基础备份恢复：

bash

# 停止数据库服务
systemctl stop postgresql-14

# 清理数据目录
rm -rf /var/lib/postgresql/14/main/*

# 恢复基础备份
pg_basebackup -D /var/lib/postgresql/14/main -c fast -Fp -Xs -v -P -U replication -h backup-server

# 配置recovery.signal
touch /var/lib/postgresql/14/main/recovery.signal
echo "restore_command = 'cp /path/to/wal/archive/%f %p'" > /var/lib/postgresql/14/main/postgresql.auto.conf

# 启动数据库
systemctl start postgresql-14

验证恢复结果：

sql

-- 检查数据库状态
SELECT pg_is_in_recovery();

-- 检查数据完整性
VACUUM ANALYZE VERBOSE;

-- 检查应用连接
SELECT count(*) FROM pg_stat_activity WHERE application_name = 'app';

WAL损坏恢复

场景：WAL文件损坏导致数据库无法启动

恢复步骤：

确认WAL损坏：

bash

# 使用pg_waldump检查WAL文件
pg_waldump /var/lib/postgresql/14/main/pg_wal/000000010000000000000001

尝试使用pg_resetwal修复：

bash

# 停止数据库服务
systemctl stop postgresql-14

# 备份当前数据目录
cp -r /var/lib/postgresql/14/main /var/lib/postgresql/14/main_backup

# 使用pg_resetwal修复
pg_resetwal -D /var/lib/postgresql/14/main -f

# 启动数据库
systemctl start postgresql-14

如果修复失败，使用基础备份恢复：

bash

# 停止数据库服务
systemctl stop postgresql-14

# 清理数据目录
rm -rf /var/lib/postgresql/14/main/*

# 恢复基础备份
pg_basebackup -D /var/lib/postgresql/14/main -c fast -Fp -Xs -v -P -U replication -h backup-server

# 启动数据库
systemctl start postgresql-14

验证恢复结果：

sql

-- 检查数据库状态
SELECT version();

-- 检查数据完整性
SELECT count(*) FROM important_table;

-- 执行应用功能测试

复制延迟恢复

场景：主从复制延迟超过阈值

恢复步骤：

检查复制状态：

sql

-- 在主库查看复制状态
SELECT client_addr, state, sent_lsn, write_lsn, flush_lsn, replay_lsn, 
       pg_wal_lsn_diff(sent_lsn, replay_lsn) AS replay_delay_b
FROM pg_stat_replication;

-- 在从库查看复制状态
SELECT pg_last_wal_receive_lsn(), pg_last_wal_replay_lsn(),
       pg_last_xact_replay_timestamp(),
       now() - pg_last_xact_replay_timestamp() AS replay_lag_time;

分析延迟原因：

sql

-- 检查从库负载
SELECT * FROM pg_stat_activity WHERE state = 'active';

-- 检查从库资源使用
SELECT * FROM pg_stat_sys_memory; -- PostgreSQL 14+

-- 检查WAL生成速率
SELECT * FROM pg_stat_wal;

恢复步骤：

如果是从库性能问题：

bash

# 优化从库配置
ALTER SYSTEM SET max_worker_processes = '16';
ALTER SYSTEM SET max_parallel_workers_per_gather = '4';
SELECT pg_reload_conf();

如果是网络问题：

bash

# 检查网络连接
ping master-server
traceroute master-server

# 重启复制连接
SELECT pg_terminate_backend(pid) FROM pg_stat_replication WHERE client_addr = 'slave-ip';

如果延迟过大，重建从库：

bash

# 在从库执行
systemctl stop postgresql-14
rm -rf /var/lib/postgresql/14/main/*
pg_basebackup -D /var/lib/postgresql/14/main -c fast -Fp -Xs -v -P -U replication -h master-server
systemctl start postgresql-14

验证恢复结果：

sql

-- 检查复制延迟
SELECT pg_wal_lsn_diff(pg_last_wal_receive_lsn(), pg_last_wal_replay_lsn()) AS replay_lag_b
FROM pg_stat_replication;

-- 验证数据一致性
SELECT count(*) FROM important_table;

6. 测试与演练

测试类型与频率

测试类型	频率	测试范围	负责人
备份恢复测试	每月	全量备份恢复	DBA负责人
故障恢复演练	每季度	模拟常见故障	应急总指挥
灾难恢复演练	每年	模拟机房灾难	应急总指挥
应急计划审查	每半年	计划内容更新	DBA负责人

测试流程

测试准备：
- 确定测试目标和范围
- 准备测试环境
- 通知相关团队和业务代表
- 准备测试用例和验证脚本
测试执行：
- 按照测试计划执行测试
- 记录测试过程和结果
- 记录遇到的问题和解决方案
测试评估：
- 评估测试结果是否达到预期目标
- 分析测试中发现的问题
- 提出改进建议
测试报告：
- 编写测试报告，包括测试目标、范围、过程、结果和建议
- 提交给应急总指挥和相关团队
- 更新应急计划

演练案例

案例1：数据库崩溃演练

演练目标：验证数据库崩溃后的恢复流程和时间
演练步骤：
- 停止生产数据库服务
- 按照应急计划进行恢复
- 记录恢复时间和步骤
- 验证恢复结果
预期结果：
- 恢复时间不超过30分钟
- 数据完整性保持不变
- 应用程序能够正常访问

案例2：WAL损坏演练

演练目标：验证WAL损坏后的恢复流程和时间
演练步骤：
- 模拟WAL文件损坏
- 按照应急计划进行恢复
- 记录恢复时间和步骤
- 验证恢复结果
预期结果：
- 恢复时间不超过1小时
- 数据丢失控制在可接受范围内
- 应用程序能够正常访问

7. 计划维护与更新

计划更新频率

定期更新：每半年审查和更新一次应急计划
事件触发更新：
- 数据库架构发生重大变化
- 业务需求发生变化
- 恢复流程或工具发生变化
- 发生重大故障或演练后

更新流程

收集更新需求：
- 收集相关团队的反馈和建议
- 分析业务和技术变化
- 总结故障和演练经验
更新计划内容：
- 更新团队成员和联系方式
- 更新资源清单和配置
- 更新恢复流程和步骤
- 更新测试计划和用例
审核和批准：
- 提交更新后的计划给应急总指挥审核
- 获得批准后发布新计划
- 通知相关团队
培训和沟通：
- 组织相关团队培训
- 确保所有团队成员了解更新内容
- 提供更新后的计划文档

不同PostgreSQL版本的应急计划差异

PostgreSQL 9.x

恢复配置：使用recovery.conf文件而非recovery.signal
复制功能：逻辑复制支持有限
监控工具：内置监控视图功能较弱
备份工具：pg_basebackup功能相对简单
恢复工具：使用pg_resetxlog而非pg_resetwal

PostgreSQL 10+

恢复配置：使用recovery.signal文件
复制功能：增强的流式复制和逻辑复制
监控工具：增强的内置监控视图
备份工具：pg_basebackup支持更多选项
恢复工具：使用pg_resetwal（pg_resetxlog作为别名）

PostgreSQL 12+

恢复配置：支持postgresql.auto.conf自动配置
复制功能：增强的逻辑复制功能
监控工具：新增pg_stat_wal等视图
备份工具：支持并行备份
恢复工具：改进的pg_resetwal安全性

PostgreSQL 14+

恢复配置：支持更多恢复选项
复制功能：增强的复制监控
监控工具：新增pg_stat_sys_memory等系统资源视图
备份工具：支持更多备份格式
恢复工具：改进的pg_resetwal诊断输出

应急计划最佳实践

1. 贴合实际生产环境

基于实际生产环境制定计划
考虑不同场景和故障类型
确保计划可执行、可测试

2. 明确角色和职责

每个团队成员都有明确的角色和职责
建立清晰的沟通渠道
确保备用联系方式可用

3. 定期测试和更新

定期测试恢复流程
及时更新计划内容
总结经验教训

4. 自动化和工具支持

使用自动化工具进行监控和告警
准备好必要的工具和脚本
确保工具版本与生产环境兼容

5. 文档化和知识共享

详细记录恢复流程和步骤
分享经验和知识
确保新团队成员了解应急计划

6. 与业务需求对齐

了解业务优先级和SLA要求
确保恢复目标符合业务需求
与业务团队保持沟通

总结

PostgreSQL应急计划是数据库运维的重要组成部分，制定有效的应急计划可以帮助DBA在发生故障时快速、有序地进行响应和恢复，最大限度地减少数据丢失和业务中断时间。应急计划应该包括团队组织、风险评估、响应流程、资源准备、恢复策略、测试演练和计划维护等内容，并定期进行测试和更新，确保其有效性和可用性。

PostgreSQL 应急计划制定 ​

应急计划概述 ​

应急计划的重要性 ​

应急计划的组成部分 ​

1. 应急团队组织架构 ​

团队角色与职责 ​

联系方式与备用联系方式 ​

2. 风险评估与优先级 ​

常见故障类型与影响 ​

数据分类与保护级别 ​

3. 应急响应流程 ​

故障检测与报告 ​

故障分类与评估 ​

恢复方案制定与批准 ​

恢复执行与验证 ​

故障关闭与总结 ​

4. 资源准备 ​

硬件资源 ​

软件资源 ​

文档资源 ​

外部资源 ​

5. 恢复策略与方案 ​

数据库崩溃恢复 ​

WAL损坏恢复 ​

复制延迟恢复 ​

6. 测试与演练 ​

测试类型与频率 ​

测试流程 ​

演练案例 ​

7. 计划维护与更新 ​

计划更新频率 ​

更新流程 ​

不同PostgreSQL版本的应急计划差异 ​

PostgreSQL 9.x ​

PostgreSQL 10+ ​

PostgreSQL 12+ ​

PostgreSQL 14+ ​

应急计划最佳实践 ​

1. 贴合实际生产环境 ​

2. 明确角色和职责 ​

3. 定期测试和更新 ​

4. 自动化和工具支持 ​

5. 文档化和知识共享 ​

6. 与业务需求对齐 ​

总结 ​

PostgreSQL 应急计划制定

应急计划概述

应急计划的重要性

应急计划的组成部分

1. 应急团队组织架构

团队角色与职责

联系方式与备用联系方式

2. 风险评估与优先级

常见故障类型与影响

数据分类与保护级别

3. 应急响应流程

故障检测与报告

故障分类与评估

恢复方案制定与批准

恢复执行与验证

故障关闭与总结

4. 资源准备

硬件资源

软件资源

文档资源

外部资源

5. 恢复策略与方案

数据库崩溃恢复

WAL损坏恢复

复制延迟恢复

6. 测试与演练

测试类型与频率

测试流程

演练案例

7. 计划维护与更新

计划更新频率

更新流程

不同PostgreSQL版本的应急计划差异

PostgreSQL 9.x

PostgreSQL 10+

PostgreSQL 12+

PostgreSQL 14+

应急计划最佳实践

1. 贴合实际生产环境

2. 明确角色和职责

3. 定期测试和更新

4. 自动化和工具支持

5. 文档化和知识共享

6. 与业务需求对齐

总结