Online DDL 工具 gh-ost實戰(一)

收錄於話題 #MySQL技術 56個

2020年了，開始正文前，先說幾句廢話，2019年公眾號開始正式更文，後期由於個人問題停更了，2020年開始重新開始更文，更文目的很簡單，記錄自己的學習，分享給大家，就這麼簡單；好啦，言歸正傳，下面開始今天的正文了；
Online DDL 一直都是 DBA 運維時比較頭疼的事，一般都會選擇在業務低峰期謹慎的操作，比較常用的幾個工具比如 percona pt-online-schema-change , Facebook OSC, 本質上它們都是基於觸發器的，簡單來講就是通過資料庫的觸發器把作用在源表的操作在一個事務內同步到修改後的表中，這在業務高峰期時會極大的加重主庫的負載。下面介紹的gh-ost 是由 Github 開發的 Online DDL 工具，使用 binlog 代替觸發器來做增量數據同步，這樣可以降低主庫的負載，異步的執行。  一、安裝步驟

[root@wjq ~]# wget https:
[root@wjq ~]#tar -xvf go1.10.1.linux-amd64.tar.gz

[root@wjq ~]#vim /etc/profile
添加
export GOROOT=/data/work/go
export GOPATH=/data/work/gopath
export PATH=$PATH:$GOROOT/bin:$GOPATH/bin

下載二進位安裝包：https://github.com/github/gh-ost/releases

[root@wjq mysql]# tar zxvf gh-ost-binary-linux-20190214020851.tar.gz

解壓完成之後，當前目錄下就會出現gh-ost的可執行文件

[root@wjq mysql]# ll gh-ost
-rwxr-xr-x 1 20649 users 9511528 Feb 14 2019 gh-ost

常用參數解釋：

Usage of gh-ost:

–aliyun-rds:是否在阿里雲資料庫上執行。true

–allow-master-master:是否允許gh-ost運行在雙主複製架構中，一般與-assume-master-host參數一起使用

–allow-nullable-unique-key:允許gh-ost在數據遷移依賴的唯一鍵可以為NULL，默認為不允許為NULL的唯一鍵。如果數據遷移(migrate)依賴的唯一鍵允許NULL值，則可能造成數據不正確，請謹慎使用。

–allow-on-master:允許gh-ost直接運行在主庫上。默認gh-ost連接的從庫。

–alter string:DDL語句

–approve-renamed-columns ALTER:如果你修改一個列的名字，gh-ost將會識別到並且需要提供重命名列名的原因，默認情況下gh-ost是不繼續執行的，除非提供-approve-renamed-columns ALTER。

–ask-pass:MySQL密碼

–assume-master-host string:為gh-ost指定一個主庫，格式為」ip:port」或者」hostname:port」。在這主主架構裡比較有用，或者在gh-ost發現不到主的時候有用。

–assume-rbr:確認gh-ost連接的資料庫實例的binlog_format=ROW的情況下，可以指定-assume-rbr，這樣可以禁止從庫上運行stop slave,start slave,執行gh-ost用戶也不需要SUPER權限。

–check-flag

–chunk-size int:在每次迭代中處理的行數量(允許範圍：100-100000)，默認值為1000。

–concurrent-rowcount:該參數如果為True(默認值)，則進行row-copy之後，估算統計行數(使用explain select count(*)方式)，並調整ETA時間，否則，gh-ost首先預估統計行數，然後開始row-copy。

–conf string:gh-ost的配置文件路徑。

–critical-load string:一系列逗號分隔的status-name=values組成，當MySQL中status超過對應的values，gh-ost將會退出。-critical-load Threads_connected=20,Connections=1500，指的是當MySQL中的狀態值Threads_connected>20,Connections>1500的時候，gh-ost將會由於該資料庫嚴重負載而停止並退出。Comma delimited status-name=threshold, same format as –max-load. When status exceeds threshold, app panics and quits

–critical-load-hibernate-seconds int :負載達到critical-load時，gh-ost在指定的時間內進入休眠狀態。它不會讀/寫任何來自任何伺服器的任何內容。

