数据库如何融入 DevOps

幸福一生一世

1.背景

1.1 DevOps 与 数据库

DevOps 用自动化流程整合了开发（Dev）、质量保证（QA）、运维（Ops）的流程，使得架构变更和软件交付更加地迅速、频繁和可靠。但是现有的 DevOps 流程，很多都绕开了数据库。目前市面上出现了一些数据库 DevOps 的工具，例如 SchemaHero、ByteBase 等等，以 DevOps 的流程处理数据库的版本变更（主要是 Schema change）。最近在看 PlanetScale，发现 PlanetScale 也将自己使劲往 DevOps 上靠。其实 PlanetScale 做这个事是有天然优势的，本来就需要使用该数据库中间件的用户，不用再引入额外的系统实现数据库 DevOps 了。
本文后面的内容，主要以 PlanetScale Schema change 为例。
1.2 数据库 Schema 变更

现在的数据库 schema 变更，流程较长（如下图），具有需要人工操作，出问题概率大，不好回滚的问题。


2.PlantScale 如何实现数据库 DevOps，以 Schema Change 为例




目标：DB 变更（主要是 schema）与 DevOps 里的的研发、测试、deploy流程结合，具备自动化、安全保证、可回滚的能力。
PlanetScale 使用 database branch 的概念与应用代码的 git branch 对应，作为应用的数据库开发环境。一个 database branch 是生产环境数据库的一份独立的拷贝，用户可以在这个分支上执行 Schema 变更和测试。它的主要好处是：可以基于真实数据做测试，且不影响线上应用。
在做完测试后，即可发起 Deploy requests，其他的 reviewer 可以像 review 代码一样评论、批准。一旦测试和 review 都通过，当前开发环境和生产环境就可以瞬间切换，整个 schema 变更的流程不需要加锁。如果测出问题，直接删除，生产环境不受影响。
3. Schema Change 具体流程

一般而言，Online schema change 工具的工作流程如下：

• 拷贝目标表（shadow table）。
  
• 执行 DDL。
  
• 同步原表的数据。
  
• 原子切换 shadow table 与原表。
  
• 删除原表。
  

PlanetScale 在这个基础上，扩展了了 branch workflow 的概念，但技术上并没有太多新鲜的东西：

• 创建一个数据库 development branch，其实就是 shadow table。
  
• 发起 schema 变更，包含了执行 DDL 、实时同步数据和基本的测试。
  
• 发起 deploy request。
  
• 其他团队成员可以 review 变更。
  
• 集成测试（if necessary）。
  
• 点击 "Deploy", 进入发布等待队列.
  

当把 shadow table 转化为 production table后，原来的表会保留一段时间（默认 30 min），两个表之间会继续同步（双写）。一旦用户反悔了，把原表切回来就可以。文献 https://planetscale.com/blog/zero-downtime-laravel-migrations给出了几个具体的例子。
这个 schema 变革的流程，表面上看起来和原来的 online ddl 非常相似，其实加入了很多机制，例如：审查、测试、回滚等。这让 schema change 的流程更加集成、自动化、安全、快捷。

参考
https://planetscale.com/blog/database-devops
https://planetscale.com/blog/zero-downtime-laravel-migrations
https://planetscale.com/docs/concepts/nonblocking-schema-changes
https://planetscale.com/blog/revert-a-migration-without-losing-data