GitHub 解釋了他們在 MySQL 上 ALTER TABLE 的方式：「gh-ost: GitHub's online schema migration tool for MySQL」。
GitHub 的舊方式是使用 pt-online-schema-change，會遇到的問題有幾個，其中看起來只有 Non pausability 這個是真正的痛點：
Non pausability: when load on the master turns high, you wish to throttle or suspend your pending migration. However a trigger-based solution cannot truly do so. While it may suspend the row-copy operation, it cannot suspend the triggers. Removal of the triggers results in data loss. Thus, the triggers must keep working throughout the migration. On busy servers, we have seen that even as the online operation throttles, the master is brought down by the load of the triggers.
當開始後，多出來的 trigger 是沒有辦法停下來的 (停下來就代表要全部重來)，而且會影響線上服務。
新的方式則是用 replication 做，多一台機器出來跑，等結束後再切換，而中間有任何過程也都很好處理：
這方法手筆比較大，不過對於系統已經有規模的組織來說不是問題... 看起來以後可以朝這個方向研究 XD
我們也做過差不多的, 只是手動來做而沒有一個工具
先從 slave 們慢慢一台一台加 index/alter table; 最後才 swap master 的方式比較快而沒有 replication bomb; 也可以正確 predict 所要花的時間
可惜 gh-ost 好像主張 table-swap 而不是 db-swap
還是會有 double-write on master 和 replication bomb 的可能