江苏龙网

  1. 首页 > 资讯 > 科技 > >

InfoQ|一次近乎完美的PostgreSQL版本大升级实践( 二 )


PostgreSQL 版本 11 上不能有回归 。 我们开发了一个自定义基准测试来运行更广泛的回归测试 ， 目标是识别 PostgreSQL 11 中潜在的查询性能下降 。
升级应当针对整体项目 ， 并在维护窗口内完成 。
使用 pg_upgrade 升级 ， 其依赖于物理层面 ， 而非逻辑或者复制 。
保留一个 9.6 版本的集群样本 。 并非所有节点都需要升级 ， 我们应保留一些 9.6 版本的节点以备回滚 。
升级应全自动化 ， 以降低人类失误的可能性 。
全部数据库升级的维护窗口只有 30 分钟 。
升级应留有记录并将其发布 。
项目
为使生产升级能顺利运行 ， 我们将项目划分为以下几个阶段：
第一阶段：在封闭环境中开发自动化
开发 ansible-playbook ， 并在 staging 上备份的 PostgreSQL 环境中进行测试 。
独立环境的使用让我们可以随时停止、启动 ， 或者恢复备份 ， 也让我们专注开发 ， 并得以将环境随时回滚到升级前 。
我们使用 staging 上的备份在环境中进行项目升级 ， 在这个过程中 ， 我们也遇到一些诸如在迁移数据库的过程中如何监视不同程序之类的挑战 。
第二阶段：在 staging 中将升级开发与配置管理进行分段式融合
在 Chef 中集成配置管理 ， 并运行数据库磁盘中的一个快照（可用于还原更新前状态） 。
通知用户 ， 本次维护窗口将力争对他们工作的影响降到最低 ， 并在没有数据损失风险的情况下进行安全升级 。
在对配置管理进行迭代和集成测试后 ， 我们开始在 staging 上运行端到端测试 。 这些测试内容是在内部公开的 ， 所以其他共享这个环境的团队会知道 staging 在这段时间暂时不可用 。
第三阶段：在 staging 上测试端到端升级
正式运行前对环境的检查 。 我们有时候会在这一步发现认证的问题 ， 有时候也会做一些能提升测试效率的小调整 。
停止 GitLab 上所有应用和流量 ， 在 CloudFlare 和 HA-proxy 上添加维护模式 ， 停止包括数据库、sidekiq、workhorse、WEB-API 等一切能访问数据库的应用 。
升级集群中六个节点中的三个 。 与生产中部分场景的策略类似 ， 我们同样准备了回滚方案 。
为 PostgreSQL 的更新运行 ansible-playbook 。 首先是数据库 leader 节点 ， 之后是一些二级节点 。
升级之后：我们在 ansible-playbook 中运行了一些自动化测试 ， 用以检测复制数据与原数据是否相符 。
接下来启动应用程序 ， 让我们的 QA 团队能运行一些测试 。 他们在升级后的数据库上运行了本地单元测试 ， 我们对负面结果进行了调查 。
测试结束后 ， 我们再次停止程序运行 ， 并将 staging 集群还原到 9.6 版本 ， 将升级过后的节点关闭到版本 11 ， 最后启动旧版集群 。 Patroni 会 promote 其中一个节点 ， 启动应用后集群就可以收到流量反馈 。 我们将 Chef 的配置恢复到集群 9.6 版本后重建数据库 ， 留出六个节点为下次测试做准备 。
我们总共在 staging 中运行过 7 次测试 ， 并通过反馈不断完善程序 。
第四阶段：升级进入生产环境
生产环境的步骤与 staging 中类似 ， 我们计划迁移八个节点 ， 留下四个作为备份 。
执行项目前期检查
宣布维护开始
运行 ansible-playbook 以停止流量和应用
运行 ansible-playbook 以进行 PostgreSQL 升级
开始验证测试并恢复流量 。 我们只运行了必需的测试 ， 才能在短暂的维护窗口内完成所有内容
回滚计划只会在数据库不一致或者 QA 测试出错时才调用 ， 以下是具体步骤：
停止 PostgreSQL 11 集群
还原 Chef 中配置到 PostgreSQL 9.6
用 9.6 版本中的四个节点初始化集群 。 通过这四个节点 ， 我们可以在流量较低的时候恢复 GitLab 上的活动 。


推荐阅读


上一篇：iQOO手机|不是游戏手机却拥有职业水准，iQOO 5游戏体验分享

下一篇：行业互联网|一加科技联合创始人裴宇确认离职：工作7年后决定告别