初试GH-OST
最近老板让做一个gh-ost和pt-osc 的对比测试，本文将对两者做对比。
一。原理和所用说明
| PT-OSC | GH-OST | |
| 原理 |
1.创建一个和要执行 alter 操作的表一样的新的空表结构(是alter之前的结构) |
1.在变更的服务器上 创建 ghost table( _tbname_gho like tbname) 其中有2种常用用法： |
| 使用限制 |
1.原表必须要有主键或者唯一索引（不含NULL） |
1.原表必须要有主键或者唯一索引（不含NULL） |
| 重要参数说明 |
–max-load，默认threads_running=25,可以指定多个指标来限速,每个chunk拷贝完会检查，超过阀值会暂停复制。如果不指定该参数，工具会检查当前运行值并增加20% |
–max-load=Threads_running=25 表面如果在执行gh-ost的过程中出现Threads_running=25则暂停gh-ost的执行 |
| 优点 | 1.执行速度快，业界使用比较广泛，较稳定 |
1.读binlog可以放在从库执行，减少主库的压力 |
| 风险点 |
1.需要创建触发器，对原表有改动 |
1.当系统负载极高时，gh-ost有可能无法跟上binlog日志的处理（未测试过该场景） |
| 运行命令实例 | pt-online-schema-change –user=db_monitor –password=xxx –host=127.0.0.1 –port=xxx –alter “add COLUMN c2 varchar (120) not null default ”” D=sbtest,t=sbtest1 –no-check-replication-filters –alter-foreign-keys-method=auto –recursion-method=none –print –execute | ./gh-ost –assume-master-host=ip:port –master-user=db_monitor –master-password=xxx –user=db_monitor –password=yyy –host=10.xxx –port=port –alter=”ADD COLUMN c2 varchar(120)” –database=sbtest –table=”sbtest1″ -execute –initially-drop-old-table –initially-drop-socket-file –initially-drop-ghost-table |
二，性能测试对比
1. 测试场景
16core CPU，2G buffer pool的测试实例，5.5的MySQL版本异步主从，2kw行记录，4.8GB 测试表大小
2. 测试结果（不限速），复制延时用zabbix 监控seconds behind master 的值
3. 结果展示
三， 最后说一下GH-OST的 cut over
gh-ost利用了MySQL的一个特性，就是原子性的rename请求，在所有被blocked的请求中，优先级永远是最高的。
gh-ost基于此设计了该方案：一个连接对原表加锁，另启一个连接尝试rename操作，此时会被阻塞住，当释放lock的时候，rename会首先被执行，其他被阻塞的请求会继续应用到新表。
参考资料：
https://github.com/github/gh-ost
https://m.aliyun.com/yunqi/articles/62928
http://www.tabdba.com/?p=175