异步 schema 变更

为什么在分布式系统中异步变更 schema 比较困难

F1 中的 schema 变更是在线的、异步的，schema 变更的过程中所有数据保持可用，保持数据一致性，并最大限度的减小对性能的影响。最大的难点在于所有 F1 服务器的 schema 变更是无法同步的，也就是说不同的 F1 服务器会在不同的时间点切换至新 schema。

由于所有的 F1 服务器共享同一个 kv 存储引擎，schema 的异步更新可能造成严重的数据错乱。例如我们发起给一次添加索引的变更，更新后的节点会很负责地在添加一行数据的同时写入一条索引，随后另一个还没来得及更新的节点收到了删除同一行数据的请求，这个节点还完全不知道索引的存在，自然也不会去删除索引了，于是错误的索引就被遗留在数据库中。

深度剖析 Google F1 的 schema 变更算法

算法思想

为了更好地阐释算法思想，本节我们以一个简化的情境做类比。

假想我们有一家跨国公司，公司员工分布在全球各地，员工之间以电子邮件的方式互相通信，同时工作的性质要求员工之间发送的消息不能出现丢失。之后在某一天出现这样的需求：管理层决定把员工通信方式由邮件改为 QQ。

对于这样一个跨国公司来说，我们无法瞬间把新的工作方式通知给所有员工。假如先收到通知的员工先改为用 QQ 了，而未收到通知的员工还在用邮件，这样一来自然就会发生大量的消息丢失。

那么我们能不能通知员工在未来的某个时刻统一换用 QQ 呢？仔细一想也是不行的。因为每个员工的手表不可能是完全对准的，总是有的快点有的慢点，只要不能保证所有员工的时间完全校准，总有那么一个不一致的时刻。

下面让我们来看看 Google 的工程师们是怎么解决这个棘手的问题的。

在未知中构建已知

根据上面的讨论，最根本的难点在于无法保证所有员工同时改变通信方式，这基本上是不可能做到的。本来员工都在用邮件，一旦通知发布出去，员工的工作方式就完全是未知的了——在任意一个时刻，任意一个员工都可能收到过通知而换用 QQ，也可能没收到通知而继续用邮件。

如果从现实层面来考虑，员工即使是离得远些，一段足够长的时间以后也应该能收到通知。员工的时间即使是没校准，也不至于错得太离谱。所以我们可以认为在足够长的时间过后，所有员工应该都已经换用 QQ 了。

我们可以使用一系列方案使“足够长的时间”变成“确定长度的时间”。首先，公司创建一个网站张贴最新的员工手册，其中自然包含员工应使用的通信方式等细则。其次，在员工入职时进行培训，要求员工每隔 30 分钟必须上网查看一下员工手册，并依照最新的手册行事。另外，如果出现网络故障等情况，员工在尝试访问网站 10 分钟后还没有看到新的手册，必须立即停止工作，直到重新看到手册为止。

基于这些规定，我们就至少可以知道从通知发布之后的某个时刻开始，所有工作中的员工都已经更新自己的通信方式了。例如我们中午 12:00 在网站上张贴新的手册，员工从 12:00 到 12:30 开始陆续查看手册并换用 QQ，到 12:30 时所有员工都应该尝试过访问网站了，到 12:40 时所有未能看到手册的员工都已经停止了工作，这时我们就可以认为所有工作中的员工都在用 QQ 了。如果再考虑手表时快时慢等特殊情形，我们不妨再多等 20 分钟。到了 13:00 ，我们可以非常自信地说：现在所有员工都换用 QQ 了。

在此基础之上，我们再规定两次修改员工手册的时间间隔不能少于 1 小时。例如在 QQ 之后我们还想换用微信，那么最早只能在 13:00 发布新的员工手册。根据前面的讨论，13:00 已经没有员工用邮件了，所以在整个演化过程中，有些时刻邮件和 QQ 同时被使用，有些时刻 QQ 和微信同时被使用，但一定不会发生邮件和微信同时被使用的情况。也就是说，在员工手册不断更新的过程中，最多只有两份手册生效：最新发布的这一份以及上一份。

