最近公司进行了阿里云迁移，将所有服务器迁移到阿里云后，在对rds进行ddl的时候，发现原来的pt工具无法正常使用，主要表现在连接数据库的时候等待，将原始表数据拷贝到中间表时缓慢，变更过程中一直提示连不上RDS。虽然使用pt-osc可以对小表变更，但是对大表DDL的时候太过缓慢，而且一直连接中断。所以只能寻找新的工具gh-ost。
针对gh-ost的原理，实现步骤，变更方式以及优点限制不再赘述，可以参考官网或者以下链接。本篇博客主要记录我对gh-ost的使用。
官网
https://github.com/github/gh-ost
http://mysql.taobao.org/monthly/2018/05/02
参数解析
https://yq.aliyun.com/articles/62928
下载安装
https://github.com/github/gh-ost/releases
安装特别简单 下载rpm包后直接 rpm -ivh 安装
rpm -ivh gh-ost-1.0.47-1.x86_64.rpm
或者下载二进制压缩包后直接解压就可以使用
tar zxvf gh-ost-binary-linux-20180527215024.tar.gz
参数说明
--host
数据库实例地址。
--port
数据库实例端口。
--user
数据库实例用户名。
--password
数据库实例密码。
--database
数据库名称。
--table
表名称。
--alter
ALTER语句的body部分，如”ALTER TABLE wing ADD COLUMN id int not null default 0”，使用gh-ost的--alter参数时，写成--alter ADD COLUMN id int not null default 0即可。
--allow-on-master
默认情况下gh-ost希望你连接一个从库进行binlog获取。如果你想连接主库进行整个迁移操作，需要加上此选项即可。gh-ost提供了三种方案连接方案。
--max-load
迁移过程中，gh-ost会时刻关注负载情况，负载阀值是使用者自己定义，比如数据库的最大连接数，如果超过阀值，gh-ost不会退出，会等待到负载在阀值以下继续执行。
--critical-load
这个指的是gh-ost退出阀值，当负载超过这个阀值，gh-ost会停止并退出。
--max-lag-millis
会监控从库的主从延迟情况，如果延迟秒数超过这个阀值，迁移不会退出，等待延迟秒数低于这个阀值继续迁移。这个是迁移中很大的一个问题，特别是在从库迁移时。
gh-ost监控复制延迟是通过检查gh-ost本身在实用程序更新日志表中注入的心跳事件来衡量的。也就是说，为了测量这个复制延迟，gh-ost不需要发出show slave status命令，也没有任何外部心跳机制。
当提供--throttle-control-replicas时，限流还会考虑指定主机上的延迟。通过查询gh-ost的更新日志表（其中gh-ost注入心跳）完成列出的主机上的延迟时间测量。
gh-ost能够利用毫秒测量复制延迟，当--max-lag-millis小于1000，即小于1秒时，gh-ost将进行限流。
--throttle-control-replicas
和–max-lag-millis/code>参数相结合，这个参数指定主从延迟的数据库实例。
--initially-drop-ghost-table
gh-ost在迁移时会创建两张表，分别是”_xx_ghc”和”_xx_gho”，gh-ost非正常退出时不会清理掉。如果这两张表存在，且加上了这个参数，那么在执行gh-ost时会自动删除原gh表，重新创建，否则退出。_xx_gho表相当于老表的全量备份，_xx_ghc表数据是数据更改日志（Changelog）。
--initially-drop-old-table
gh-ost执行完成后默认不会删除“_xx_del”表（加上ok-to-drop-table参数会在执行完成后删除原表），此表是由gh-ost原子切换时产生（rename table `sbtest`.`xx` to `sbtest`.`_xx_del`, `sbtest`.`_xx_gho` to `sbtest`.`xx`），是存储原表数据。加上此参数时gh-ost会在执行前如果检测到“_xx_del”表存在则进行删除操作（默认不启用该参数，gh-ost直接退出操作），该参数不建议使用，请手动处理原来存在的原数据表。
--initially-drop-socket-file
gh-ost执行时会创建socket文件，非正常退出时不会删除socket文件，下次执行gh-ost时会报错，加上这个参数，gh-ost会强制删除已经存在的socket文件。该参数不建议使用，可能会删除一个正在运行的gh-ost程序，导致DDL失败。
--ok-to-drop-table
gh-ost执行完以后是否删除“_xx_del”表，此表是由gh-ost原子切换时产生（rename table `sbtest`.`xx` to `sbtest`.`_xx_del`, `sbtest`.`_xx_gho` to `sbtest`.`xx`），是存储原表数据。加上此参数会执行完成后自动删除，但是非正常完成退出时无法删除此表，可能就需要借助initially-drop-old-table参数在执行前删除已经存在的“_xx_del”表。该参数不建议使用，请手动处理原表。
--cut-over
自动执行rename操作，选择cut-over类型：atomic/two-step，atomic（默认）类型的cut-over是Github的算法，two-step采用的是facebook-OSC的算法。
--cut-over-lock-timeout-seconds
gh-ost在cut-over阶段最大的锁等待时间，当锁超时时，gh-ost的cut-over将重试。(默认值：3)
--switch-to-rbr
让gh-ost自动将从库的binlog_format转换为ROW格式。
--assume-rbr
确认gh-ost连接的数据库实例的binlog_format=ROW的情况下，可以指定--assume-rbr，这样可以禁止从库上运行stop slave，start slave；执行gh-ost用户也不需要SUPER权限。
--panic-flag-file
这个文件被创建，迁移操作会被立即终止退出。
--throttle-flag-file
此文件存在时操作暂停，删除文件操作会继续。
--postpone-cut-over-flag-file
当这个文件存在的时候，gh-ost的cut-over阶段将会被推迟，直到该文件被删除。
--concurrent-rowcount
该参数如果为True(默认值)，则进行row-copy之后，估算统计行数(使用explain select count(*)方式)，并调整ETA时间，否则，gh-ost首先预估统计行数，然后开始row-copy。
--exact-rowcount
准确统计表行数(使用select count(*)的方式)，得到更准确的预估时间。
--execute
如果确定执行，加上这个参数。
可选参数介绍
--default-retries
各种操作在panick前重试次数。(默认为60)
--chunk-size
迁移过程是一步步分批次完成的，这个参数是指事务每次提交的行数，默认是1000。
--timestamp-old-table
使旧表包含时间戳值，旧表是在成功迁移结束时将原始表重新命名的内容。例如，如果表是gh_ost_test，那么旧表通常是_gh_ost_test_del。使用--timestamp-old-table后，它将是_gh_ost_test_20170221103147_del。
--throttle-http
提供一个HTTP端点，gh-ost将在给定的URL上发出HEAD请求，并在响应状态码不是200时进行限流。URL可以通过交互式命令动态查询和更新，空的URL表示禁用HTTP检查。
--approve-renamed-columns
当做（change old_name new_name …）动作时，gh-ost分析语句以尝试将旧列名称与新列名称相关联，如果它检测到确实是重命名操作，默认情况下将会打印出信息并退出。但除非你提供--approve-renamed-columns，强制发出迁移操作。
如果你认为gh-ost解析错误，并且实际上并且没有重命名，你可以改为传入--skip-renamed-columns，这将导致gh-ost取消关联列值，数据将不会在这些列之间复制。
--skip-foreign-key-checks
默认情况下，gh-ost会验证迁移表中存不存在外键，如果存在就会报错并退出；在具有大量表的服务器上，此检查可能需要很长时间。如果你确定没有外键存在（表没有引用其他表，也没有被其他表引用）并希望保存检查时间，可以使用--skip-foreign-key-checks。但如果表上有外键，使用这个参数则会清除外键，千万注意。
--discard-foreign-keys
该操作很危险，意味着将默默丢弃表上存在的任何外键。目前，gh-ost不支持迁移表上的外键（当它在迁移表上注意到外键时，它会保留）。但是，它能够支持通过此标志删除外键，如果你想这么干，这是一个有用的选项。使用下来感觉跟--skip-foreign-key-checks参数作用一样。
--replica-server-id
gh-ost原理是通过模拟slave从而获得binlog，其默认server-id为99999，如果你运行多个迁移，那么你必须为每个gh-ost进程提供一个不同的，唯一的server-id。也可以使用进程ID当做server-id，例如：--replica-server-id = $((1000000000 + ))。
--migrate-on-replica
通常，gh-ost用于在主服务器上迁移表。如果你只希望在从库上执行全部迁移，使用--migrate-on-replica参数将gh-ost连接到从库进行迁移。
--assume-master-host
默认情况下，gh-ost更倾向连接从库来进行迁移。gh-ost通过爬取复制拓扑来推断主服务器的身份，你可以通过--assume-master-host = the.master.com明确告诉gh-ost主服务器的身份。这在以下方面很有用：
主 – 主拓扑结构（与--allow-master-master一起使用），其中gh-ost可以随意选择其中一个主协同者，这种情况你可以选择一个特定的主库。
tungsten×××拓扑结构（与--tungsten一起使用），其中gh-ost无法抓取并检测主节点。
--dml-batch-size
gh-ost从二进制日志读取事件，并将它们应用到ghost表上。它采用的方式是将多个事件分组应用于单个事务中。这可以提供更好的写入吞吐量，因为我们不需要将每个事务日志同步到的磁盘。
此选项就是控制批量写入的大小，允许的值是1 – 100，其中1表示不分组处理（二进制日志中的每个事件在其自己的事务中应用到ghost表上）。默认值是10。
--heartbeat-interval-millis
用来控制注入心跳事件的频率（就是_xx_ghc表），用来测量主从延迟。你应该设置heartbeat-interval-millis <= max-lag-millis。否则，将失去粒度和效果。默认值100。其--max-lag-millis值应该在300-500之间。
--conf
指定gh-ost凭据的文件，如下格式。
[client]
user=gromit
password=123456
--debug
输出详细日志。
--verbose
执行过程输出日志。