GitHub 开源的 MySQL 在线更改 Schema 工具

[Goodapp]

MySQL 在线更改 schema 的工具很多，如 Percona 的pt-online-schema-change、 Facebook 的 OSC 和 LHM 等，但这些都是基于触发器（ Trigger ）的，今天咱们介绍的 gh-ost 号称是不需要触发器（ Triggerless ）支持的在线更改表结构的工具。

原文地址：gh-ost: GitHub's online schema migration tool for MySQL

本文先介绍一下当前业界已经存在的这些工具的使用场景和原理，然后再详细介绍 gh-ost 的工作原理和特性。

今天我们开源了 GitHub 内部使用的一款 不需要触发器支持的 MySQL 在线更改表结构的工具 gh-ost

开发 gh-ost 是为了应付 GitHub 在生产环境中面临的持续的、不断变化的在线修改表结构的需求。gh-ost 通过提供低影响、可控、可审计和操作友好的解决方案改变了现有的在线迁移表工具的工作模式。

MySQL 表迁移及结构更改操作是业界众所周知的问题， 2009 年以来已经可以通过在线（不停服务）变更的工具来解决。迅速增长，快速迭代的产品往往需要频繁的需改数据库的结构。增加 /更改 /删除 / 字段和索引等等，这些操作在 MySQL 中默认都会锁表，影响线上的服务。 向这种数据库结构层面的变更我们每天都会面临多次，当然这种操作不应该影响用户的正常服务。

在开始介绍 gh-ost 工具之前，咱们先来看一下当前现有的这些工具的解决方案。

在线修改表结构，已存在的场景

如今，在线修改表结构可以通过下面的三种方式来完成：

• 在从库上修改表结构，操作会在其他的从库上生效，将结构变更了的从库设置为主库
• 使用 MySQL InnoDB 存储引擎提供的在线 DDL 特性
• 使用在线修改表结构的工具。现在最流行的是 pt-online-schema-change 和 Facebook 的 OSC；当然还有 LHM 和比较原始的 oak-online-alter-table 工具。

其他的还包括 Galera 集群的 Schema 滚动更新，以及一些其他的非 InnoDB 的存储引擎等待，在 GitHub 我们使用通用的 主-从 架构 和 InnoDB 存储引擎。

为什么我们决定开始一个新的解决方案，而不是使用上面的提到的这些呢？现有的每种解决方案都有其局限性，下文会对这些方式的普遍问题简单的说明一下，但会对基于触发器的在线变更工具的问题进行详细说明。

• 基于主从复制的迁移方式需要很多的前置工作，如：大量的主机，较长的传输时间，复杂的管理等等。变更操作需要在一个指定的从库上或者基于 sub-tree 的主从结构中执行。需要的情况也比较多，如：主机宕机、主机从早先的备份中恢复数据、新主机加入到集群等等，所有这些情况都有可能对我们的操作造成影响。最要命的是可能这些操作一天要进行很多次，如果使用这种方法我们操作人员每天的效率是非常高的（译者注：现如今很少有人用这种方式了吧）

• MySQL 针对 Innodb 存储引擎的在线 DDL 操作在开始之前都需要一个短时间排它锁(exclusive)来准备环境，所以 alter 命令发出后，会首先等待该表上的其它操作完成，在 alter 命令之后的请求会出现等待 waiting meta data lock 。同样在 ddl 结束之前，也要等待 alter 期间所有的事务完成，也会堵塞一小段时间，这对于繁忙的数据库服务来说危险系数是非常高的。另外 DDL 操作不能中断，如果中途 kill 掉，会造成长时间的事务回滚，还有可能造成元数据的损坏。它操作起来并不那么的 Nice ，不能限流和暂停，在大负载的环境中甚至会影响正常的业务。

• 我们用了很多年的 pt-online-schema-change 工具。然而随着我们不断增长的业务和流量，我们遇到了很多的问题，我们必须考虑在操作中的哪些 危险操作 （译者注： pt 工具集的文档中经常会有一些危险提示）。某些操作必须避开高峰时段来进行，否则 MySQL 可能就挂了。所有现存的在线表结构修改的工具都是利用了 MySQL 的触发器来执行的，这种方式有一些潜藏的问题。

