ghost是github的在线变更工具。下面是翻译的github介绍ghost的文档。
之前使用了pt的工具来做变更，但是很多的变更需要放在周末，业务低峰期做，一些重要的业务表还无法变更，pt工具是使用了触发器的，触发器有下面的一些问题,没用过mysql的触发器，下面的问题也没有遇到过：
• Stored routines
• Interpreted, not compiled. Latency added to each transaction
• Locks
• Transaction space competes for multiple, uncoordinated locks
• Metadata locks
• Unsuspendible
• Even as throtling is required, triggers must continue to work
• Concurrent migrations
• Trust issues
• No reliable testing
• Either cannot test in production, or test does not get actual write workload
ghost是基于binlog的
ghost作为replic连接拉取binlog的实体
将dml操作的信息解析转换成，来满足重构的表结构，在ghost表上应用。
ghost连接到master上迭代每一行。一个chunk一个chunk的处理，从元彪拷贝行到ghost表，这种处理方式跟别的工具处理方式都一致。
维护一个用于内部轻量簿记的“更新日志”表
这种方式几乎是对原表无任何影响的。
ghost推荐连接到副本去拉取binlog,而不影响主库
ghost可以控制整个的数据流，它可以真正加速，暂停所有写入迁移的服务器上
gh-ost的设计是按顺序发出所有写入，完全避免了锁争用的问题，迁移server只能看到单一连接的写入，迁移算法简单。
ghost的迁移方式：
gh-ost migration:
- creates ghost table on migrated server
- alters ghost table
- hooks up as a MySQL replica, streams binary log events
- interchangeably:
- applies events on ghost table
- copies rows from original table onto ghost table
- cut-over
Preferred setup:
- connects to replica
- inspects table structure, table dimensions on replica
- hooks as replica onto replica
- apply all changes on master
- writes internal & heartbeat events onto master,
expects them on replica
限流
基于下面的因素限流
• Master metrics
• Replication lag
• Arbitrary query
• HTTP endpoint
• Flag file
• Use command
ghost提供延时的切换，这个是可以选，可配置的。
作为切入准备，gh-ost只是通过binlog事件来保持表的同步
需要明确的命令/提示来切换
亚秒级别的复制延时，在github上他们能将复制延时控制在300ms。
动态的可见性和控制
如果正在运行的配置不满足你的要求，你可以kill掉任务，然后使用新的配置开始一个新的任务。
可以对运行中的任务进行
status
• max-lag-millis=500
• throtle
• cut-over