–critical-load-interval-millis int:當值為0時，當達到-critical-load，gh-ost立即退出。當值不為0時，當達到-critical-load，gh-ost會在-critical-load-interval-millis秒數後，再次進行檢查，再次檢查依舊達到-critical-load，gh-ost將會退出。

–cut-over string:選擇cut-over類型:atomic/two-step，atomic(默認)類型的cut-over是github的算法，two-step採用的是facebook-OSC的算法。

–cut-over-exponential-backoff

–cut-over-lock-timeout-seconds int:gh-ost在cut-over階段最大的鎖等待時間，當鎖超時時，gh-ost的cut-over將重試。(默認值：3)

–database string:資料庫名稱。

–debug:debug模式。

–default-retries int:各種操作在panick前重試次數。(默認為60)

–discard-foreign-keys:該參數針對一個有外鍵的表，在gh-ost創建ghost表時，並不會為ghost表創建外鍵。該參數很適合用於刪除外鍵，除此之外，請謹慎使用。

–dml-batch-size int:在單個事務中應用DML事件的批量大小（範圍1-100）（默認值為10）

–exact-rowcount:準確統計表行數(使用select count(*)的方式)，得到更準確的預估時間。

–execute:實際執行alter&migrate表，默認為noop，不執行，僅僅做測試並退出，如果想要ALTER TABLE語句真正落實到資料庫中去，需要明確指定-execute

–exponential-backoff-max-interval int

–force-named-cut-over:如果為true，則』unpostpone | cut-over』交互式命令必須命名遷移的表

–force-table-names string:在臨時表上使用的表名前綴

–heartbeat-interval-millis int:gh-ost心跳頻率值，默認為500

–help

–hooks-hint string:任意消息通過GH_OST_HOOKS_HINT注入到鉤子

–hooks-path string:hook文件存放目錄(默認為empty，即禁用hook)。hook會在這個目錄下尋找符合約定命名的hook文件來執行。

–host string :MySQL IP/hostname

–initially-drop-ghost-table:gh-ost操作之前，檢查並刪除已經存在的ghost表。該參數不建議使用，請手動處理原來存在的ghost表。默認不啟用該參數，gh-ost直接退出操作。

–initially-drop-old-table:gh-ost操作之前，檢查並刪除已經存在的舊錶。該參數不建議使用，請手動處理原來存在的ghost表。默認不啟用該參數，gh-ost直接退出操作。

–initially-drop-socket-file:gh-ost強制刪除已經存在的socket文件。該參數不建議使用，可能會刪除一個正在運行的gh-ost程序，導致DDL失敗。

–master-password string :MySQL 主密碼

–master-user string:MysQL主帳號

–max-lag-millis int:主從複製最大延遲時間，當主從複製延遲時間超過該值後，gh-ost將採取節流(throttle)措施，默認值：1500s。

–max-load string:逗號分隔狀態名稱=閾值，如：』Threads_running=100,Threads_connected=500′. When status exceeds threshold, app throttles writes

–migrate-on-replica:gh-ost的數據遷移(migrate)運行在從庫上，而不是主庫上。

–nice-ratio float:每次chunk時間段的休眠時間，範圍[0.0…100.0]。0：每個chunk時間段不休眠，即一個chunk接著一個chunk執行；1：每row-copy 1毫秒，則另外休眠1毫秒；0.7：每row-copy 10毫秒，則另外休眠7毫秒。

–ok-to-drop-table:gh-ost操作結束後，刪除舊錶，默認狀態是不刪除舊錶，會存在_tablename_del表。

–panic-flag-file string:當這個文件被創建，gh-ost將會立即退出。

–password string :MySQL密碼

–port int ：MySQL埠，最好用從庫

–postpone-cut-over-flag-file string：當這個文件存在的時候，gh-ost的cut-over階段將會被推遲，數據仍然在複製，直到該文件被刪除。

–quiet：靜默模式。

–replica-server-id uint : gh-ost的server_id

–replication-lag-query string:棄用

–serve-socket-file string：gh-ost的socket文件絕對路徑。

–serve-tcp-port int:gh-ost使用埠，默認為關閉埠。

