印刻数据库

外观

PostgreSQL 升级回滚方案 ​

在 PostgreSQL 升级过程中，即使进行了充分的准备和测试，仍可能遇到不可预见的问题导致升级失败。一个完善的回滚方案是确保升级安全的关键保障。本文将详细介绍 PostgreSQL 升级的回滚策略、准备工作和具体步骤。

回滚前准备 ​

环境准备 ​

  • 完整备份：升级前必须对源数据库进行全量备份，包括数据文件、配置文件和WAL日志
  • 配置备份：备份所有配置文件（postgresql.conf、pg_hba.conf、pg_ident.conf等）
  • 环境隔离：确保源数据库和目标数据库环境完全隔离，避免相互影响
  • 回滚脚本：提前编写好回滚脚本，包括服务启停、配置恢复等步骤
  • 权限准备：确保执行回滚操作的用户具有足够的权限

工具准备 ​

  • 备份恢复工具：pg_dump/pg_restore、pg_basebackup等
  • 监控工具：确保可以监控回滚过程中的系统资源使用情况
  • 日志工具：准备好日志收集和分析工具，以便回滚过程中的问题排查

回滚触发条件 ​

明确升级失败的判定标准，当出现以下情况时，应立即触发回滚：

  • 升级过程中出现致命错误，无法继续执行
  • 升级完成后，核心功能测试失败
  • 性能下降超过预期（如查询响应时间增加50%以上）
  • 出现数据不一致或数据丢失
  • 应用程序兼容性问题无法解决

不同升级方式的回滚策略 ​

pg_upgrade 回滚策略 ​

pg_upgrade 是物理升级方式，回滚相对简单，主要依赖于升级前对源数据库的备份和保留。

回滚准备 ​

  • 升级前保留源数据库的完整目录结构和数据文件
  • 记录源数据库的端口、数据目录、配置文件路径等关键信息
  • 确保源数据库的二进制文件仍可用

回滚步骤 ​

  1. 停止目标数据库服务

    bash
    # PostgreSQL 10+
pg_ctl -D /path/to/target/data stop -m fast

# 系统服务方式
systemctl stop postgresql@15-main

  2. 恢复源数据库配置

    • 确保源数据库的配置文件未被修改
    • 如果配置文件被修改，使用备份恢复

  3. 启动源数据库服务

    bash
    # PostgreSQL 10+
pg_ctl -D /path/to/source/data start

# 系统服务方式
systemctl start postgresql@14-main

  4. 验证源数据库状态

    bash
    psql -h localhost -p 5432 -U postgres -c "SELECT version();"
psql -h localhost -p 5432 -U postgres -c "SELECT pg_is_in_recovery();"

逻辑备份恢复回滚策略 ​

逻辑备份恢复方式的回滚主要依赖于升级前的备份，回滚过程相对简单。

回滚准备 ​

  • 升级前的全量逻辑备份
  • 备份期间的WAL日志（用于PITR恢复）
  • 源数据库的二进制文件和配置

回滚步骤 ​

  1. 停止目标数据库服务

    bash
    pg_ctl -D /path/to/target/data stop -m fast

  2. 清理目标数据库（可选）

    bash
    rm -rf /path/to/target/data

  3. 恢复源数据库

    • 如果源数据库未被删除，直接启动
    • 如果源数据库已被删除，使用备份恢复：
      bash
      # 使用pg_restore恢复全量备份
pg_restore -d postgres -U postgres -C -F c /path/to/backup/pg_dumpall.sql

# 或使用psql恢复SQL格式备份
psql -U postgres -f /path/to/backup/pg_dumpall.sql

  4. 启动源数据库

    bash
    pg_ctl -D /path/to/source/data start

复制升级回滚策略 ​

复制升级（如使用流复制或逻辑复制）的回滚策略取决于复制架构。

回滚准备 ​

  • 确保主库和备库的角色信息明确
  • 记录复制延迟和同步状态
  • 准备好切换工具和脚本

流复制升级回滚步骤 ​

  1. 停止目标主库服务

    bash
    pg_ctl -D /path/to/target/data stop -m fast

  2. 提升源备库为主库

    • 在源备库上执行：
      bash
      pg_ctl -D /path/to/source/standby/data promote
    • 或使用触发文件：
      bash
      touch /path/to/source/standby/data/promote

  3. 更新应用连接配置

    • 将应用连接指向原备库（现在的主库）
    • 更新连接池配置

  4. 重新配置复制

    • 如有需要，重新搭建复制架构

逻辑复制升级回滚步骤 ​

  1. 停止目标数据库的订阅

    sql
    ALTER SUBSCRIPTION my_subscription DISABLE;
DROP SUBSCRIPTION my_subscription;

  2. 恢复源数据库的发布

    sql
    -- 如果发布被删除，重新创建
CREATE PUBLICATION my_publication FOR ALL TABLES;

  3. 更新应用连接

    • 将应用连接切换回源数据库

回滚步骤详解 ​