基于触发器的在线修改有哪些问题呢？

所有在线表结构修改工具的操作方式都类似：创建与原表结构一致的临时表，该临时表已经是按要求修改后的表结构了，缓慢增量的从原表中复制数据，同时记录原表的更改(所有的 INSERT, DELETE, UPDATE 操作) 并应用到临时表。当工具确认表数据已经同步完成，它会进行替换工作，将临时表更名为原表。

pt-online-schema-change, LHM 和 oak-online-alter-table 这些工具都使用同步的方式，当原表有变更操作时利用一些事务的间隙时间将这些变化同步到临时表。 Facebook 的工具使用异步的方式将变更写入到 changelog 表中，然后重复的将 changelog 表的变更应用到临时表。所有的这些工具都使用触发器来识别原表的变更操作。

当表中的每一行数据有 INSERT, DELETE, UPDATE 操作时都会调用存储的触发器。一个触发器可能在一个事务空间中包含一系列查询操作。这样就会造成一个原子操作不单会在原表执行，还会调用相应的触发器执行多个操作。

在基于触发器迁移实践中，遇到了如下的问题：

• 触发器是以解释型代码的方式保存的。 MySQL 不会预编译这些代码。 会在每次的事务空间中被调用，它们被添加到被操作的表的每个查询行为之前的分析和解释器中。

• 锁表: 触发器在原始表查询中共享相同的事务空间，而这些查询在这张表中会有竞争锁，触发器在另外一张表会独占竞争锁。在这种极端情况下，同步方式的锁争夺直接关系到主库的并发写性能。以我们的经验来说，在生产环境中当竞争锁接近或者结束时，数据库可能会由于竞争锁而被阻塞住。触发锁的另一个方面是创建或销毁时所需要的元数据锁。我们曾经遇到过在繁忙的表中当表结构修改完成后，删除触发器可能需要数秒到分钟的时间。

• 不可信：当主库的负载上升时，我们希望降速或者暂停操作，但基于触发器的操作并不能这么做。虽然它可以暂停行复制操作，但却不能暂停出触发器，如果删除触发器可能会造成数据丢失，因此触发器需要在整个操作过程中都要存在。在我们比较繁忙的服务器中就遇到过由于触发器占用 CPU 资源而将主库拖死的例子。

• 并发迁移: 我们或者其他的人可能比较关注多个同时修改表结构（不同的表）的场景。鉴于上述触发器的开销，我们没有兴趣同时对多个表进行在线修改操作，我们也不确定是否有人在生产环境中这样做过。

• 测试：我们修改表结构可能只是为了测试，或者评估其负载开销。基于触发器的表结构修改操作只能通过基于语句复制的方式来进行模拟实验，离真实的主库操作还有一定的距离，不能真实的反映实际情况。

gh-ost

gh-ost GitHub 的在线 Schema 修改工具，下面工作原理图：

gh-ost 具有如下特性:

• 无触发器
• 轻量级
• 可暂停
• 可动态控制
• 可审计
• 可测试
• 值得信赖 :blush:

无触发器

gh-ost 没有使用触发器。它通过分析 binlog 日志的形式来监听表中的数据变更。因此它的工作模式是异步的，只有当原始表的更改被提交后才会将变更同步到临时表（ ghost table ）

gh-ost 要求 binlog 是 RBR 格式 ( 基于行的复制)；然而也不是说你就不能在基于 SBR （基于语句的复制）日志格式的主库上执行在线变更操作。实际上是可以的。 gh-ost 可以将从库的 SBR 日志转换为 RBR 日志，只需要重新配置就可以了。

轻量级