在矛盾中构建一致

上面我们设计了大量的规定和方案，最后只得到了不那么强的结论，看起来对问题的解决并没有什么帮助。不难发现问题的关键在于邮件和 QQ 这两种通信方式是矛盾不兼容的，只要有一个时刻有员工用邮件而有员工用 QQ，那么就很可能会造成消息丢失。

那么问题的本质其实是：在通信方式由邮件变成 QQ 的过程中，邮件和 QQ 这两种通信方式不能同时生效。

请回想一下上一节中我们得到过的结论，邮件和微信一定不可能同时被使用……你想到了吗？

BING！没错，只要我们在邮件和 QQ 中间加入一个其他的通信方式 X 作为过渡，因为同时只有两种连续的手册生效，邮件和 QQ 就很自然地被隔离了。很显然通信方式 X 一定不是微信，它一定是同时与邮件和 QQ 兼容的，在这里 X 的定义可以是：同时从邮件和 QQ 查收消息，发送消息时邮件和 QQ 各发送一遍。

以上就是 F1 schema 变更的主要思想了。具体在 F1 schema 变更的过程中，由于数据库本身的复杂性，有些变更无法由一个中间状态隔离，我们需要设计多个逐步递进的状态来进行演化。万变不离其宗，只要我们保证任意相邻两个状态是相互兼容的，整个演化的过程就是可依赖的。

F1 中的算法实现

租约

F1 中 schema 以特殊的 kv 对存储于 Spanner 中，同时每个 F1 服务器在运行过程中自身也维护一份拷贝。为了保证同一时刻最多只有 2 份 schema 生效，F1 约定了长度为数分钟的 schema 租约，所有 F1 服务器在租约到期后都要重新加载 schema 。如果节点无法重新完成续租，它将会自动终止服务并等待被集群管理设施重启。

中间状态

前面已经提过，F1 在 schema 变更的过程中，会把一次 schema 的变更拆解为多个逐步递进的中间状态。实际上我们并不需要针对每种 schema 变更单独设计中间状态，总共只需要两种就够了： delete-only 和 write-only 。

delete-only 指的是 schema 元素的存在性只对删除操作可见。

例如当某索引处于 delete-only 状态时，F1 服务器中执行对应表的删除一行数据操作时能“看到”该索引，所以会同时删除该行对应的索引，与之相对的，如果是插入一行数据则“看不到”该索引，所以 F1 不会尝试新增该行对应的索引。

具体的，如果 schema 元素是 table 或 column ，该 schema 元素只对 delete 语句生效；如果 schema 元素是 index ，则只对 delete 和 update 语句生效，其中 update 语句修改 index 的过程可以认为是先 delete 后再 insert ，在 delete-only 状态时只处理其中的 delete 而忽略掉 insert 。

总之，只要某 schema 元素处于 delete-only 状态，F1 保证该 schema 元素对应的 kv 对总是能够被正确地删除，并且不会为此 schema 元素创建任何新的 kv 对。

write-only 指的是 schema 元素对写操作可见，对读操作不可见。

例如当某索引处于 write-only 状态时，不论是 insert 、 delete ，或是 update ，F1 都保证正确的更新索引，只是对于查询来说该索引仍是不存在的。

简单的归纳下就是 write-only 状态的 schema 元素可写不可读。

示例推演

Google 论文的叙述过程是描述完两种中间状态后就开始了冗长的形式化推导，最后得以证明按照特定的步骤来做 schema 演化是能保证一致性的。这里我想先拿出一个例子把 schema 变更的过程推演一遍，这样形成整体印象后更有助于看懂证明：）我们以添加索引为例，对应的完整 schema 演化过程如下：

absent --> delete only --> write only --(reorg)--> public

其中 delete-only 和 write-only 是介绍过了的中间状态。 absent 指该索引完全不存在，也就是schema变更的初始状态。 public 自然对应变更完成后就状态，即索引可读可写，对所有操作可见。

