“关系”在数据库中的主要表现形式是表，包含表属性，列属性，索引以及约束等。通过“关系”来规范存储，使得用户通过SQL标准规范存取数据。借助SQL语句丰富的表达能力，在数据库层面就能搞定复杂的业务。当然，为了做到这一点，“关系”定义（schema）的维护至关重要。当schema需要发生变更时，如何能做到Online(不影响业务的读写操作)？业内数据库Online schema变更的方案有哪些？X-DB是如何实现的，设计背后的原因是什么？本文将详细讨论。

MySQL Online DDL的演进

MySQL毫无疑问是最流行的开源单机数据库。在5.5版本以前，MySQL不支持Online DDL。需要做schema变更时（例如：修改列、加索引等），要么锁表变更(禁写)，要么通过主备切换的方式来进行。第二种方式的缺陷在于：需要DBA人工介入，而且主备的schema变更先后生效，无法严格一致。

既然数据库内部搞不定，那就在数据库外部做。pt-online-schema-change, gh-ost等变更工具，通过建立目标schema的影子表，借助触发器双写或者拉取binlog双写，最终通过rename影子表操作来达到变更的效果。

5.6版本以后，MySQL内部开始支持Online DDL。主要原理是将数据分为基线和增量两部分，开启一个单独线程变更基线数据，同时增量实时记录到row-log里。基线变更结束后，通过回放row-log，实现增量同步。整个过程中有几个关键点：第一，开始变更时获取快照，这个阶段需要禁写，确保获取snapshot对应的基线，和后续增量(row-log)是一份完整的数据；第二，在基线变更完成后，开始回放row-log，由于row-log随着业务的写入在不断追加，因此这里基于一个前提：row-log的回放速度高于业务写入的速度，否则可能一直追不上，schema变更也就无法完成；第三，schema生效阶段同样需要禁写，确保不会有新的写进来，新的schema开始生效。

目前，MySQL8.0在对于部分加列等schema变更操作做了优化，支持instant ddl，有点类似X-DB Fast DDL。其余Online DDL的基本原理仍保持不变。对于MySQL的Online DDL方案，需要说明的是：MySQL主备副本之间通过binlog同步，主的schema变更成功后，才会写binlog同步给备库，然后备库才开始做ddl。假设一个ddl变更需要1个小时，那么备库最多可能会延迟2倍的变更时间。若变更期间，主库发生故障，备库数据还未追平，则无法提供服务的。

NewSQL的Online DDL

NewSQL时代，Online DDL依然是一个绕不过去的问题。以两个优秀的开源数据库CockroachDB和TiDB为例，它们的Online DDL实现均参考论文Online, Asynchronous Schema Change in F1。F1-Server集群中每个server都是无状态的，多副本复制靠存储层Spanner保证。对于Spanner而言，F1-Server相当于一个客户端。数据库的schema通过Spanner持久化存储，每个F1-Server在本地维护一份schema的缓存，并通过lease机制保证缓存的时效性。任何一个F1-Server都可以接收读写请求，如果schema缓存不正确，就无法保证存取数据正确性。


DDL最简单的实现方法：执行变更过程中，所有F1-Server禁写，变更完成后，等待lease时间，确保所有F1-Server都拥有最新的Schema。但是，通常Schema变更都伴随着数据迁移，比如添加索引操作，需要依据主表build一份索引出来，这个时间可能很长，长时间禁写肯定是不可接受的。


既然禁写不可行，那么在DDL发生时，必然存在多个F1-Server存在多个不同版本的schema的情况。下面将以一个加索引的例子简单描述F1-Spanner架构下DDL执行过程，如为表Relation(Pk,C1)新加索引Index(C1)。首先选举一个F1-Servers作为Owner，记为F1-Server1，执行DDL后拥有了new-schema，同时假设F1-Server2仍然使用old-schema。


对于某个记录，F1-Server1会同时写入主表和索引数据；如果该记录后续被F1-Server2删除，那么只会删除主表记录，索引数据就会残留在系统中，这就产生了不一致。未解决这类问题，论文通过引入多个中间状态schema，并且证明如果任意两个相邻状态下，数据的一致性能得到保证，通过一系列中间状态变更，就最终能保证整个变更过程正确性。Online DDL变更过程分为四个步骤：absent->delete-only->write-only->public，相应地，schema版本包括4个状态：

• S1(absent): 变更之前的状态
• S2(delete-only): 只允许删除新二级索引，忽略新二级索引写入，不允许读新二级索引
• S3(write-only): 当所有F1-Server都达到S2状态后，开始进入这一阶段，允许删除/写入新二级索引进KV层，不允许读新二级索引，并开始扫描基线数据，构造新的二级索引<key,value>到KV层
• S4(public)：新二级索引对外可见(可读)

F1论文详细论述了经过这4个状态的转变，如何保证一致性，过程较为复杂，这里不做详述，感兴趣的朋友可以翻看原文。

数据库架构对Online-ddl影响

引入中间状态的目的是为了解决多个F1-Servers无法在schema变更期间，保证数据一致性。但这个前提是基于F1+Spanner框架（如图1）。

F1 架构

对于F1来说，Spanner是一个共享分布式存储层，而对Spanner来说，F1就是一个client。正在这种彻底的解耦、彻底的存储计算分离导致了schema-change的复杂性，当然架构的选择各有利弊的权衡，这里只是从Online DDL的角度考虑。