–skip-foreign-key-checks:確定你的表上沒有外鍵時，設置為’true』，並且希望跳過gh-ost驗證的時間-skip-renamed-columns ALTER

–skip-renamed-columns ALTER：如果你修改一個列的名字(如change column)，gh-ost將會識別到並且需要提供重命名列名的原因，默認情況下gh-ost是不繼續執行的。該參數告訴gh-ost跳該列的數據遷移，讓gh-ost把重命名列作為無關緊要的列。該操作很危險，你會損失該列的所有值。

–stack:添加錯誤堆棧追蹤。

–switch-to-rbr:讓gh-ost自動將從庫的binlog_format轉換為ROW格式。

–table string:表名

–test-on-replica：在從庫上測試gh-ost，包括在從庫上數據遷移(migration)，數據遷移完成後stop slave，原表和ghost表立刻交換而後立刻交換回來。繼續保持stop slave，使你可以對比兩張表。

–test-on-replica-skip-replica-stop:當-test-on-replica執行時，該參數表示該過程中不用stop slave。

–throttle-additional-flag-file string:當該文件被創建後，gh-ost操作立即停止。該參數可以用在多個gh-ost同時操作的時候，創建一個文件，讓所有的gh-ost操作停止，或者刪除這個文件，讓所有的gh-ost操作恢復。

–throttle-control-replicas string:列出所有需要被檢查主從複製延遲的從庫。

–throttle-flag-file string:當該文件被創建後，gh-ost操作立即停止。該參數適合控制單個gh-ost操作。-throttle-additional-flag-file string適合控制多個gh-ost操作。

–throttle-http string

–throttle-query string:節流查詢。每秒鐘執行一次。當返回值=0時不需要節流，當返回值>0時，需要執行節流操作。該查詢會在數據遷移(migrated)伺服器上操作，所以請確保該查詢是輕量級的。

–timestamp-old-table:在舊錶名中使用時間戳。這會使舊錶名稱具有唯一且無衝突的交叉遷移

–tungsten：告訴gh-ost你正在運行的是一個tungsten-replication拓撲結構。

–user string :MYSQL用戶

–verbose

–version

  二、主庫模式

gh-ost \
--max-load=Threads_running=20 \
--critical-load=Threads_running=50 \
--critical-load-interval-millis=5000 \
--chunk-size=1000 \
--user="root" \
--password="xxxxx" \
--host='127.0.0.1' \
--port=3306 \
--database="wjq" \
--table="employees" \
--verbose \
--alter="engine=innodb" \
--assume-rbr \
--cut-over=default \
--cut-over-lock-timeout-seconds=1 \
--dml-batch-size=10 \
--allow-on-master \
--concurrent-rowcount \
--default-retries=10 \
--heartbeat-interval-millis=2000 \
--panic-flag-file=/tmp/ghost.panic.flag \
--postpone-cut-over-flag-file=/tmp/ghost.postpone.flag \
--timestamp-old-table \
--execute 2>&1 | tee /tmp/rebuild_employees.log

GH-OST會輸出一些關鍵詳細信息，讓你了解整個遷移過程。當然，你可以控制輸出級別。

