mysql gh 划线,gh-ost：在线DDL修改MySQL表结构工具

在之前，我分享过一次pt-online-schema-change在线DDL的工具实践记录，在实际使用过程中，发现部门的很多老系统大量使用了触发器，从而无法使用这个工具，非常遗憾！导致很多DDL变更都必须压到空闲时候做，比如凌晨，非常苦逼。

咨询了做DBA的老同事，他将gh-ost推荐给我，基于golang语言，是github开源的一个DDL工具，gh-ost是gitHub,s Online Schema Transmogrifier/Transfigurator/Transformer/Thingy的缩写，意思是GitHub的在线表定义转换器。＝＝＝＝＝＝＝＝＝＝＝＝　　分割线之间内容摘自网络　　＝＝＝＝＝＝＝＝＝＝＝＝

gh-ost有如下特点：

无触发器

轻量级

可暂停

动态可控

可审计

可测试

可靠

无触发器

gh-ost不使用触发器，它跟踪二进制日志文件，在对原始表的修改提交之后，用异步方式把这修改内容应用到临时表中去。

gh-ost希望二进制文件使用基于行的日志格式，但这并不表示如果主库上使用的是基于语句的日志格式，就不能用它来在线修改表定义了。事实上，我们常用的方式是用一个从库把日志的语句模式转成行模式，再从这个从库上去读日志。搭一个这样的从库并不复杂。

轻量级

因为不需要使用触发器，gh-ost把修改表定义的负载和正常的业务负载解耦开了。它不需要考虑被修改的表上的并发操作和竞争等，这些在二进制日志中都被序列化了，gh-ost只操作临时表，完全与原始表不相干。事实上，gh-ost也把行拷贝的写操作与二进制日志的写操作序列化了，这样，对主库来说只是有一条连接在顺序的向临时表中不断写入数据，这样的行为与常见的ETL相当不同。

可暂停

因为所有写操作都是gh-ost生成的，而读取二进制文件本身就是一个异步操作，所以在暂停时，gh-ost是完全可以把所有对主库的写操作全都暂停的。暂停就意味着对主库没有写入和更新。不过gh-ost也有一张内部状态跟踪表，即使在暂停状态下也会向那张表中不断写入心跳信息，写入量可以忽略不计。

gh-ost提供了比简单的暂停更多的功能，除了暂停之外还可以做：

负载：与pt-online-schema-change相近的一个功能，用户可以设置MySQL指标的阈值，比如设置Threads_running=30。

复制延迟：gh-ost内置了心跳功能来检查复制延迟。用户可以指定查看哪个从库的延迟，gh-ost默认是直接查看它连上的那个从库。

命令：用户可以写一些命令，根据输出结果来决定要不要开始操作。比如：SELECT HOUR(NOW()) BETWEEN 8 and 17.

上述所有指标即使在修改表定义的过程中也可以动态修改。

标志位文件：生成一个标志位文件，gh-ost就会立刻暂停。删除文件，gh-ost又会恢复工作。

用户命令：通过网络连上gh-ost，通过命令让它暂停。

动态可控

如果别的工具在修改过程中产生了比较高的负载，DBA只好把它停掉再修改配置，比如把一次拷贝的数据量改小些，然后再从头开始修改过程。这样的反复操作代价非常大。

gh-ost通过监听TCP或者unix socket文件来获取命令。即使有正在进行中的修改工作，用户也可以向gh-ost发出命令修改配置，比如可以这样做：

echo throttle | socat - /tmp/gh-ost.sock：这是暂停命令。也可以输入no-throttle

修改运行参数，gh-ost可以接受这样的修改方式来改变它的行为：chunk-size=1500, max-lag-millis=2000, max-load=Thread_running=30

可审计

用上面所说的相同接口也可以查看gh-ost的状态，查看当前任务进度、主要配置参数、相关MySQL实例的情况等。这些信息通过网络发送命令就可以得到，因此就给了运维人员极大的灵活性，如果是使用别的工具的话一般只能是通过共享屏幕或者不断跟踪日志文件最新内容。

可测试

读取二进制文件内容的操作完全不会增加主库的负载，在从库上做修改表结构的操作也和在主库上做是非常相象的(当然并不完全一样，但主要来说还是差不多的)。

gh-ost自带了--test-on-replica选项来支持测试功能，它允许你在从库上运行起修改表结构操作，在操作结束时会暂停主从复制，让两张表都处于同步、就绪状态，然后切换表、再切换回来。这样就可以让用户从容不迫地对两张表进行检查和对比。

我们在GitHub是这样在生产环境测试gh-ost的：我们有许多个指定的生产从库，在上面不提供服务，只是周而复始地不断地把所有表定义都改来改去。对于我们生产环境地每一张表，小到空表，大到几百GB，都会通过修改存储引擎的方式来进行修改(engine=innodb),这样并不会真正修改表结构。在每一次这样的修改操作最后我们都会停掉主从复制，再把原始表和临时表的全量数据都各做一次校验和，然后比较两个校验和，要求它们是一致的。然后我们恢复主从复制，再继续测试下一张表。我们生产环境的每一张表都这样用gh-ost在从库上做过好多次修改测试。

可靠的

所有上述讲到的和没讲到的内容，都是为了让你对gh-ost的能力建立信任。毕竟，大家在做这件事的时候已经使用类似工具做了好多年，而gh-ost只是一个新工具。

我们在从库上对gh-ost进行测试，在去主库上做第一次真正改动之前我们在从库上成功地试了几千次。所以，请你也在从库上开始测试，验证数据是完好无损的，然后再把它用到生产环境。我们希望你可以放手去试。

当你执行了gh-ost之后，也许你会看见主库的负载变高了，那你可以发出暂停命令。用echo throttle命令生成一个文件，看看主库的负载会不会又变得正常。试一下这些命令，你就可以知道你可以怎样控制它的行为，你的心里就会安定许多。

你发起了一次修改操作，然后估计完成时间是凌晨2点钟，可是你又非常关心最后的切换操作，非常想看着它切换，这可怎么办？只需要一个标志位文件就可以告诉gh-ost推迟切换了，这样gh-ost会只做完拷贝数据的操作，但不会切换表。它还会仍然继续同步数据，保持临时表的数据处于同步状态。等第二天早上你回到办公室之后，删除标志位文件或者向gh-ost发送命令echo unpostpone，它就会做切换了。我们不希望软件强迫我们看着它做事情，它应该把我们解放出来，让人去做人该做的事。

谈到估计完成时间，--exact-rowcount选项非常有用。在最开始时要在目标表上做个代价比较大的SELECT COUNT(*)操作查出具体要拷多少行数据，gh-ost就会对它要做多少工作有了一个比较准确的估计。接下来在拷贝的过程中，它会不断地尝试更新这个估计值。因为预计完成的时间点总是会不断变化，所以已经完成的百分比就反而比较精确。如果你也曾经有过非常痛苦的经历，看着已经完成99%了可是剩下的一点操作却继续了一个小时也没完，你就会非常喜欢我们提供的这