初試GH-OST（轉）

zping發表於2018-04-18

最近老闆讓做一個gh-ost和pt-osc 的對比測試，本文將對兩者做對比。

一。原理和所用說明

  PT-OSC GH-OST
原理

1.建立一個和要執行 alter 操作的表一樣的新的空表結構(是alter之前的結構)
2.在新表執行alter table 語句
3.在原表中建立觸發器3個觸發器分別對應insert,update,delete操作
4.以一定塊大小從原表拷貝資料到臨時表，拷貝過程中通過原表上的觸發器在原表進行的寫操作都會更新到新建的臨時表
5.Rename 原表到old表中，在把臨時表Rename為原表
6.如果有參考該表的外來鍵，根據alter-foreign-keys-method引數的值，檢測外來鍵相關的表，做相應設定的處理
7.預設最後將舊原表刪除

1.在變更的伺服器上 建立 ghost table( _tbname_gho like tbname)
2.更改 _tbname_gho 結構為新表結構
3.作為mysql的slave連線mysql server，並記錄新增binlog event
4.交替執行: 應用新增events到 ghost table 和 複製老表的記錄到 ghost table
5.table重新命名(ghost table 替代 老表)

其中有2種常用用法：
1.連線從庫，變更主庫 - 預設方式，slave需要開啟log-slave-update
2.連線主庫，變更主庫 - 必須ROW格式，帶上引數--allow-on-master"
使用限制

1.原表必須要有主鍵或者唯一索引（不含NULL）
2.原表上不能有觸發器存在
3.使用前需保證有足夠的磁碟容量，因為複製原表需要一倍的空間
4.在阿里RDS 上使用需要增加引數no-version-check

1.原表必須要有主鍵或者唯一索引（不含NULL）
2.不支援外來鍵
3.不支援觸發器
4.不支援虛擬列
5.不支援 5.7 point型別的列
6. 5.7 JSON列不能是主鍵
7.不能存在另外一個table名字一樣，只是大小寫有區別
8.不支援多源複製
9.不支援M-M 雙寫
10.不支援FEDERATED engine
重要引數說明

--max-load，預設threads_running=25,可以指定多個指標來限速,每個chunk拷貝完會檢查，超過閥值會暫停複製。如果不指定該引數，工具會檢查當前執行值並增加20%
--critical-load,預設為threads_running=50,如果不指定，則工具檢查當前執行值並當執行到200%是退出工具執行
--max-lag，預設1s，如果發現延遲大於該值，則暫停複製資料。
--check-interval,配合max-lag使用，檢查從庫超過延時後，該工具睡眠多久
--recursion-method，指定從庫的發現機制,processlist,dsn,none 等
--chunk-time,預設0.5秒，拷貝資料行的時候為了保證0.5秒內拷貝完一個chunk，動態調整下一次chunk-size的大小
--[no]check-replication-filters，如果工具檢查到伺服器選項中有任何複製相關的篩選，工具會報錯退出，預設為yes
--chunk-size，指定塊大小，預設1000行。

--max-load=Threads_running=25 表面如果在執行gh-ost的過程中出現Threads_running=25則暫停gh-ost的執行
--critical-load=Threads_running=60 表明執行過程中出現Threads_running達到60則終止gh-ost的執行
--chunk-size=1000 設定每次從原表copy到 ghost table的行數
--ok-to-drop-table 執行完之後刪除原表
--allow-on-master 直連主庫執行
優點　 1.執行速度快，業界使用比較廣泛，較穩定

1.讀binlog可以放在從庫執行，減少主庫的壓力
2.不需要建立觸發器，對原表沒有改動
風險點　　

1.需要建立觸發器，對原表有改動
2.涉及主鍵的更改需要review

1.當系統負載極高時，gh-ost有可能無法跟上binlog日誌的處理（未測試過該場景）
2.限制比較多，見上文
3.涉及主鍵的更改需要review
執行命令例項 pt-online-schema-change --user=db_monitor --password=xxx --host=127.0.0.1 --port=xxx --alter "add COLUMN c2 varchar (120) not null default ''" D=sbtest,t=sbtest1 --no-check-replication-filters --alter-foreign-keys-method=auto --recursion-method=none --print --execute ./gh-ost --assume-master-host=ip:port --master-user=db_monitor --master-password=xxx --user=db_monitor --password=yyy --host=10.xxx --port=port  --alter="ADD COLUMN c2 varchar(120)"   --database=sbtest --table="sbtest1" -execute --initially-drop-old-table --initially-drop-socket-file --initially-drop-ghost-table

 

二，效能測試對比

1. 測試場景

       16core CPU，2G buffer pool的測試例項，5.5的MySQL版本非同步主從，2kw行記錄，4.8GB 測試表大小

2. 測試結果（不限速），複製延時用zabbix 監控seconds behind master 的值

        

3. 結果展示

 

三， 最後說一下GH-OST的 cut over

gh-ost利用了MySQL的一個特性，就是原子性的rename請求，在所有被blocked的請求中，優先順序永遠是最高的。
gh-ost基於此設計了該方案：一個連線對原表加鎖，另啟一個連線嘗試rename操作，此時會被阻塞住，當釋放lock的時候，rename會首先被執行，其他被阻塞的請求會繼續應用到新表。

 

參考資料：

https://github.com/github/gh-ost

https://m.aliyun.com/yunqi/articles/62928

http://www.tabdba.com/?p=175

Do not go gentle into that good night~

相關文章