2019-12-07 22:43:58 INFO starting gh-ost 1.0.48
2019-12-07 22:43:58 INFO Migrating `wjq`.`employees`
2019-12-07 22:43:58 INFO connection validated on 127.0.0.1:3306
2019-12-07 22:43:58 INFO User has ALL privileges
2019-12-07 22:43:58 INFO binary logs validated on 127.0.0.1:3306
2019-12-07 22:43:58 INFO Inspector initiated on wjq:3306, version 5.7.19-log
2019-12-07 22:43:58 INFO Table found. Engine=InnoDB
2019-12-07 22:44:01 INFO Estimated number of rows via EXPLAIN: 299387
2019-12-07 22:44:01 INFO Recursively searching for replication master
2019-12-07 22:44:01 INFO Master found to be wjq:3306
2019-12-07 22:44:01 INFO log_slave_updates validated on 127.0.0.1:3306
2019-12-07 22:44:01 INFO connection validated on 127.0.0.1:3306
2019-12-07 22:44:01 INFO Connecting binlog streamer at mysql3306.000064:8255879
[2019/12/07 22:44:01] [info] binlogsyncer.go:133 create BinlogSyncer with config {99999 mysql 127.0.0.1 3306 root false false false UTC true 0 0s 0s 0 false}
[2019/12/07 22:44:01] [info] binlogsyncer.go:354 begin to sync binlog from position (mysql3306.000064, 8255879)
[2019/12/07 22:44:01] [info] binlogsyncer.go:203 register slave for master server 127.0.0.1:3306
2019-12-07 22:44:01 INFO connection validated on 127.0.0.1:3306
2019-12-07 22:44:01 INFO connection validated on 127.0.0.1:3306
2019-12-07 22:44:01 INFO will use time_zone='SYSTEM' on applier
2019-12-07 22:44:01 INFO Examining table structure on applier
2019-12-07 22:44:01 INFO Applier initiated on wjq:3306, version 5.7.19-log
2019-12-07 22:44:01 INFO Dropping table `wjq`.`_employees_ghc`
2019-12-07 22:44:01 INFO Table dropped
2019-12-07 22:44:01 INFO Creating changelog table `wjq`.`_employees_ghc`
2019-12-07 22:44:01 INFO rotate to next log from mysql3306.000064:0 to mysql3306.000064
[2019/12/07 22:44:01] [info] binlogsyncer.go:723 rotate to (mysql3306.000064, 8255879)
2019-12-07 22:44:01 INFO Changelog table created
2019-12-07 22:44:01 INFO Creating ghost table `wjq`.`_employees_gho`
2019-12-07 22:44:01 INFO Ghost table created
2019-12-07 22:44:01 INFO Altering ghost table `wjq`.`_employees_gho`
2019-12-07 22:44:01 INFO Ghost table altered
2019-12-07 22:44:01 INFO Intercepted changelog state GhostTableMigrated
2019-12-07 22:44:01 INFO Created postpone-cut-over-flag-file: /tmp/ghost.postpone.flag
2019-12-07 22:44:01 INFO Waiting for ghost table to be migrated. Current lag is 0s
2019-12-07 22:44:01 INFO Handled changelog state GhostTableMigrated
2019-12-07 22:44:01 INFO Chosen shared unique key is PRIMARY
2019-12-07 22:44:01 INFO Shared columns are emp_no,birth_date,first_name,last_name,gender,hire_date,testcol1,count
2019-12-07 22:44:01 INFO Listening on unix socket file: /tmp/gh-ost.wjq.employees.sock
2019-12-07 22:44:01 INFO Migration min values: [10001]
2019-12-07 22:44:01 INFO Migration max values: [499999]
2019-12-07 22:44:01 INFO Waiting for first throttle metrics to be collected
2019-12-07 22:44:01 ERROR parsing time "" as "2006-01-02T15:04:05.999999999Z07:00": cannot parse "" as "2006"
2019-12-07 22:44:01 INFO First throttle metrics collected
# Migrating `wjq`.`employees`; Ghost table is `wjq`.`_employees_gho`
# Migrating wjq:3306; inspecting wjq:3306; executing on wjq
# Migration started at Sat Dec 07 22:43:58 +0800 2019
# chunk-size: 1000; max-lag-millis: 1500ms; dml-batch-size: 10; max-load: Threads_running=20; critical-load: Threads_running=50; nice-ratio: 0.000000
# throttle-additional-flag-file: /tmp/gh-ost.throttle
# postpone-cut-over-flag-file: /tmp/ghost.postpone.flag [set]
# panic-flag-file: /tmp/ghost.panic.flag
# Serving on unix socket: /tmp/gh-ost.wjq.employees.sock

這些信息是GH-OST相對自我解釋，他們大多表示一切順利。你將主要關注遷移並了解其是否順利進行。一旦遷移實際開始，你將看到如下輸出。

