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

HOW?

notion image
  • 建立一張和原表結構相同的 ghost
  • ALTER ghost
  • gh-ost 偽裝成 SLAVEMaster/Slave 拉取 binlog
將資料寫入 ghost
  • binlog event 應用到 ghost
  • 從原表複製 rowsghost
  • 切換 ghost 表和原表
上述的步驟中可以看出 gh-ost 的大部分和其他online DDL 工具大體相同,唯一的不同處就是 gh-ost 不是基於 triggergh-ost 的開發團隊認為使用 trigger 有許多的限制與風險,可參照:
Why triggerless?
Why triggerless?
取而代之的是 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 socketTCPtable _ghc 查詢 gh-ost 狀態。
  • 可測試: gh-ost 可以在 SLAVE 進行遷移,用以觀察 Loading 和 正確性後再投入使用。
  • 控制切換階段: cut overgh-ost 最關鍵的一個步驟,你可以隨時決定 cut over 的時間。
  • 外部 hook: gh-ost 提供 hook 功能,例如:可以用於推送到 SLACK 群組告知進度。

如何運作

執行步驟
執行步驟

解析 cut over 階段

Cut over
Cut over

要求與限制

要求與限制
要求與限制

Shared key

Shared key
Shared key

參數

常用的參數如下:
其他參數可以參考:
 參數
參數

限流管理

Throttle
Throttle

互動式指令

Interactive commands
Interactive commands

hook

hook
hook

DDL 方案比較選擇

方案選擇
方案選擇