1. gh-ost工作模式
gh-ost有三种工作模式：
a:
连接到从库，在主库做迁移。
b:
连接到主库，迁移过程所有操作都在主上操作，包括读取binlog等等。
c:
在从库做迁移测试。
三种方法各有优缺点，先说a的缺点，a会在从上面读取binlog,但数据库主从数据为什么会造成不一致，一个很重要的原因是主库的binlog没有完全在从库执行。
所以感觉a方法有丢失数据的风险。b方法任何操作都会再主库操作，或多或少会对主库负载造成影响，但是可以通过调整一些参数降低和时刻关注这些影响.
至于c方法是偏向测试用的，这里不做过多介绍，但是c方法里有一个细节，cut-over阶段有会stop slave一个操作,其实这个操作风险特别高，
有时stop slave 时间会很长，务必会对线上数据库使用造成影响，所以如果使用c方法做测试也要在线下数据库。
2.参数介绍。
gh-ost参数很多，但我使用到的有限，这里只对使用到的参数进行介绍，再强调一下，这里测试的是b方法。
--max-load
迁移过程中，gh-ost会时刻关注负载情况，负载阀值是使用者自己定义，比如数据库的最大连接数，如果超过阀值，gh-ost不会退出，会等待到负载在阀值以下继续执行。
--critical-load
这个指的是gh-ost退出阀值，当负载超过这个阀值，gh-ost会停止并退出
--chunk-size
迁移过程是一步步分批次完成的，这个参数是指事务每次提交的行数，默认是1000。
--max-lag-millis
会监控从库的主从延迟情况，如果延迟秒数超过这个阀值，迁移不会退出，等待延迟秒数低于这个阀值继续迁移。
--throttle-control-replicas
和--max-lag-millis参数相结合，这个参数指定主从延迟的数据库实例。
--initially-drop-ghost-table
gh-ost执行前会创建两张xx_ghc和xx_gho表，如果这两张表存在,且加上了这个参数，那么会自动删除原gh表，从新创建，
否则退出。xx_gho表相当于老表的全量备份，xx_ghc表数据是数据更改日志，理解成增量备份。
--initially-drop-socket-file
gh-ost执行时会创建socket文件，退出时不会删除，下次执行gh-ost时会报错，加上这个参数会删除老的socket文件，重新创建。
--ok-to-drop-table
go-ost执行完以后是否删除老表，加上此参数会自动删除老表。
--host
数据库实例地址。
--port
数据库实例端口。
--user
数据库实例用户名。
--password
数据库实例密码。
--database
数据库名称。
--table
表名。
-verbose
--alter
操作语句。
--cut-over
自动执行rename操作。
--debug
输出详细日志。
--panic-flag-file
这个文件被创建，迁移操作会被立即终止退出。
--execute
如果确定执行，加上这个参数。
--allow-on-master
整个迁移所有操作在主库上执行，也就是数的b方法。
--throttle-flag-file
此文件存在时操作暂停，删除文件操作会继续。
./gh-ost -host="192.168.15.104" --max-load=Threads_connected=3000
-port=3306 -user="dlan" -password="root123" -database="aaa" -table="team_member_20161109"
--alter="add column yuhao2 char(11)" --allow-on-master --initially-drop-ghost-table --initially-drop-old-table
-initially-drop-ghost-table --initially-drop-ghost-table --initially-drop-socket-file --initially-drop-socket-file
--ok-to-drop-table --cut-over=default --execute
以上测试加的参数，测试的心碎，2事务就出问题