Copy: 0/299387 0.0%; Applied: 0; Backlog: 0/1000; Time: 3s(total), 0s(copy); streamer: mysql3306.000064:8257599; State: migrating; ETA: N/A
Copy: 0/299387 0.0%; Applied: 0; Backlog: 0/1000; Time: 4s(total), 1s(copy); streamer: mysql3306.000064:8258392; State: migrating; ETA: N/A
Copy: 7000/299387 2.3%; Applied: 0; Backlog: 0/1000; Time: 5s(total), 2s(copy); streamer: mysql3306.000064:8454005; State: migrating; ETA: 1m25s
Copy: 16000/299387 5.3%; Applied: 0; Backlog: 0/1000; Time: 6s(total), 3s(copy); streamer: mysql3306.000064:8704252; State: migrating; ETA: 53s
Copy: 32000/299387 10.7%; Applied: 0; Backlog: 0/1000; Time: 7s(total), 4s(copy); streamer: mysql3306.000064:9149375; State: migrating; ETA: 33s
Copy: 48000/299387 16.0%; Applied: 0; Backlog: 0/1000; Time: 8s(total), 5s(copy); streamer: mysql3306.000064:9593805; State: migrating; ETA: 26s
Copy: 64000/299387 21.4%; Applied: 0; Backlog: 0/1000; Time: 9s(total), 6s(copy); streamer: mysql3306.000064:10038647; State: migrating; ETA: 22s
Copy: 79000/299387 26.4%; Applied: 0; Backlog: 0/1000; Time: 10s(total), 7s(copy); streamer: mysql3306.000064:10455500; State: migrating; ETA: 19s
Copy: 95000/299387 31.7%; Applied: 0; Backlog: 0/1000; Time: 11s(total), 8s(copy); streamer: mysql3306.000064:10900454; State: migrating; ETA: 17s
Copy: 113000/299387 37.7%; Applied: 0; Backlog: 0/1000; Time: 12s(total), 9s(copy); streamer: mysql3306.000064:11400683; State: migrating; ETA: 14s
Copy: 128000/299387 42.8%; Applied: 0; Backlog: 0/1000; Time: 13s(total), 10s(copy); streamer: mysql3306.000064:11817995; State: migrating; ETA: 13s
Copy: 143000/299387 47.8%; Applied: 0; Backlog: 0/1000; Time: 14s(total), 11s(copy); streamer: mysql3306.000064:12262961; State: migrating; ETA: 12s
Copy: 157000/299387 52.4%; Applied: 0; Backlog: 0/1000; Time: 15s(total), 12s(copy); streamer: mysql3306.000064:12624284; State: migrating; ETA: 10s
Copy: 174000/299387 58.1%; Applied: 0; Backlog: 0/1000; Time: 16s(total), 13s(copy); streamer: mysql3306.000064:13096505; State: migrating; ETA: 9s
Copy: 189000/299387 63.1%; Applied: 0; Backlog: 0/1000; Time: 17s(total), 14s(copy); streamer: mysql3306.000064:13513590; State: migrating; ETA: 8s
Copy: 204000/299387 68.1%; Applied: 0; Backlog: 0/1000; Time: 18s(total), 15s(copy); streamer: mysql3306.000064:13931136; State: migrating; ETA: 7s
Copy: 214000/299387 71.5%; Applied: 0; Backlog: 0/1000; Time: 19s(total), 16s(copy); streamer: mysql3306.000064:14209235; State: migrating; ETA: 6s
Copy: 229000/299387 76.5%; Applied: 0; Backlog: 0/1000; Time: 20s(total), 17s(copy); streamer: mysql3306.000064:14626242; State: migrating; ETA: 5s
Copy: 246000/299387 82.2%; Applied: 0; Backlog: 0/1000; Time: 21s(total), 18s(copy); streamer: mysql3306.000064:15098735; State: migrating; ETA: 3s
Copy: 259000/299387 86.5%; Applied: 0; Backlog: 0/1000; Time: 22s(total), 19s(copy); streamer: mysql3306.000064:15460181; State: migrating; ETA: 2s
Copy: 277000/299387 92.5%; Applied: 0; Backlog: 0/1000; Time: 23s(total), 20s(copy); streamer: mysql3306.000064:15960640; State: migrating; ETA: 1s
Copy: 292000/299387 97.5%; Applied: 0; Backlog: 0/1000; Time: 24s(total), 21s(copy); streamer: mysql3306.000064:16377900; State: migrating; ETA: 0s
2019-12-07 22:44:23 INFO Row copy complete

