介绍 gh-ost 之前，先来简单了解一下在这之前基于触发器的工具原理。考虑一下 Online DDL 实际上可以粗糙的分成几步：

  1. 根据原来的表结构执行 alter 语句，新建一个更新表结构之后的表，通常称为幽灵表。对用户不可见。
  2. 把原来表的已有数据 copy 到幽灵表。
  3. 在 copy 的过程中，会有新的数据过来，这些数据要同步到幽灵表，也就是 “Online” 的精髓。
  4. 删除源表（可选），完成 online DDL。

这其中比较重要的第三步，如何同步增量的数据。最开始办法就是使用触发器，在源表上增加几个触发器，例如当源表执行 INSERT，UPDATE，DELETE 语句，就把这些操作通过触发器同步到幽灵表上，这样在幽灵表上执行的语句和源表的语句就属于同一个事务，显然这样会影响主库的性能。

后面出现了异步的模式，使用触发器把对源表的操作保存到一个 Changelog 表中，不真正的去执行，专门有一个后台的线程从 Changelog 表读取数据应用到幽灵表上。这种方式一定程度上缓解了主库的压力，但是保存到 Changelog 表也同样是属于同一个事务中，对性能也有不小的影响。

  • Triggers, overhead: 触发器是用存储过程的实现的，就无法避免存储过程本身需要的开销。
  • Triggers, locks: 增大了同一个事务的执行步骤，更多的锁争抢。
  • Trigger based migration, no pause: 整个过程无法暂停，假如发现影响主库性能，停止 Online DDL，那么下次就需要从头来过。
  • Triggers, multiple migrations: 他们认为多个并行的操作是不安全的。
  • Trigger based migration, no reliable production test: 无法在生产环境做测试。
  • Trigger based migration, bound to server: 触发器和源操作还是在同一个事务空间。

从上面的描述可以看出，触发器的作用是源表和幽灵表之间的增量数据同步，gh-ost 放弃了触发器，使用 binlog 来同步。gh-ost 作为一个伪装的备库，可以从主库/备库上拉取 binlog，过滤之后重新应用到主库上去，相当于主库上的增量操作通过 binlog 又应用回主库本身，不过是应用在幽灵表上。引用一下的图：

gh-ost 首先连接到主库上，根据 alter 语句创建幽灵表，然后作为一个”备库“连接到其中一个真正的备库上，一边在主库上拷贝已有的数据到幽灵表，一边从备库上拉取增量数据的 binlog，然后不断的把 binlog 应用回主库。图中 cut-over 是最后一步，锁住主库的源表，等待 binlog 应用完毕，然后替换 gh-ost 表为源表。gh-ost 在执行中，会在原本的 binlog event 里面增加以下 hint 和心跳包，用来控制整个流程的进度，检测状态等。这种架构带来诸多好处，例如：

  • 整个流程异步执行，对于源表的增量数据操作没有额外的开销，高峰期变更业务对性能影响小。
  • 降低写压力，触发器操作都在一个事务内，gh-ost 应用 binlog 是另外一个连接在做。
  • 可测试，gh-ost 提供了测试功能，可以连接到一个备库上直接做 Online DDL，在备库上观察变更结果是否正确，再对主库操作，心里更有底。
  • 并行操作，对于 gh-ost 来说就是多个对主库的连接。
  • 用户没有 Super 权限，因此使用过程中要加上 –assume-rbr, gh-ost 会认为 binlog 本身就是 row 模式，不会再去修改。阿里云 RDS 上的 binlog 默认也是 row 模式，所以不存在问题。
  • 其它权限，主要是 REPLICATION SLAVE，REPLICATION CLIENT 可以拉取 binlog ，也可以获得。
  • 无法连接到备库拉取 binlog。备库通常对用户来说是透明的，所以 gh-ost 需要直接连接到主库上去，这可能会增大对主库的负载。使用的时候需要增加 –allow-on-master， –assume-master-host。官方推荐的方式也是连接到其中一个备库，因为会有一些压力较大的 SELECT 操作，放在备库是最好的。几种连接模式如下图所示：

gh-ost-operation-modes.png

当有用户反馈无法在阿里云 RDS 上使用 gh-ost 的时候，我们着手进行了排查，发现在 Github 上已经有热心的用户 dikang123, 在 issue #470 中进行了讨论，原因是在校验阶段隐藏了两个参数，@@port 和 @@hostname，导致 gh-ost 获得了非法的字符。隐藏的原因是系统架构和安全的考虑，避免用户的端口和主机被恶意攻击。返回非法字符也是出于用户体验，例如 port 本应该是整型，如果返回 0，那么可能会有用户认为自己的数据库端口是 0，但是返回 ‘NULL’，用户就可以接收到明确的隐藏信号。

我们随后向官方提交了 Pull Request 从工具本身解决，经过多次交流和代码 review，决定增加一个参数 –aliyun-rds，这样就可以绕开非法字符的校验。具体的过程可以看下 。

  • –allow-on-master
  • –assume-rbr
  • –assume-master-host
  • –aliyun-rds

gh-ost 在 Online DDL 上确实做出了很大的创新，是一款优秀的工具，并且在很多地方的都有巧妙的设计，例如最后一步 cut-over, ，本文并未详细描述。对于在云数据库上的使用，还有一些额外的限制，未来根据用户的需求，可以和数据库层面做更多的融合。