由于没有使用触发器，因此在操作的过程中对主库的影响是最小的。当然在操作的过程中也不用担心并发和锁的问题。 变更操作都是以流的形式顺序的写到 binlog 文件中， gh-ost 只是读取他们并应用到 gh-ost 表中。实际上， gh-ost 通过读取 binlog 的写事件来进行顺序的行复制操作。因此，主库只会有一个单独连接顺序的将数据写入到临时表（ ghost table ）。这和 ETL 操作有很大的不同。

可暂停

所有的写操作都是由 gh-ost 控制的，并且以异步的方式读取 binlog ，当限速的时候， gh-ost 可以暂停向主库写入数据，限速意味着不会在主库进行复制，也不会有行更新。当限速时 gh-ost 会创建一个内部的跟踪（ tracking ）表，以最小的系统开销向这个表中写入心跳事件

gh-ost 支持多种方式的限速：

• 负载: 为熟悉 pt-online-schema-change 工具的用户提供了类似的功能，可以设置 MySQL 中的状态阈值，如 Threads_running=30
• 复制延迟: gh-ost 内置了心跳机制，可以指定不同的从库，从而对主从的复制延迟时间进行监控，如果达到了设定的延迟阈值程序会自动进入限速模式。
• 查询: 用户可以可以设置一个限流 SQL ，比如 SELECT HOUR(NOW()) BETWEEN 8 and 17 这样就可以动态的设置限流时间。
• 标示文件: 可以通过创建一个标示文件来让程序限速，当删除文件后可以恢复正常操作。
• 用户命令: 可以动态的连接到 gh-ost (下文会提到) 通过网络连接的方式实现限速。

可动态控制

现在的工具，当执行操作的过程中发现负载上升了， DBA 不得不终止操作，重新配置参数，如 chunk-size ，然后重新执行操作命令，我们发现这种方式效率非常低。

gh-ost 可以通过 unix socket 文件或者 TCP 端口（可配置）的方式来监听请求，操作者可以在命令运行后更改相应的参数，参考下面的例子：

• echo throttle | socat - /tmp/gh-ost.sock 打开限速，同样的，可以使用 no-throttle 来关闭限流。
• 改变执行参数: chunk-size=1500, max-lag-millis=2000, max-load=Thread_running=30 这些参数都可以在运行时变更。

可审计

同样的，使用上文提到的程序接口可以获取 gh-ost 的状态。gh-ost 可以报告当前的进度，主要参数的配置以及当前服务器的标示等等。这些信息都可以通过网络接口取到，相对于传统的 tail 日志的方式要灵活很多。

可测试

因为日志文件和主库负载关系不大，因此在从库上执行修改表结构的操作可以更真实的体现出这些操作锁产生的实际影响。(虽然不是十分理想，后续我们会做优化工作)。

gh-ost 內建支持测试功能，通过使用 --test-on-replica 的参数来指定: 它可以在从库上进行变更操作，在操作结束时gh-ost 将会停止复制，交换表，反向交换表，保留 2 个表并保持同步，停止复制。可以在空闲时候测试和比较两个表的数据情况。

这是我们在 GitHub 的生产环境中的测试：我们生产环境中有多个从库；部分从库并不是为用户提供服务的，而是用来对所有表运行的连续覆盖迁移测试。我们生产环境中的表，小的可能没有数据，大的会达到数百 GB ，我们只是做个标记，并不会正在的修改表结构（ engine=innodb ）。当每一个迁移结束后会停止复制，我们会对原表和临时表的数据进行完整的 checksum 确保他们的数据一致性。然后我们会恢复复制，再去操作下一张表。我们的生产环境的从库中已经通过 gh-ost 成功的操作了很多表。

值得信赖

上文提到说了这么多，都是为了提高大家对 gh-ost 的信任程度。毕竟在业界它还是一个新手，类似的工具已经存在了很多年了。

• 在第一次试手之前我们建议用户先在从库上测试，校验数据的一致性。我们已经在从库上成功的进行了数以千计的迁移操作。

• 如果在主库上使用 gh-ost 用户可以实时观察主库的负载情况，如果发现负载变化很大，可以通过上文提到的多种形式进行限速，直到负载恢复正常，然后再通过命令微调参数，这样可以动态的控制操作风险。

