1. gh-ost工作模式
gh-ost有三種工作模式：
a:
連接到從庫，在主庫做遷移。
b:
連接到主庫，遷移過程所有操作都在主上操作，包括讀取binlog等等。
c:
在從庫做遷移測試。
三種方法各有優缺點，先說a的缺點，a會在從上面讀取binlog,但數據庫主從數據爲什麼會造成不一致，一個很重要的原因是主庫的binlog沒有完全在從庫執行。
所以感覺a方法有丟失數據的風險。b方法任何操作都會再主庫操作，或多或少會對主庫負載造成影響，但是可以通過調整一些參數降低和時刻關注這些影響.
至於c方法是偏向測試用的，這裏不做過多介紹，但是c方法裏有一個細節，cut-over階段有會stop slave一個操作,其實這個操作風險特別高，
有時stop slave 時間會很長，務必會對線上數據庫使用造成影響，所以如果使用c方法做測試也要在線下數據庫。
2.參數介紹。
gh-ost參數很多，但我使用到的有限，這裏只對使用到的參數進行介紹，再強調一下，這裏測試的是b方法。
--max-load
遷移過程中，gh-ost會時刻關注負載情況，負載閥值是使用者自己定義，比如數據庫的最大連接數，如果超過閥值，gh-ost不會退出，會等待到負載在閥值以下繼續執行。
--critical-load
這個指的是gh-ost退出閥值，當負載超過這個閥值，gh-ost會停止並退出
--chunk-size
遷移過程是一步步分批次完成的，這個參數是指事務每次提交的行數，默認是1000。
--max-lag-millis
會監控從庫的主從延遲情況，如果延遲秒數超過這個閥值，遷移不會退出，等待延遲秒數低於這個閥值繼續遷移。
--throttle-control-replicas
和--max-lag-millis參數相結合，這個參數指定主從延遲的數據庫實例。
--initially-drop-ghost-table
gh-ost執行前會創建兩張xx_ghc和xx_gho表，如果這兩張表存在,且加上了這個參數，那麼會自動刪除原gh表，從新創建，
否則退出。xx_gho表相當於老表的全量備份，xx_ghc表數據是數據更改日誌，理解成增量備份。
--initially-drop-socket-file
gh-ost執行時會創建socket文件，退出時不會刪除，下次執行gh-ost時會報錯，加上這個參數會刪除老的socket文件，重新創建。
--ok-to-drop-table
go-ost執行完以後是否刪除老表，加上此參數會自動刪除老表。
--host
數據庫實例地址。
--port
數據庫實例端口。
--user
數據庫實例用戶名。
--password
數據庫實例密碼。
--database
數據庫名稱。
--table
表名。
-verbose
--alter
操作語句。
--cut-over
自動執行rename操作。
--debug
輸出詳細日誌。
--panic-flag-file
這個文件被創建，遷移操作會被立即終止退出。
--execute
如果確定執行，加上這個參數。
--allow-on-master
整個遷移所有操作在主庫上執行，也就是數的b方法。
--throttle-flag-file
此文件存在時操作暫停，刪除文件操作會繼續。
./gh-ost -host="192.168.15.104" --max-load=Threads_connected=3000
-port=3306 -user="dlan" -password="root123" -database="aaa" -table="team_member_20161109"
--alter="add column yuhao2 char(11)" --allow-on-master --initially-drop-ghost-table --initially-drop-old-table
-initially-drop-ghost-table --initially-drop-ghost-table --initially-drop-socket-file --initially-drop-socket-file
--ok-to-drop-table --cut-over=default --execute
以上測試加的參數，測試的心碎，2事務就出問題
