什么是数据库 Schema Drift

所谓数据库结构漂移，或者说 schema drift，描述的是当前数据库的实际schema (实际状态) 和source of truth (理想状态) 之间存在偏差的情况。这也是造成和数据库相关故障的最常见原因之一。

当前数据库的实际状态很好理解：

• 在 MySQL 中，它指的是命令mysqldump --no-data的输出结果；

• 在 PostgreSQL 中，它指的是命令pg_dump --schema-only的输出结果。

而 source of truth 的情况要更为复杂……

The source of truth

你可能会好奇为何需要单独分一个 source of truth 出来。原因是当前数据库的 schema 并不总是和理想状态一致。误操作和软件 bug 都可能导致数据库 schema 发生意外的变更。鉴于此，有必要保留一个独立的 source of truth。这也和会计学中复式簿记法的理念一脉相承。

source of truth 最好存放在版本控制系统 (VCS) 中，也即和应用代码放在同一个地方。这就是所谓的 database-as-code，是对 GitOps 的实践。诸如 Liquibase 和 Flyway 之类的解决方案基本都支持这种做法。Bytebase 也是如此，不过在此基础上更进一步，提供点击即用的 UI 以配置 VCS 集成。

source of truth格式

搞清了source of truth的存放位置后，就该选定source of truth的格式了。这里我们给出两种方案，分别是基于状态 (state-based) 的方案和基于迁移 (migration- based) 的方案。长话短说：

• 选用基于状态的方案时，整个 schema 的理想最终状态存储在代码仓库中；

• 选用基于迁移的方案时，迁移文件存储在仓库中。每份文件包含一组 DDL 语句，例如 CREATE/ALTER/DROP TABLE。按规定的顺序依次执行文件，便可得到理想的 schema 状态。

基于状态的方案更加符合直觉，因为单个文件对应一个数据库schema。然而，基于状态的方案有一定局限性，难以适用于所有场景。(可以参考这篇文章：「state-based or migration-based」)这也是为何 Liquidbase，Flyway 和 Bytebase 都选用了基于迁移的方案。

schema drift 检测

若采用基于迁移的方案，schema drift 的检测就会更加困难。系统要从一系列迁移文件中推演出理想的数据库 schema，再将其与数据库当前实际的 schema 做对比，以此来检测 drift。

1. 对于每次 schema 迁移，Bytebase 都会保留一份 schema 快照。

2. 如果团队使用版本控制系统管理数据库 schema，他们可以配置 Bytebase，将 schema 快照按指定路径回写至仓库。以下是 Bytebase 依照用户配置的路径回写整个 schema 快照的示例。

通过运用这一机制，Bytebase 不断比较 schema 快照和数据库当前的实际 schema，一旦发现drift，当即报告👇

drift 详情👇

总结

数据库 schema drift 是造成和数据库相关的故障的最常见原因之一。要解决这一问题，第一步是将理想的数据库 schema 状态记录到类似 GitLab 的版本控制系统中。Bytebase 则更进一步，提供了易用的 UI，以帮助用户采用这种方案。此外，一旦检测到 schema drift，Bytebase 便会展示其详细信息。

感兴趣的话，可以参看我们的 demo，也可以用简单的一行命令自行部署 Bytebase。