用户命令：通过网络连上gh-ost，通过命令让它暂停。
动态可控
如果别的工具在修改过程中产生了比较高的负载，DBA只好把它停掉再修改配置，比如把一次拷贝的数据量改小些，然后再从头开始修改过程。这样的反复操作代价非常大。
gh-ost通过监听TCP或者unix socket文件来获取命令。即使有正在进行中的修改工作，用户也可以向gh-ost发出命令修改配置，比如可以这样做：
echo throttle | socat - /tmp/gh-ost.sock：这是暂停命令。也可以输入no-throttle
修改运行参数，gh-ost可以接受这样的修改方式来改变它的行为：chunk-size=1500, max-lag-millis=2000, max-load=Thread_running=30
可审计
用上面所说的相同接口也可以查看gh-ost的状态，查看当前任务进度、主要配置参数、相关MySQL实例的情况等。这些信息通过网络发送命令就可以得到，因此就给了运维人员极大的灵活性，如果是使用别的工具的话一般只能是通过共享屏幕或者不断跟踪日志文件最新内容。
可测试
读取二进制文件内容的操作完全不会增加主库的负载，在从库上做修改表结构的操作也和在主库上做是非常相象的(当然并不完全一样，但主要来说还是差不多的)。
gh-ost自带了--test-on-replica选项来支持测试功能，它允许你在从库上运行起修改表结构操作，在操作结束时会暂停主从复制，让两张表都处于同步、就绪状态，然后切换表、再切换回来。这样就可以让用户从容不迫地对两张表进行检查和对比。
在GitHub是这样在生产环境测试gh-ost的：有许多个指定的生产从库，在上面不提供服务，只是周而复始地不断地把所有表定义都改来改去。对于生产环境地每一张表，小到空表，大到几百GB，都会通过修改存储引擎的方式来进行修改(engine=innodb),这样并不会真正修改表结构。在每一次这样的修改操作最后都会停掉主从复制，再把原始表和临时表的全量数据都各做一次校验和，然后比较两个校验和，要求它们是一致的。然后恢复主从复制，再继续测试下一张表。Github生产环境的每一张表都这样用gh-ost在从库上做过好多次修改测试。
可靠性高
所有上述讲到的和没讲到的内容，都是为了让你对gh-ost的能力建立信任。毕竟，大家在做这件事的时候已经使用类似工具做了好多年，而gh-ost只是一个新工具。
Github在从库上对gh-ost进行测试，在去主库上做第一次真正改动之前在从库上成功地试了几千次。所以，请你也在从库上开始测试，验证数据是完好无损的，然后再把它用到生产环境。希望你可以放手去试。
当你执行了gh-ost之后，也许你会看见主库的负载变高了，那你可以发出暂停命令。用echo throttle命令生成一个文件，看看主库的负载会不会又变得正常。试一下这些命令，你就可以知道你可以怎样控制它的行为，你的心里就会安定许多。
你发起了一次修改操作，然后估计完成时间是凌晨2点钟，可是你又非常关心最后的切换操作，非常想看着它切换，这可怎么办?只需要一个标志位文件就可以告诉gh-ost推迟切换了，这样gh-ost会只做完拷贝数据的操作，但不会切换表。它还会仍然继续同步数据，保持临时表的数据处于同步状态。等第二天早上你回到办公室之后，删除标志位文件或者向gh-ost发送命令echo unpostpone，它就会做切换了。没有人希望软件强迫自己看着它做事情，它应该把大家解放出来，让人去做人该做的事。
谈到估计完成时间，--exact-rowcount选项非常有用。在最开始时要在目标表上做个代价比较大的SELECT COUNT(*)操作查出具体要拷多少行数据，gh-ost就会对它要做多少工作有了一个比较准确的估计。接下来在拷贝的过程中，它会不断地尝试更新这个估计值。因为预计完成的时间点总是会不断变化，所以已经完成的百分比就反而比较精确。如果你也曾经有过非常痛苦的经历，看着已经完成99%了可是剩下的一点操作却继续了一个小时也没完，你就会非常喜欢gh-ost提供的这个功能。
gh-ost工作模式
gh-ost工作时可以连上多个MySQL实例，同时也把自己以从库的方式连上其中一个实例来获取二进制日志事件。根据你的配置、数据库集群架构和你想在哪里执行修改操作，可以有许多种不同的工作模式。