1、连上从库，在主库上修改
这是gh-ost默认的工作模式，它会查看从库情况，找到集群的主库并且连接上去。修改操作的具体步骤是：
在主库上读写行数据;
在从库上读取二进制日志事件，将变更应用到主库上;
在从库上查看表格式、字段、主键、总行数等;
在从库上读取gh-ost内部事件日志(比如心跳);
在主库上完成表切换;
如果主库的二进制日志格式是Statement，就可以使用这种模式。但从库就必须配成启用二进制日志(log_bin, log_slave_updates)，还要设成Row格式(binlog_format=ROW)，实际上gh-ost会在从库上帮你做这些设置。
事实上，即使把从库改成Row格式，这仍然是对主库侵入最少的工作模式。
2、连上主库
如果没有从库，或者不想在从库上操作，那直接用主库也是可以的。gh-ost就会在主库上直接做所有的操作。仍然可以在上面查看主从复制延迟。
主库必须产生Row格式的二进制日志;
启动gh-ost时必须用--allow-on-master选项来开启这种模式;
3、在从库上修改和测试
这种模式会在从库上做修改。gh-ost仍然会连上主库，但所有操作都是在从库上做的，不会对主库产生任何影响。在操作过程中，gh-ost也会不时地暂停，以便从库的数据可以保持最新。
--migrate-on-replica选项让gh-ost直接在从库上修改表。最终的切换过程也是在从库正常复制的状态下完成的。
--test-on-replica表明操作只是为了测试目的。在进行最终的切换操作之前，复制会被停止。原始表和临时表会相互切换，再切换回来，最终相当于原始表没被动过。主从复制暂停的状态下，你可以检查和对比这两张表中的数据。
gh-ost在GitHub的应用
现在Github生产环境的表修改操作全都是用gh-ost完成的。每天只要有需求来了，技术人员就把它运行起来，有时候一天会做好多次。因为它有审计和控制功能，所以还可以把它和Chatops系统整合起来。技术人员可以对它的工作进度有非常清晰的了解，因此可以控制它的行为。在生产环境中各种指标和事件都被收集起来，让大家可以以图形化的方式看到操作情况。
开源
gh-ost按照 MIT许可协议 向开源社区 发布 。
尽管现在已经稳定了，Github还是有一些想要继续改进的方面，因此现在把它发布出来，希望能得到来自于社区的参与和贡献。Github也会不断把社区提供的建议等公布出来。
Github的技术团队还在积极维护gh-ost。希望你能试用一下，他们花了很大的精力，相信它是非常可靠的。