1. 回滚决策与沟通 ​

  • 评估损失：评估升级失败造成的影响范围和程度
  • 决策批准：按照应急预案流程，获得回滚决策批准
  • 通知相关方：通知开发、运维、业务等相关团队回滚计划
  • 记录决策：详细记录回滚决策的原因、时间和批准人

2. 回滚执行 ​

根据不同的升级方式，执行相应的回滚步骤：

  • 停止所有相关服务：包括应用服务、中间件、监控服务等
  • 执行回滚操作：按照预定义的回滚脚本执行
  • 监控回滚过程：实时监控系统资源使用情况和日志
  • 记录回滚过程：详细记录回滚的每一步操作和结果

3. 回滚验证 ​

回滚完成后，需要进行全面的验证：

  • 服务状态验证：确认数据库服务正常启动

    bash
    pg_ctl -D /path/to/source/data status
systemctl status postgresql@14-main

  • 连接验证：测试应用连接是否正常

    bash
    psql -h localhost -p 5432 -U postgres -c "SELECT 1;"

  • 数据完整性验证：

    sql
    -- 检查数据库数量
SELECT COUNT(*) FROM pg_database;

-- 检查关键表的数据量
SELECT COUNT(*) FROM important_table;

-- 检查最近的事务
SELECT * FROM pg_stat_activity WHERE state = 'active';

  • 性能验证：运行性能基准测试，确认性能恢复正常

    bash
    pgbench -h localhost -p 5432 -U postgres -c 10 -j 2 -t 1000 testdb

4. 回滚后处理 ​

  • 清理目标环境：删除临时文件和目录，释放磁盘空间
  • 更新文档：记录升级失败的原因和回滚过程
  • 分析失败原因：组织相关人员分析升级失败的根本原因
  • 优化升级方案：根据失败原因，优化升级方案，准备重新升级

不同版本的回滚注意事项 ​

PostgreSQL 9.x 版本 ​

  • 9.x 版本使用的是传统的启动脚本，而非systemd服务
  • 9.4及以下版本不支持某些高级功能，如逻辑复制
  • 回滚时需注意配置文件路径的差异

PostgreSQL 10+ 版本 ​

  • 10+ 版本引入了systemd服务管理
  • 12+ 版本引入了wal_level的默认值变更（从minimal改为replica）
  • 14+ 版本引入了更多的监控指标和管理功能

回滚最佳实践 ​

1. 制定详细的回滚计划 ​

  • 提前编写回滚脚本，包括所有必要的步骤
  • 明确回滚的时间窗口和预期完成时间
  • 确定回滚的负责人和协作人员

2. 进行回滚演练 ​

  • 在测试环境中进行回滚演练，验证回滚计划的可行性
  • 记录演练过程中遇到的问题，并优化回滚计划
  • 定期更新和演练回滚计划

3. 保持环境一致性 ​

  • 确保源数据库和目标数据库的环境配置一致
  • 避免在升级过程中修改源数据库的配置
  • 确保回滚过程中使用的工具版本与源数据库兼容

4. 实时监控和日志分析 ​

  • 回滚过程中实时监控系统资源使用情况
  • 收集和分析回滚过程中的所有日志
  • 及时发现和解决回滚过程中的问题

5. 事后总结和改进 ​

  • 回滚完成后，组织相关人员进行总结
  • 分析升级失败的根本原因
  • 优化升级方案和回滚计划
  • 更新相关文档和流程

案例分析 ​

案例1：pg_upgrade 升级失败回滚 ​

背景：从 PostgreSQL 13 升级到 15 过程中，pg_upgrade 执行失败，提示数据文件版本不兼容。

回滚过程：

  1. 停止目标数据库服务
  2. 启动源 PostgreSQL 13 服务
  3. 验证源数据库状态正常
  4. 分析失败原因：发现目标数据库的 initdb 版本与源数据库不兼容

改进措施：

  • 确保目标数据库使用正确版本的 initdb 初始化
  • 在升级前增加版本兼容性检查步骤

案例2：逻辑备份恢复升级失败回滚 ​

背景：使用 pg_dumpall 备份 PostgreSQL 12 数据库，恢复到 PostgreSQL 14 后，应用程序连接失败。

回滚过程：

  1. 停止 PostgreSQL 14 服务
  2. 启动 PostgreSQL 12 服务
  3. 验证应用连接正常
  4. 分析失败原因：发现应用程序依赖的某个扩展在 PostgreSQL 14 中语法发生了变化

改进措施：

  • 升级前测试应用程序与目标 PostgreSQL 版本的兼容性
  • 针对依赖的扩展进行单独测试

总结 ​

一个完善的回滚方案是 PostgreSQL 升级成功的重要保障。在升级前，必须做好充分的准备工作，包括完整备份、环境隔离、回滚脚本编写等。根据不同的升级方式，选择合适的回滚策略，并在回滚过程中进行实时监控和验证。回滚完成后，及时总结和改进，不断优化升级和回滚流程，确保数据库升级的安全性和可靠性。

通过本文的介绍，希望能帮助 DBA 们制定出更加完善的 PostgreSQL 升级回滚方案，应对各种升级失败情况，保障数据库系统的稳定运行。