進度提示說明：

Copy: 7000/299387 2.3%;299387指需要遷移總行數，7000指已經遷移的行數，2.3%指遷移完成的百分比。

Applied: 0，指在二進位日誌中處理的event數量。在上面的例子中，遷移表沒有流量，因此沒有被處理日誌event。

Backlog: 0/1000，表示我們在讀取二進位日誌方面表現良好，在二進位日誌隊列中沒有任何積壓（Backlog）事件。

Backlog: 7/1000，當複製行時，在二進位日誌中積壓了一些事件，並且需要應用。

Backlog: 1000/1000，表示我們的1000個事件的緩衝區已滿（程序寫死的1000個事件緩衝區，低版本是100個），此時就注意binlog寫入量非常大，gh-ost處理不過來event了，可能需要暫停binlog讀取，需要優先應用緩衝區的事件。

streamer: mysql3306.000064:8454005;表示當前已經應用到binlog文件位置

# Migrating `wjq`.`employees`; Ghost table is `wjq`.`_employees_gho`
# Migrating wjq:3306; inspecting wjq:3306; executing on wjq
# Migration started at Sat Dec 07 22:43:58 +0800 2019
# chunk-size: 1000; max-lag-millis: 1500ms; dml-batch-size: 10; max-load: Threads_running=20; critical-load: Threads_running=50; nice-ratio: 0.000000
# throttle-additional-flag-file: /tmp/gh-ost.throttle
# postpone-cut-over-flag-file: /tmp/ghost.postpone.flag [set]
# panic-flag-file: /tmp/ghost.panic.flag
# Serving on unix socket: /tmp/gh-ost.wjq.employees.sock

  三、從庫模式

gh-ost \
--max-load=Threads_running=16 \
--critical-load=Threads_running=32 \
--chunk-size=1000 \
--initially-drop-old-table \
--initially-drop-ghost-table \
--initially-drop-socket-file \
--ok-to-drop-table \
--host="10.249.5.39" \
--port=3307 \
--user="dbadmin" \
--password="xxxxx" \
--assume-rbr \
--allow-on-master \
--assume-master-host=10.249.5.39:3306 \
--database="gh_ost" \
--table="gh_01" \
--alter="add column c4 varchar(50) not null default ''" \
--panic-flag-file=/tmp/ghost.panic.flag \
--serve-socket-file=/tmp/ghost.sock \
--verbose \
--execute

  四、測試模式

gh-ost \
--test-on-replica \
--max-load=Threads_running=16 \
--critical-load=Threads_running=32 \
--chunk-size=1000 \
--initially-drop-old-table \
--initially-drop-ghost-table \
--initially-drop-socket-file \
--host="10.249.5.39" \
--port=3307 \
--user="dbadmin" \
--password="xxxxx" \
--assume-rbr \
--database="gh_ost" \
--table="gh_01" \
--alter="add column c4 varchar(50) not null default ''" \
--panic-flag-file=/tmp/ghost.panic.flag \
--serve-socket-file=/tmp/ghost.sock \
--verbose \
--execute

參數說明

–test-on-replica：在從庫上執行遷移，但不進行最後的cut-over，並最後會停止複製線程，供測試人員進行數據對比

–migrate-on-replica：直接在從庫上遷移並cut-over，複製線程不會停止

  五、暫停、恢復、終止、延遲切換gh-ost的–serve-socket-file文件用來監聽請求，比如可以動態調整性能方面參數，也可以進行暫停、恢復gh-ost線程。

#暫停
[root@wjq tmp]# echo throttle | socat - /tmp/ghost.sock

#恢復
[root@wjq tmp]# echo no-throttle | socat - /tmp/ghost.sock

#終止
對應panic-flag-file參數文件，當tmp目錄存在該文件立即停止
[root@wjq tmp]# touch /tmp/ghost.panic.flag


日誌中就會出現如下的信息：
2019-12-07 22:44:54 FATAL Found panic-file /tmp/ghost.panic.flag. Aborting without cleanup

