初试GH-OST（转）

1.创建一个和要执行 alter 操作的表一样的新的空表结构(是alter之前的结构)
2.在新表执行alter table 语句
3.在原表中创建触发器3个触发器分别对应insert,update,delete操作
4.以一定块大小从原表拷贝数据到临时表，拷贝过程中通过原表上的触发器在原表进行的写操作都会更新到新建的临时表
5.Rename 原表到old表中，在把临时表Rename为原表
6.如果有参考该表的外键，根据alter-foreign-keys-method参数的值，检测外键相关的表，做相应设置的处理
7.默认最后将旧原表删除

1.在变更的服务器上 创建 ghost table( _tbname_gho like tbname)
2.更改 _tbname_gho 结构为新表结构
3.作为mysql的slave连接mysql server，并记录新增binlog event
4.交替执行: 应用新增events到 ghost table 和 复制老表的记录到 ghost table
5.table重命名(ghost table 替代 老表)

其中有2种常用用法：
1.连接从库，变更主库 - 默认方式，slave需要开启log-slave-update
2.连接主库，变更主库 - 必须ROW格式，带上参数--allow-on-master"

1.原表必须要有主键或者唯一索引（不含NULL）
2.原表上不能有触发器存在
3.使用前需保证有足够的磁盘容量，因为复制原表需要一倍的空间
4.在阿里RDS 上使用需要增加参数no-version-check

1.原表必须要有主键或者唯一索引（不含NULL）
2.不支持外键
3.不支持触发器
4.不支持虚拟列
5.不支持 5.7 point类型的列
6. 5.7 JSON列不能是主键
7.不能存在另外一个table名字一样，只是大小写有区别
8.不支持多源复制
9.不支持M-M 双写
10.不支持FEDERATED engine

--max-load，默认threads_running=25,可以指定多个指标来限速,每个chunk拷贝完会检查，超过阀值会暂停复制。如果不指定该参数，工具会检查当前运行值并增加20%
--critical-load,默认为threads_running=50,如果不指定，则工具检查当前运行值并当运行到200%是退出工具运行
--max-lag，默认1s，如果发现延迟大于该值，则暂停复制数据。
--check-interval,配合max-lag使用，检查从库超过延时后，该工具睡眠多久
--recursion-method，指定从库的发现机制,processlist,dsn,none 等
--chunk-time,默认0.5秒，拷贝数据行的时候为了保证0.5秒内拷贝完一个chunk，动态调整下一次chunk-size的大小
--[no]check-replication-filters，如果工具检查到服务器选项中有任何复制相关的筛选，工具会报错退出，默认为yes
--chunk-size，指定块大小，默认1000行。

--max-load=Threads_running=25 表面如果在执行gh-ost的过程中出现Threads_running=25则暂停gh-ost的执行
--critical-load=Threads_running=60 表明执行过程中出现Threads_running达到60则终止gh-ost的执行
--chunk-size=1000 设置每次从原表copy到 ghost table的行数
--ok-to-drop-table 执行完之后删除原表
--allow-on-master 直连主库执行

1.读binlog可以放在从库执行，减少主库的压力
2.不需要创建触发器，对原表没有改动

1.需要创建触发器，对原表有改动
2.涉及主键的更改需要review

1.当系统负载极高时，gh-ost有可能无法跟上binlog日志的处理（未测试过该场景）
2.限制比较多，见上文
3.涉及主键的更改需要review