印刻数据库

外观

PostgreSQL 切换演练 ​

切换演练概述 ​

什么是切换演练 ​

切换演练（Switchover Drills）是指在受控环境中模拟主备切换的过程，验证高可用架构的可靠性和切换流程的正确性。切换演练包括手动切换演练和自动故障转移演练两种类型。

切换演练的重要性 ​

  • 验证高可用架构的可靠性
  • 熟悉切换流程，提高运维能力
  • 发现潜在问题，提前修复
  • 确保切换流程符合预期
  • 满足合规要求，如ISO 27001、SOC 2等

切换演练目标 ​

  • 验证切换流程的正确性
  • 测试切换时间，确保符合SLA要求
  • 验证数据一致性
  • 测试应用的切换兼容性
  • 验证监控告警机制
  • 培训运维团队

切换演练准备 ​

1. 制定演练计划 ​

  • 确定演练类型：手动切换或自动故障转移
  • 选择演练时间：业务低峰期，如周末或凌晨
  • 确定演练范围：单机切换或集群切换
  • 制定详细步骤：包括准备、执行、验证和回滚
  • 明确角色和职责：演练负责人、执行人员、监控人员、应用验证人员

2. 准备测试环境 ​

  • 搭建测试集群：与生产环境相似的配置
  • 模拟生产数据：使用生产环境的备份数据
  • 配置监控工具：Prometheus + Grafana、Zabbix等
  • 准备测试脚本：切换脚本、验证脚本、回滚脚本

3. 备份重要数据 ​

  • 生产环境备份：执行生产环境全量备份
  • 配置文件备份：备份postgresql.conf、pg_hba.conf等
  • 集群配置备份：备份Patroni、repmgr等配置

4. 通知相关团队 ​

  • 应用团队：通知应用可能的影响
  • 运维团队：安排演练人员
  • 监控团队：关注演练过程的监控指标
  • 管理层：告知演练计划和预期影响

5. 准备回滚方案 ​

  • 制定回滚步骤：详细的回滚流程
  • 准备回滚脚本：自动化回滚脚本
  • 测试回滚方案：确保回滚能够成功执行

手动切换演练执行步骤 ​

1. 预演练检查 ​

sql
-- 检查主备状态
SELECT 
    application_name AS 备库名称,
    client_addr AS 备库IP,
    state AS 复制状态,
    sync_state AS 同步状态,
    pg_wal_lsn_diff(pg_current_wal_lsn(), replay_lsn) AS 回放延迟_bytes
FROM pg_stat_replication;

-- 检查数据库状态
SELECT datname, state FROM pg_stat_database;

-- 检查锁状态
SELECT * FROM pg_locks WHERE NOT granted;

2. 执行手动切换 ​

按照之前文档中描述的手动切换流程执行切换：

  1. 检查复制状态
  2. 停止主库写入操作
  3. 验证备库已应用所有WAL
  4. 提升备库为主库
  5. 验证新主库状态
  6. 将原主库转换为备库
  7. 验证新的主备关系

3. 应用验证 ​

  • 连接测试：验证应用能够连接到新主库
  • 功能测试：测试核心业务功能
  • 性能测试：检查系统性能指标
  • 数据一致性测试：验证数据完整性

4. 监控验证 ​

  • 检查监控指标：CPU、内存、磁盘I/O、网络连接
  • 验证告警机制：切换过程中的告警是否正常
  • 检查日志：主备库日志、应用日志

5. 回滚（如果需要） ​

如果切换过程中出现问题，执行回滚操作：

  1. 停止新主库写入
  2. 恢复原主库
  3. 重新配置备库
  4. 恢复应用连接

自动故障转移演练执行步骤 ​

1. 预演练检查 ​

bash
# 检查Patroni集群状态
patronictl -c /etc/patroni/patroni.yml list

# 检查repmgr集群状态
repmgr -f /etc/repmgr/repmgr.conf cluster show

# 检查pg_auto_failover集群状态
pg_autoctl show state

2. 模拟主库故障 ​

根据不同的高可用解决方案，选择合适的方式模拟主库故障：

Patroni 故障模拟 ​

bash
# 停止PostgreSQL服务
systemctl stop postgresql-14

# 或终止PostgreSQL进程
pkill -9 postgres

repmgr 故障模拟 ​

bash
# 停止PostgreSQL服务
pg_ctl stop -D /var/lib/pgsql/14/data -m immediate

pg_auto_failover 故障模拟 ​

bash
# 停止PostgreSQL服务
systemctl stop postgresql-14

3. 观察故障转移过程 ​

  • 监控切换时间：从故障发生到新主库可用的时间
  • 观察日志：高可用组件日志、PostgreSQL日志
  • 检查监控：复制状态变化、告警触发情况

4. 验证故障转移结果 ​

sql
-- 检查新主库状态
SELECT pg_is_in_recovery();

-- 检查复制状态
SELECT * FROM pg_stat_replication;

-- 检查数据一致性
SELECT count(*) FROM important_table;

5. 恢复原主库 ​

  • 将原主库重新加入集群
  • 验证复制状态正常
  • 确保数据一致

切换演练验证 ​

1. 切换时间验证 ​

  • 测量切换时间：从开始切换到应用恢复可用的时间
  • 分析切换时间构成：准备时间、执行时间、验证时间
  • 与SLA对比：确保满足业务要求