reorg 指 “database reorganization”，不是一种 schema 状态，而是发生在 write-only 状态之后的一系列操作。这些操作是为了保证在索引变为 public 之前所有旧数据的索引都被正确地生成。

根据之前的讨论，F1 中同时最多只可能有两份 schema 生效，我们逐个步骤来分析。

先看 absent 到 delete-only 。很显然这个过程中不会出现与此索引相关的任何数据。

再看 delete-only 到 write-only 。根据 write-only 的定义，一旦某节点进入 write-only 状态后，任何数据变更都会同时更新索引。当然，不可能所有节点同时进入 write-only 状态，但我们至少能保证没有节点还停留在 absent 状态， delete-only 或 write-only 状态的节点都能保证索引被正确清除。于是我们知道：从 write-only 状态发布时刻开始，数据库中不会存在多余的索引。

接下来是 reorg ，我们来考察 reorg 开始时数据库的状态。首先因为 delete-only 的存在，我们知道此时数据库中不存在多余的索引。另外此时不可能有节点还停留在 delete-only 状态，我们又知道从这时起，所有数据的变更都能正确地更新索引。所以 reorg 要做的就是取到当前时刻的snapshot，为每条数据补写对应的索引即可。当然 reorg 开始之后数据可能发生变更，这种情况下底层Spanner提供的一致性能保证 reorg 的写入操作要么失败（说明新数据已提前写入），要么被新数据覆盖。

基于前面的讨论，到 reorg 完成时，我们的数据不少不多也不错乱，可以放心地改为 public 状态了。

证明过程简介

这里简单介绍下证明过程，以理解为主，详细情况可自行查阅论文。

我们定义数据库表示为存储引擎中所有 kv 对的集合。数据库表示 d 对于 schema S 是一致的，当且仅当

1. d 中不存在多余数据。
2. d 中的数据是完整的。

其中不存在多余数据要求：

1. d 中的列数据或索引必须是 S 中定义过的列或索引。
2. d 中所有索引都指向合法的行。
3. d 中不存在未知数据。

数据的完整性要求：

1. public 状态的行或索引是完整的。
2. public 状态的约束是满足的。

我们要求正确实现所有 delete, update, insert 或 query 操作，保证其对于任何schema S ，都不破坏数据库表示的一致性。

我们定义schema S1 至 S2 的变更过程是保持一致的，当且仅当

1. 任何 S1 所定义的操作 OPs1 都保持数据库表示 d 对于 S2 的一致性。
2. 任何 S2 所定义的操作 OPs2 都保持数据库表示 d 对于 S1 的一致性。

这里看起来第 2 点是没必要的，但确实是必须的，因为 F1 中在变更发生的过程中 S1 和 S2 是会同时生效的。我们考虑为 table 添加一列 optional 列 C 的变更（ optional 表示允许该列在数据库表示 d 中不存在，对应于 SQL 中未定义 NOT NULL 或有 DEFAULT 的情况）。首先， S2 定义的 insert 操作会写入 C 列的数据，其产生的数据库表示 d' 对 S2 是一致的，但对 S1 是不一致的（有多余数据）。现在如果发起由 S1 定义的 delete 操作， C 列对应的数据就不能被正确删除了。

显然根据定义，我们有如下推论：schema S1 至 S2 的变更过程是保持一致的，当且仅当 S2 至 S1 的变更过程也是保持一致的。

接下来我们可以得出如下结论：任何从 schema S1 至 S2 的变更，如果其添加或删除了一项 public schema 元素 E ，那么此变更不能保持一致性。

我们先考虑添加 E 的情况。不论 E 是 table, column 或 index ，由 S2 定义的 insert 都将插入 S1 未定义的数据，所以 S1 至 S2 的变更不能保持一致性。根据上面的“可逆”推论，删除的情况也得证。

接下来我们要证明：任何从 schema S1 至 S2 的变更，如果其添加了一项 delete-only schema 元素 E ，那么此变更过程保持一致。

