type
status
date
slug
summary
tags
category
icon
password
GitHub's online schema migration for MySQL:
HOW?

- 建立一張和原表結構相同的
ghost
表
- ALTER
ghost
表
-
gh-ost
偽裝成SLAVE
從Master/Slave
拉取binlog
將資料寫入 ghost
表
- 將
binlog event
應用到ghost
表
- 從原表複製
rows
到ghost
表
- 切換
ghost
表和原表
上述的步驟中可以看出
Why triggerless?gh-ost
的大部分和其他online DDL 工具大體相同,唯一的不同處就是 gh-ost
不是基於 trigger
。 gh-ost
的開發團隊認為使用 trigger
有許多的限制與風險,可參照:取而代之的是
gh-ost
透過 binlog
來獲取原表資料的改動,並將之異步應用到 ghost
表。 gh-ost
承擔了其他工具留給 DATABASE 執行的任務(trigger
),等於是完全分離了遷移資料時的寫Loading和 DATABASE 服務本身的 Loading,因此 gh-ost
可能更好的控制整個遷移的過程,可以做到真正的暫停。 Highlights
- No
trigger
:這是gh-ost
的特點,基於trigger
的方案會對MySQL
的性能造成較大的影響。gh-ost
解析binlog
後寫入數據,不僅可控對MySQL
的性能影響也很小。
- 真正的暫停:當
gh-ost
進入throttle
狀態時,gh-ost
真正停止了對MASTER
的寫入(除了必要的低負載的心跳紀錄),讓MASTER
可以回到原始的 Loading 狀態。
- 動態控制:即使已經開始運行
gh-ost
,也可以透過交互式命令
隨時重新配置gh-ost
部分參數,甚至你可以強制讓gh-ost
進入throttle
狀態。
- 可審核:可以透過
unix socket
、TCP
或table _ghc
查詢gh-ost
狀態。
- 可測試:
gh-ost
可以在SLAVE
進行遷移,用以觀察 Loading 和 正確性後再投入使用。
- 控制切換階段:
cut over
是gh-ost
最關鍵的一個步驟,你可以隨時決定cut over
的時間。
- 外部 hook:
gh-ost
提供hook
功能,例如:可以用於推送到SLACK
群組告知進度。
如何運作
執行步驟解析 cut over 階段
Cut over要求與限制
要求與限制Shared key
Shared key參數
常用的參數如下:
其他參數可以參考:
參數