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

2024-07-24 12:31:44

字體：大中小

來源：轉載

供稿：網友

無觸發器：這也是其他工具最受詬病之處。觸發器方案會對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數據庫啟動過程的闡述

下一篇：Linux平臺卸載MySQL概括