• 如果迁移操作开始后预完成计时间（ ETA ）显示要到夜里 2 点才能完成，结束时候需要切换表，你是不是要留下来盯着？你可以通过标记文件让 gh-ost 推迟切换操作。 gh-ost 会完成行复制，但并不会切换表，它会持续的将原表的数据更新操作同步到临时表中。你第二天来到办公室，删除标记文件或者通过接口 echo unpostpone 告诉 gh-ost 开始切换表。我们不想让我们的软件把使用者绑住，它应该是为我们拜托束缚。

• 说到 ETA, --exact-rowcount 参数你可能会喜欢。相对于一条漫长的 SELECT COUNT(*) 语句， gh-ost 会预估出迁移操作所需要花费的时间，还会根据当前迁移的工作状况更新预估时间。虽然 ETA 的时间随时更改，但进度百分比的显示是准确的。

gh-ost 操作模式

gh-ost 可以同时连接多个服务器，为了获取二进制的数据流，它会作为一个从库，将数据从一个库复制到另外一个。它有各种不同的操作模式，这取决于你的设置，配置，和要运行迁移环境。

a. 连接到从库，在主库做迁移

这是 gh-ost 默认的工作方式。 gh-ost 将会检查从库状态，找到集群结构中的主库并连接，接下来进行迁移操作：

• 行数据在主库上读写
• 读取从库的二进制日志，将变更应用到主库
• 在从库收集表格式，字段&索引，行数等信息
• 在从库上读取内部的变更事件（如心跳事件）
• 在主库切换表

如果你的主库的日志格式是 SBR ，工具也可以正常工作。但从库必须启用二级制日志(log_bin, log_slave_updates) 并且设置 binlog_format=ROW ( gh-ost 是读取从库的二级制文件)。

如果直接在主库上操作，当然也需要二进制日志格式是 RBR 。

b. 连接到主库

如果你没有从库，或者不想使用从库，你可以直接在主库上操作。gh-ost 将会直接在主库上进行所有操作。你需要持续关注复制延迟问题。

• 你的主库的二进制日志必须是 RBR 格式。
• 在这个模式中你必须指定 --allow-on-master 参数

c. 在从库迁移 /测试

该模式会在从库执行迁移操作。 gh-ost 会简单的连接到主库，此后所有的操作都在从库执行，不会对主库进行任何的改动。整个操作过程中， gh-ost 将控制速度保证从库可以及时的进行数据同步

• --migrate-on-replica 表示 gh-ost 会直接在从库上进行迁移操作。即使在复制运行阶段也可以进行表的切换操作。
• --test-on-replica 表示 迁移操作只是为了测试在切换之前复制会停止，然后会进行切换操作，然后在切换回来，你的原始表最终还是原始表。两个表都会保存下来，复制操作是停止的。你可以对这两个表进行一致性检查等测试操作。

gh-ost at GitHub

我们已经在所有线上所有的数据库在线操作中使用了 gh-ost ，我们每天都需要使用它，根据数据库修改需求，可能每天要运行多次。凭借其审计和控制功能我们已经将它集成到了ChatOps流程中。我们的工程师可以清醒的了解到迁移操作的进度，而且可以灵活的控制其行为。

开源

gh-ost 在MIT 的许可下发布到了开源社区。

虽然 gh-ost 在使用中很稳定，我们还在不断的完善和改进。我们将其开源也欢迎社会各界的朋友能够参与和贡献。随后我们会发布 贡献和建议的页面。

我们会积极的维护 gh-ost 项目，同时希望广大的用户可以尝试和测试这个工具，我们做了很大努力使之更值得信赖。

译者注

gh-ost 是 MySQL 业界在线修改表结构工具中的一名新秀，通常我们都是通过 Percona 的 pt-online-schema-change 工具来做这项工作， gh-ost 的出现给我们带来了一种全新的方式。本文是翻译了一篇 gh-ost 的介绍文章，还没有尝试过这个工具。欢迎喜欢尝鲜网友谈谈使用感受。

---

好雨社区原创翻译