無觸發器：這也是其他工具最受詬病之處。觸發器方案會對MySQL的效能造成比較大的影響，嚴重時甚至會拖垮主庫。
輕量級：gh-ost獲取資料表修改操作的方法是偽裝成從庫連入，獲取並解析二進位制日誌，對臨時表插入資料也是增量、可控制的，因此對MySQL主庫的效能幾乎無影響。
可暫停：當原主庫處於業務高峰期時，完全可以暫停gh-ost的操作，暫停就意味著對主庫沒有寫入和更新，這是非常受歡迎的。
動態可控：gh-ost的操作不但可以暫停，還可以動態修改，因此在各種情況下修改了配置之後都不必從頭開始重新執行整個修改過程，這是非常節約資源的。
可審計：gh-ost的狀態是可以非常容易獲取到的，包括當前任務進度、主要配置引數、相關MySQL例項的情況等。gh-ost透過監聽TCP或者unix socket檔案來獲取命令，因此就給了運維人員極大的靈活性。
可測試：gh-ost支援在從庫上進行測試，以觀察對系統負載的影響、驗證正確性等。GitHub生產環境的每一張表都這樣用gh-ost在從庫上做過好多次修改測試，他們也呼籲大家用這種方式先體驗gh-ost的功能，再考慮上線應用。
可靠性高：經過充分的測試之後，現在GitHub生產環境的修改表定義操作已經全部由gh-ost完成了，而且它還有暫停、延遲切換、準確估計任務進度等功能，審計和線上控制功能可以讓它輕鬆地與監控系統結合起來，必然非常受運維人員喜愛。
完美解決切換問題：表切換操作是線上修改表定義的最後一步，其它工具操作到這一步時常常會出現各種問題。Facebook OSC也曾詳細分析過這個問題，但它的最終方案是個非原子性切換：先把原始表改名，再把臨時表改名頂上。可惜在兩次改名中間會有一小段表不存在的時間，在這期間執行的業務語句都會失敗，因為目標表不存在。Shlomi等經過嚴密的論證和實驗，給出了原子性的兩階段切換方案：用一條連線去持有鎖，另一條連線做原子性的rename操作。在rename操作之前，會建立一張訊號表，用它來阻塞rename操作，直到所有要求的表切換前提條件就緒。根據這個方案，表切換或者成功，皆大歡喜；或者失敗，則對業務無影響，也不會丟失資料，還會釋放鎖讓業務繼續，DBA只需要再一次用gh-ost重新嘗試切換即可。

線上更改MySQL表結構工具gh-ost的特點介紹

相關文章