因为 S1 和 S2 上定义的任何操作都不会为 E 创建数据，显然不会产生多余数据。又因为 E 不处于 public 状态，自然也不会破坏数据完整性。所以该变更保持一致性。

接下来我们要证明：任何从 schema S1 至 S2 的变更，如果其将一项 delete-only 状态的 schema optional 元素 E 置为 public ，那么此变更过程保持一致。

因为 S1 和 S2 上定义的 delete 操作都能正确地删除 E 所对应的 kv 对，不会产生多余数据。由于 S1 中 E 是 delete-only ， S1 所定义的 insert 不会为 E 写入对应的数据，但是因为 E 是 optional 的，数据的缺失最终不会影响一致性。所以该变更过程保持一致。

到这里，我们就有了针对添加 optional schema 元素的完整变更方案：

absent --> delete-only --> public

删除 schema 元素以及添加删除 required 元素的情况都是类似的推导过程，这里就不再赘述了，具体可参考论文。

TiDB 的异步 schema 变更实现

背景

现在一般数据库在进行 DDL 操作时都会锁表，导致线上对此表的 DML 操作全部进入等待状态（有些数据支持读操作，但是也以消耗大量内存为代价），即很多涉及此表的业务都处于阻塞状态，表越大，影响时间越久。这使得 DBA 在做此类操作前要做足准备，然后挑个天时地利人和的时间段执行。为此，架构师们在设计整个系统的时候都会很慎重的考虑表结构，希望将来不用再修改。但是未来的业务需求往往是不可预估的，所以 DDL 操作无法完全避免。由此可见原先的机制处理 DDL 操作是令许多人都头疼的事情。本文将会介绍 TiDB 是如何解决此问题的。

解决方案

根据 Google F1 的在线异步 schema 变更算法实现，并做了一些简单优化。为了简化设计，整个系统同一时刻只允许一个节点做 schema 变更。这里先说明一下，本文不会讲述 Google F1 schema 算法推导过程，对此算法不了解的可以直接阅读论文原文或者本书前一章节。

DDL的分类：

由于 bootstrap 操作时需要修改 DDL，这样就产生了鸡生蛋，蛋生鸡的依赖问题。所以需要将 DDL 分成两类，静态 DDL 和动态 DDL。系统 bootstrap 阶段只使用静态 DDL，同时必须在一个事务内完成，而后续所有的操作只允许使用动态 DDL。

引入新概念：

• 元数据记录：为了简化设计，引入 system database 和 system table 来记录异步 schema 变更的过程中的一些元数据。
• State：根据 F1 的异步 schema 变更过程，中间引入了一些状态，这些状态要和 column，index， table 以及 database 绑定， state 主要包括 none, delete only, write only, write reorganization, public。前面的顺序是在创建操作的时候的，删除操作的状态与它的顺序相反，write reorganization 改为 delete reorganization，虽然都是 reorganization 状态，但是由于可见级别是有很大区别的，所以将其分为两种状态标记。
• Lease：同一时刻系统所有节点中 schema 最多有两个不同的版本，即最多有两种不同状态。正因为如此，一个租期内每个正常的节点都会自动加载 schema 的信息，如果不能在租期内正常加载，此节点会自动退出整个系统。那么要确保整个系统的所有节点都已经从某个状态更新到下个状态需要 2 倍的租期时间。
• Job： 每个单独的 DDL 操作可看做一个 job。在一个 DDL 操作开始时，会将此操作封装成一个 job 并存放到 job queue，等此操作完成时，会将此 job 从 job queue 删除，并在存入 history job queue，便于查看历史 job。
• Worker：每个节点都有一个 worker 用来处理 job。
• Owner：整个系统只有一个节点的 worker 能当选 owner 角色，每个节点都可能当选这个角色，当选 owner 后 worker 才有处理 job 的权利。owner 这个角色是有任期的，owner 的信息会存储在 KV 层中。worker定期获取 KV 层中的 owner 信息，如果其中 ownerID 为空，或者当前的 owner 超过了任期，则 worker 可以尝试更新 KV 层中的 owner 信息（设置 ownerID 为自身的 workerID），如果更新成功，则该 worker 成为 owner。在租期内这个用来确保整个系统同一时间只有一个节点在处理 schema 变更。
• Background operations：主要用于 delete reorganization 的优化处理，跟前面的 worker 处理 job 机制很像。所以引入了 background job， background job queue， background job history queue， background worker 和 background owner，它们的功能跟上面提到的角色功能一一对应，这里就不作详细介绍。

