• 无触发器：这也是其他工具最受诟病之处。触发器方案会对MySQL的性能造成比较大的影响，严重时甚至会拖垮主库。
• 轻量级：gh-ost获取数据表修改操作的方法是伪装成从库连入，获取并解析二进制日志，对临时表插入数据也是增量、可控制的，因此对MySQL主库的性能几乎无影响。
• 可暂停：当原主库处于业务高峰期时，完全可以暂停gh-ost的操作，暂停就意味着对主库没有写入和更新，这是非常受欢迎的。
• 动态可控：gh-ost的操作不但可以暂停，还可以动态修改，因此在各种情况下修改了配置之后都不必从头开始重新运行整个修改过程，这是非常节约资源的。
• 可审计：gh-ost的状态是可以非常容易获取到的，包括当前任务进度、主要配置参数、相关MySQL实例的情况等。gh-ost通过监听TCP或者unix socket文件来获取命令，因此就给了运维人员极大的灵活性。
• 可测试：gh-ost支持在从库上进行测试，以观察对系统负载的影响、验证正确性等。GitHub生产环境的每一张表都这样用gh-ost在从库上做过好多次修改测试，他们也呼吁大家用这种方式先体验gh-ost的功能，再考虑上线应用。
• 可靠性高：经过充分的测试之后，现在GitHub生产环境的修改表定义操作已经全部由gh-ost完成了，而且它还有暂停、延迟切换、准确估计任务进度等功能，审计和在线控制功能可以让它轻松地与监控系统结合起来，必然非常受运维人员喜爱。
• 完美解决切换问题：表切换操作是在线修改表定义的最后一步，其它工具操作到这一步时常常会出现各种问题。Facebook OSC也曾详细分析过这个问题，但它的最终方案是个非原子性切换：先把原始表改名，再把临时表改名顶上。可惜在两次改名中间会有一小段表不存在的时间，在这期间运行的业务语句都会失败，因为目标表不存在。Shlomi等经过严密的论证和实验，给出了原子性的两阶段切换方案：用一条连接去持有锁，另一条连接做原子性的rename操作。在rename操作之前，会创建一张信号表，用它来阻塞rename操作，直到所有要求的表切换前提条件就绪。根据这个方案，表切换或者成功，皆大欢喜；或者失败，则对业务无影响，也不会丢失数据，还会释放锁让业务继续，DBA只需要再一次用gh-ost重新尝试切换即可。

名称栏目：在线更改MySQL表结构工具gh-ost的特点介绍
当前URL：http://www.tsicrk.com/article/jhccdj.html