gh-ost

基于触发器的 Online DDL 工具

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

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

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

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

在 gh-ost 的文档 中细数了触发器的不足之处，大致有以下几点:

• 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: 触发器和源操作还是在同一个事务空间。