变更流程

通过上面的章节可以了解异步 schema 变更的基本概念，本章节会将这些基本点串联成具体的变更流程。这里在讲述流程的时候会对 MySQL Client 端， MySQL Protocol 层和 KV 层的操作也会一笔带过，只介绍 TiDB SQL 层中处理异步 schema 变更的流程。
基本流程如图 1，下面将详细介绍每个模块以及具体流程。

图 1 结构流程图

模块

• TiDB Server：包含了 TiDB 的 MySQL Protocol 层和 TiDB SQL 层，图中主要描述的是 TiDB SQL 层中涉及到异步 schema 变更的基本模块。
• load schema：是在每个节点（这个模块跟之前提到的 worker 一样，便于理解可以这样认为）启动时创建的一个 gorountine， 用于在到达每个租期时间后去加载 schema，如果某个节点加载失败 TiDB Server 将会自动挂掉。此处加载失败包括加载超时。
• start job：是在 TiDB SQL 层接收到请求后，给 job 分配 ID 并将之存入 KV 层，之后等待 job 处理完成后返回给上层，汇报处理结果。
• worker：每个节点起一个处理 job 的 goroutine，它会定期检查是否有待处理的 job。 它在得到本节点上 start job 模块通知后，也会直接去检查是否有待执行的 job 。
• owner：可以认为是一个角色，信息存储在 KV 层，其中包括记录当前当选此角色的节点信息。
• job queue：是一个存放 job 的队列，存储在 KV 层，逻辑上整个系统只有一个。
• job history queue：是一个存放已经处理完成的 job 的队列，存储在 KV 层，逻辑上整个系统只有一个。

基本流程

本小节描述的是异步 DDL 变更的整体流程，忽略实现细节。假设系统中只有两个节点，TiDB Server 1 和 TiDB Server 2。其中 TiDB Server 1 是 DDL 操作的接收节点， TiDB Server 2 是 owner。如下图 2 展示的是在 TiDB Server 1 中涉及的流程，图 3 展示的是在 TiDB Server 2 中涉及的流程。

图 2 TiDB Server 1 流程图

图 3 TiDB Server 2 流程图

1. MySQL Client 发送给 TiDB Server 一个更改 DDL 的 SQL 语句请求。
2. 某个 TiDB Server 收到请求（MySQL Protocol 层收到请求进行解析优化），然后到达 TiDB SQL 层进行执行。这步骤主要是在 TiDB SQL 层接到请求后，会起个 start job 的模块根据请求将其封装成特定的 DDL job，然后将此 job 存储到 KV 层， 并通知自己的 worker 有 job 可以执行。
3. 收到请求的 TiDB Server 的 worker 接收到处理 job 的通知后，判断自身是否处于 owner 的角色，如果处于 owner 角色则直接处理此 job，如果没有处于此角色则退出不做任何处理。图中我们假设没有处于此角色，那么其他的某个 TiDB Server 中肯定有一个处于此角色的，如果那个处于 owner 角色节点的 worker 通过定期检测机制来检查是否有 job 可以被执行时，发现了此 job，那么它就会处理这个 job。
4. 当 worker 处理完 job 后， 它会将此 job 从 KV 层的 job queue 中移除，并放入 job history queue。
5. 之前封装 job 的 start job 模块会定期去 job history queue 查看是否有之前放进去的 job 对应 ID 的 job，如果有则整个 DDL 操作结束。
6. TiDB Server 将 response 返回 MySQL Client。