2. 数据一致性验证 ​

  • 全量数据对比：使用pg_comparator等工具
  • 关键表验证：验证核心业务表的数据一致性
  • 事务完整性验证：确保事务未丢失

3. 应用可用性验证 ​

  • 应用连接验证：应用能够自动连接到新主库
  • 功能验证：核心业务功能正常
  • 性能验证：系统性能符合预期

4. 监控告警验证 ​

  • 告警触发验证：切换过程中的告警是否正常触发
  • 告警内容验证：告警信息准确、清晰
  • 告警级别验证：告警级别设置合理

5. 文档验证 ​

  • 验证切换文档：文档步骤是否正确
  • 更新文档：根据演练结果更新文档
  • 完善流程：优化切换流程

切换演练报告 ​

1. 演练概况 ​

  • 演练时间：开始和结束时间
  • 演练类型：手动切换或自动故障转移
  • 演练范围：单机或集群
  • 参与人员：演练团队成员

2. 演练过程 ​

  • 执行步骤：详细的执行过程
  • 遇到的问题：演练中遇到的问题及解决方案
  • 切换时间：各阶段的时间统计

3. 演练结果 ​

  • 切换成功与否：成功或失败
  • 数据一致性：数据是否一致
  • 应用可用性：应用是否正常
  • 监控告警：告警是否正常

4. 改进建议 ​

  • 流程改进：切换流程的优化建议
  • 配置优化：参数调整建议
  • 工具改进：工具使用建议
  • 团队培训：培训需求

5. 结论 ​

  • 演练是否达到目标：目标完成情况
  • 高可用架构是否可靠：架构评估
  • 后续行动计划：下一步工作

切换演练最佳实践 ​

1. 定期演练 ​

  • 频率：建议每季度至少一次
  • 类型：交替进行手动切换和自动故障转移演练
  • 范围：从单机到集群，逐步扩大范围

2. 模拟真实场景 ​

  • 模拟网络故障：断开网络连接
  • 模拟硬件故障：关闭服务器电源
  • 模拟存储故障：断开存储连接
  • 模拟软件故障：终止PostgreSQL进程

3. 自动化演练 ​

  • 编写演练脚本：自动化切换脚本、验证脚本
  • 使用CI/CD工具：Jenkins、GitLab CI等
  • 自动化监控：Prometheus + Grafana自动监控

4. 故障注入测试 ​

  • 混沌工程：使用Chaos Monkey等工具
  • 随机故障：随机选择故障点
  • 逐步增加复杂度：从简单故障到复杂故障

5. 持续改进 ​

  • 分析演练结果：定期回顾演练报告
  • 优化切换流程：根据演练结果改进
  • 更新文档：保持文档与实际流程一致
  • 培训团队：提高团队技能

常见问题与解决方案 ​

1. 切换时间过长 ​

问题现象：

  • 切换时间超过预期
  • 应用长时间不可用

解决方案：

  • 优化切换流程，减少手动步骤
  • 提高备库硬件配置
  • 调整PostgreSQL参数，减少WAL生成
  • 考虑使用并行复制

2. 数据不一致 ​

问题现象：

  • 切换后数据不一致
  • 应用查询到错误数据

解决方案：

  • 确保复制延迟在可接受范围内
  • 使用同步复制
  • 启用pg_rewind功能
  • 执行全量数据校验

3. 应用连接失败 ​

问题现象：

  • 切换后应用无法连接
  • 连接超时或认证失败

解决方案：

  • 与负载均衡器集成，自动更新路由
  • 配置应用连接池自动重连
  • 使用DNS别名或VIP机制
  • 验证pg_hba.conf配置

4. 监控告警不及时 ​

问题现象：

  • 切换过程中告警延迟
  • 告警信息不准确

解决方案：

  • 调整监控采集频率
  • 优化告警规则
  • 配置多级告警机制
  • 测试告警渠道

5. 回滚失败 ​

问题现象：

  • 回滚过程中出现错误
  • 回滚后系统不可用

解决方案：

  • 完善回滚方案
  • 测试回滚脚本
  • 确保备份可用
  • 增加回滚步骤的验证

版本差异注意事项 ​

PostgreSQL 9.6 ​

  • 不支持pg_rewind功能
  • 需要使用recovery.conf配置文件
  • 切换时间可能较长

PostgreSQL 10-11 ​

  • 支持pg_rewind功能
  • 开始支持recovery.signal文件
  • 切换时间有所优化

PostgreSQL 12+ ​

  • 支持并行复制，提高复制性能
  • 增强了WAL管理功能
  • 切换时间进一步优化
  • 支持更细粒度的复制控制

总结 ​

切换演练是确保PostgreSQL高可用架构可靠性的重要手段，通过定期的切换演练，可以验证切换流程的正确性，发现潜在问题，提高运维团队的能力。切换演练需要精心准备，包括制定计划、准备环境、备份数据、通知团队和准备回滚方案。

在实际生产环境中，建议：

  1. 定期进行切换演练，至少每季度一次
  2. 交替进行手动切换和自动故障转移演练
  3. 模拟真实故障场景，提高演练的真实性
  4. 自动化演练流程，减少人为错误
  5. 分析演练结果，持续改进切换流程
  6. 完善文档，保持文档与实际流程一致

通过合理的切换演练，可以确保PostgreSQL高可用架构在关键时刻能够可靠地工作，减少业务中断时间，提高系统可用性。