注意：停止gh-ost操作會有遺留表 xxx_ghc, xxx_gho 還有socket文件，管理cut-over的文件,如果你需要執行兩次請務必檢查指定目錄是否存在這些文件，並且清理掉文件和表

#延遲切換(cut-over階段)
--postpone-cut-over-flag-file=/tmp/ghost.postpone.flag
當設置該參數時cut-over一直延遲切換，直到你刪除該文件才進行切換

#動態調整性能參數
[root@wjq tmp]# echo chunk-size=100 | socat - /tmp/gh-ost.wjq.employees.sock

#打開限流
[root@wjq tmp]# echo throttle | socat - /tmp/gh-ost.wjq.employees.sock

#關閉限流
[root@wjq tmp]# no-throttle | socat - /tmp/gh-ost.wjq.employees.sock

改變執行限速參數: chunk-size= 1024, max-lag-millis=100, max-load=Thread_running=23 這些參數都可以在運行時動態調整。
echo chunk-size=1024 | socat - /tmp/gh-ost.wjq.employees.sock
echo max-lag-millis=100 | socat - /tmp/gh-ost.wjq.employees.sock
echo max-load=Thread_running=23 | socat - /tmp/gh-ost.wjq.employees.sock

  六、使用過程中遇到的問題記錄問題 1、對於主從結構 DB 集群，Binlog 日誌格式必須是 ROW 模式，否則會有如下報錯：2019-12-07 22:44:01 FATAL 192.168.1.1:3306 has MIXED binlog_format, but I’m too scared to change it to ROW because it has replicas. Bailing out執行 gh-ost 之前，先將 binlog 格式動態改為 ROW 模式（不會影響主從同步）：SET GLOBAL binlog_format = 『ROW』;然後，再執行 gh-ost 就可以了，如果後面需要 MIXED 模式，可以再次動態修改回來即可。問題 2、修改對象表不能被觸發器關聯，gh-ost 雖然不再依賴觸發器，但是依然不支持有觸發器關聯的表，如果修改有觸發器關聯的表，則會有如下提示：2019-12-07 22:44:01 ERROR Found triggers on ndb.net_device_parts. Triggers are not supported at this time. Bailing out問題 3、修改對象表不能被外鍵關聯，否則如下報錯：2019-12-07 22:44:01 FATAL 2019-12-07 22:44:01 ERROR Found 7 parent-side foreign keys on ndb.net_device. Parent-side foreign keys are not supported. Bailing out問題 4、FATAL Unexpected database port reported該問題主要發生在主主模式，且使用自定義埠的情況，解決辦法：在-assume-master-host 參數後面添加主機的埠號，比如：-assume-master-host=192.168.1.1:3307如果是雲資料庫的話，需要加上–aliyun-rds參數示例說明上面是一個簡單的案例，下面我們就來看一下在執行過程中產生的兩張中間表：

root@localhost:mysql3306.sock [wjq]>show tables like '%employees%';
+----+
| Tables_in_wjq (%employees%) |
+----+
| _employees_ghc |
| _employees_gho |
| employees |
+----+
3 rows in set (0.00 sec)

root@localhost:mysql3306.sock [wjq]>show create table _employees_ghc\G;
*************************** 1. row ***************************
Table: _employees_ghc
Create Table: CREATE TABLE `_employees_ghc` (
`id` bigint(20) NOT NULL AUTO_INCREMENT,
`last_update` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
`hint` varchar(64) CHARACTER SET ascii NOT NULL,
`value` varchar(4096) CHARACTER SET ascii NOT NULL,
PRIMARY KEY (`id`),
UNIQUE KEY `hint_uidx` (`hint`)
) ENGINE=InnoDB AUTO_INCREMENT=311 DEFAULT CHARSET=utf8mb4
1 row in set (0.00 sec)

_employees_ghc是用於記錄中間執行過程記錄表_employees_gho就是目標表，也就是應用ddl語句的幽靈表參考連接https://www.cnblogs.com/mysql-dba/p/9901583.htmlhttps://cloud.tencent.com/developer/article/1072238