详细流程

本小节以在 Table 中添加 column 为例详细介绍 worker 处理 job 的整个流程，具体流程如图 4 。考虑到与前面章节的连续性，图 4 可以理解为是图 2 和图 3 的展开描绘。

图 4 add column 流程图

便于在之后介绍中获取信息的方式，此处贴出了 job 的结构。

	type Job struct {
		ID       int64      `json:"id"`
		Type     ActionType `json:"type"`
		SchemaID int64      `json:"schema_id"`
		TableID  int64      `json:"table_id"`
		State    JobState   `json:"state"`
		Error    string     `json:"err"`
		// every time we meet an error when running job, we will increase it
		ErrorCount int64         `json:"err_count"`
		Args       []interface{} `json:"-"`
		// we must use json raw message for delay parsing special args.
		RawArgs     json.RawMessage `json:"raw_args"`
		SchemaState SchemaState     `json:"schema_state"`
		// snapshot version for this job.
		SnapshotVer uint64 `json:"snapshot_ver"`
		// unix nano seconds
		// TODO: use timestamp allocated by TSO
		LastUpdateTS int64 `json:"last_update_ts"`
	}

TiDB Server 1 流程

1. start job 给 start worker 传递了 job 已经准备完成的信号。
2. worker 开启一个事务，检查自己是否是 owner 角色，结果发现不是 owner 角色（此处跟先前的章节保持一致，假设此节点 worker 不是 owner 角色），则提交事务退出处理 job 的循环，回到 start worker 等待信号的循环。

TiDB Server 2 流程

1. start worker 中的定时器到达时间。
2. 开启一个事务，检查发现本节点为 owner 角色。
3. 从 KV 层获取队列中第一个 job（假设就是 TiDB Server 1 之前放入的 job），判断此 job 的类型并对它做相应的处理。
4. 此处 job 的类型为 add column，然后流程到达图中 get column information 步骤。
     a.取对应 table info（主要通过 job 中 schemaID 和 tableID 获取），然后确定添加的 column 在原先的表中不存在或者为不可见状态。
     b.如果新添加的 column 在原先表中不存在，那么将新 column 信息关联到 table info。
     c.在前面两个步骤中发生某些情况会将此 job 标记为 cancel 状态，并返回 error，到达图中 returns error 流程。比如发现对应的数据库、数据表的状态为不存在或者不可见（即它的状态不为 public），发现此 column 已存在并为可见状态等一些错误，这里就不全部列举了。
5. schema 版本号加 1。
6. 将 job 的 schema 状态和 table 中 column 状态标记为 delete only， 更新 table info 到 KV 层。
7. 因为 job 状态没有 finish（即 done 或者 cancel 状态），所以直接将 job 在上一步更新的信息写入 KV 层。
8. 在执行前面的操作时消耗了一定的时间，所以这里将更新 owner 的 last update timestamp 为当前时间（防止经常将 owner 角色在不同服务器中切换），并提交事务。
9. 循环执行步骤 2、 3、 4.a、5、 6、 7 、8，不过将6中的状态由 delete only 改为 write only。
10. 循环执行步骤 2、 3、 4.a、5、 6、 7 、8，不过将6中的状态由 write only 改为 write reorganization。
11. 循环执行步骤 2、 3、 4.a、5，获取当前事务的快照版本，然后给新添加的列填写数据。通过应版本下需要得到的表的所有 handle（相当于 rowID），出于内存和性能的综合考量，此处处理为批量获取。然后针对每行新添加的列做数据填充，具体操作如下（下面的操作都会在一个事务中完成）：
      a.用先前取到的 handle 确定对应行存在，如果不存在则不对此行做任何操作。
      b.如果存在，通过 handle 和 新添加的 columnID 拼成的 key 获取对应列。获取的值不为空则不对此行做任何操作。
      c.如果值为空，则通过对应的新添加行的信息获取默认值，并存储到 KV 层。
      d.将当前的 handle 信息存储到当前 job reorganization handle 字段，并存储到 KV 层。假如 12 这个步骤执行到一半，由于某些原因要重新执行 write reorganization 状态的操作，那么可以直接从这个 handle 开始操作。
