onlineDDL的原理以及Vitess如何帮助处理模式迁移

Vitess 引入了一种运行模式迁移的新方法：非阻塞的、异步的、预定的online DDL。通过 online DDL，Vitess 简化了模式迁移过程，它获得了操作开销的所有权，并为用户提供了一个简单、熟悉的界面：标准的 ALTER TABLE 语句。

让我们首先介绍一些背景知识并解释为什么模式迁移在数据库世界中是一个如此重要的问题，然后深入研究实现细节。 

关系模型和操作开销

关系模型是软件世界中存在时间最长的模型之一，它是几十年前引入的，直到今天仍被广泛使用。SQL 同样古老而可靠，甚至在非关系数据库中也可以找到 SQL 或类似 SQL 的语言。

关系模型对许多常见的用例都有意义，具有属性的实体（分别为表和列）可以很好地映射到流行的结构，如用户、产品、成员关系、消息等，而且 SQL 的表达能力足够强，能够构造简单和复杂的问题。

但从历史上看，关系模型是有代价的。虽然许多数据库系统对读和写进行了优化，但它们对元数据更改（特别是模式更改）的优化程度并不高。此类更改的最大挑战之一是，它们需要一个操作程序，而且大多不在开发人员的领域之内。

在早期，数据库管理员（DBA）充当数据库的保镖是很常见的。他们会拖延来自开发者的“疯狂请求”。变更的要求需要经过漫长的程序和文书工作。

幸运的是，这些日子已经过去了，我们在持续部署和快速开发方面更加协作。然而，新的变化加剧了这个问题。在过去，你需要每月更改一次模式；也许几个月就有一次。你应该为此做好准备，推出一个新的版本。如今，世界上最繁忙的数据库部署每天都要运行多个模式迁移，这并不少见。

这重新引入并强化了模式迁移问题：该过程大部分不在开发人员的领域之内。它要求他们是数据库专家。在每天进行多次迁移的情况下，他们需要以与自己的开发流程不兼容的方式与其他开发人员协作和同步（例如，这与比较和合并 git 分支完全不同）。在小公司中，你会看到开发人员只是在他们认为合适的时候拥有和运行他们的迁移，但这并不能扩展，而且产品和组织越大，就越需要一个更正式的流程。

在 MySQL 世界中，直接的模式迁移是阻塞的，如果不是在主服务器上，那就是在副本上。他们对资源咄咄逼人，无法被打断或压制。在线模式更改工具已经存在了十多年，但是它们引入了自己的复杂性：你需要将它们与数据库一起安装、允许访问、安排执行、登录、执行、通知这些工具如何进行限制、处理错误、为它们的操作提供可见性等等。在规模较大的公司中，有专门的 DBA 或 Ops 团队手动执行模式更改是很常见的。这些团队可以每周甚至每天花费数小时来处理模式迁移的操作开销。

对于开发人员来说，这是一种所有权的丧失。虽然他们有向某个表添加列的想法，但他们需要从外部团队请求帮助，并且常常等待，而对进展状态没有太多的可见性。这就打破了他们的流程。也许 NOSQL 数据库最大的吸引力之一是它们不会对开发人员的流程施加这种级别的约束。

对于 DBA 来说，模式迁移是一种负担。一些开发人员对他们自己的工作流程的意外中断。

操作的一些复杂性

操作开销始于模式迁移跨越多个域这一事实。让我们来看看模式迁移流的不完整分解：

• 正规化：某些人（开发人员？）需要正规化迁移。通常会有人提出一个 CREATE，DROP，或者 ALTER TABLE 语句。这种说法正确吗？它在语法上有效吗？它是否与现有的惯例相冲突？
• 发现：这条语句需要在生产环境的什么地方运行？开发人员可能不知道模式是如何跨不同集群部署的。发现机制是什么？并且，如果我们找到了正确的集群，那么哪个服务器作为该集群的主服务器呢？数据是否分片？如果是，我们如何检测所有的碎片？
• 调度：是否已经在需要的集群上运行了迁移？数据库对并发迁移的反应很差；最好是按顺序运行它们。我们需要等吗？多长时间？如果我们要睡觉，谁来抢我们的空位？我们还会再失去一天的工作吗？
• 执行：我们需要登录到某个服务器上吗？我们应该在哪里运行我们的在线模式迁移工具？我们应该传递什么命令行标志？
• 监控：我们能说说进展情况吗？我们能让所有人都看到吗？当迁移完成时，我们如何通知相关方？
• 清理：MySQL 的模式迁移工具会留下一些工件：需要删除的大型表。删除表本身就是一个问题。我们如何自动清理这些工件？
• 恢复：如果迁移失败，我们如何继续？还有其他的清理工作要做吗？

对于生产环境中的多个集群（其中一些是分片的），用于识别正确的集群的发现机制是什么？用于应用模式更改的集群的主机是？

Vitess 帮助处理模式迁移流程

Vitess 的架构使其处于一个独特的位置，可以处理大多数模式迁移流程。例如：

• 发现是微不足道的。Vitess 在内部将所有模式映射到碎片和集群，并在任何给定时间知道应该在何处应用迁移（或查询）。
• Vitess 模拟了一个单一的数据库。用户通过 vtgate 访问 Vitess，这是一个智能代理，可以从语义上理解查询。当 Vitess 拦截一个查询时，它不必严格地将该查询发送到后端数据库服务器。对于 online DDL，Vitess 会注意模式更改请求，并在之后安排它。适当的后端 tablet 将接收该请求，并各自安排它，以避免运行并发迁移。
• tablet 自己执行在线模式迁移工具。今天，Vitess 支持 pt-online-schema-change 和 gh-ost。tablet 决定如何执行这些工具，提供命令行标志，任何必要的挂钩/插件。而且，在 Linux/amd64 上，gh-ost 是预编译的，并与 Vitess 绑定，所以不需要安装。Vitess 指示工具使用它自己的内部节流机制，因此工具不需要担心要监视哪些副本。节流机制可以动态适应拓扑变化。
• Vitess 提供了一个跨所有碎片查询迁移进度的接口。此外，它还提供了一个接口，用于中止迁移，或重新尝试中止的迁移或失败的迁移。
• Vitess 了解哪些工件是由模式迁移工具生成的。事实上，它指示他们生成什么工件。无论成功还是失败，Vitess 都可以在迁移后进行清理。它将把工件表发送到垃圾收集机制。它将为 pt-osc 迁移清理遗留的触发器。Vitess 为每个迁移创建一个临时帐户，并在迁移完成后销毁它。
• Vitess 知道迁移何时失败，并运行适当的清理，即使 Vitess 本身在迁移过程中失败。此时，Vitess 为故障转移导致的迁移失败提供了一次性的自动重试。

Vitess 知道模式部署在何处、存在哪些碎片、在任何给定时间谁是主节点，并且可以在正确的数据库服务器上应用 DDL，而无需用户干预。

对用户来说是什么样子的？

开发 Vitess online DDL 的目标是尽可能地向用户隐藏所有的复杂性。因此，所有用户需要运行的是：

SET @@ddl_strategy=’gh-ost’;
ALTER TABLE my_table ADD COLUMN some_column INT NOT NULL;

ALTER TABLE 语句本身是完全正常的，但是响应不同。它立即返回，并带有一个作业 ID，用户可以使用该 ID 跟踪迁移的进度。用户可以选择 gh-ost 策略、pt-osc 策略或普通 direct 策略（不是 online DDL）。