12. 将调整 table info 中 column 和 index column 中的位置，将 job 的 schema 和 table info 中新添加的 column 的状态设置为设置为public， 更新 table info 到 KV 层。最后将 job 的状态改为 done。
13. 因为 job 状态已经 finish，将此 job 从 job queue 中移除并放入 job history queue 中。
14. 执行步骤8，与之前的步骤一样 12， 13， 14 和 15 在一个事务中。

TiDB Server 1 流程

1. start job 的定时检查触发后，会检查 job history queue 是否有之前自己放入 job queue 中的 job（通过 jobID）。如果有则此 DDL 操作在 TiDB SQL 完成，上抛到 MySQL Protocol 层，最后返回给 Client， 结束这个操作。

优化

对删除数据库，删除数据表等减少一个状态，即 2 倍 lease 的等待时间，以及删除数据库或者数据表中大量数据所消耗的时间。原本对于删除操作的状态变化是 public -> write only -> delete only -> delete reorganization -> none，优化的处理是去掉 delete reorganization 状态，并把此状态需要处理的元数据的操作放到 delete only 状态时，把具体删除数据的操作放到后台处理，然后直接把状态标为 none。
这相对原来设计的主要有两点不同，下面介绍下做如此优化是否对数据完整性和一致性有影响。

• 将删除具体数据这个操作异步处理了。因为在把数据放到后台删除前，此数据表（假设这里执行的是删除表操作，后面提到也这么假设）的元数据已经删除，对外已经不能访问到此表了，那么对于它们下面的具体数据就更不能访问了。这里可能有人会有疑问那异步删除模块是怎么访问的具体数据的，将元数据事先存在 job 信息中，就这么简单。只要保证先删除元数据（保证此事务提交成功）再异步删除具体数据是不会有问题的。
• 去掉了 delete reorganization 状态。本来 delete only 以及之前的状态都没做修改所以必然是没问题的，那么就是考虑 none 这个状态，即当整个系统由于接到变更信息先后不同处于 delete only 以及 none 这两个状态。那么就分析在这个状态下有客户端希望对此表进行一些操作。
• 客户端访问表处于 none 状态的 TiDB Server。这个其实更没有做优化前是一致的，即访问不到此表，这边不过多解释。
• 客户端访问表处于 delete only 状态的 TiDB Server。此时客户端对此表做读写操作会失败，因为 delete only 状态对它们都不可见。

实现

此优化对于原先的代码逻辑基本没有变化，除了对于删除操作（目前还只是删除数据库和表操作）在其处于 delete only 状态时，就会把元数据删除，而对起表中具体数据的删除则推迟到后台运行，然后结束 DDL job。放到后台运行的任务的流程跟之前处理任务的流程类似，详细过程如下：

1. 在图 4 中判定 finish 操作为 true 后，判断如果是可以放在后台运行（暂时还只是删除数据库和表的任务），那么将其封装成 background job 放入 background job queue， 并通知本机后台的 worker 将其处理。
2. 后台 job 也有对应的 owner，假设本机的 backgroundworker 就是 background owner 角色，那么他将从 background job queue 中取出第一个 background job， 然后执行对应类型的操作（删除表中具体的数据）。
   如果执行完成，那么从 background job queue 中将此 job 删除，并放入 background job history queue 中。
   注意步骤2和步骤 3需要在一个事务中执行。

总结

以上内容是 TiDB 的异步 schema 变更实现的基本内容介绍，可能有些流程细节没有讲解清晰，如果对本人的描述或者对实现有疑问的欢迎到 issues 讨论。

摘自https://github.com/ngaut/builddatabase/tree/d68e8383499677fc257b5ec7c824ab80ea94744f/f1