20180710使用gh

時間  2019-12-08
標籤 使用 简体版
原文   原文鏈接

轉自：http://www.ywnds.com/?p=14265python

1、背景mysql

GitHub正式宣佈以開源的方式發佈gh-ost：GitHub的MySQL無觸發器在線更改表定義工具！下面是官方給出gh-ost產生的背景。linux

gh-ost是GitHub在2016年5月份開源的，目的是解決一個常常碰到的問題：不斷變化的產品需求會不斷要求更改MySQL表結構。gh-ost經過一種影響小、可控制、可審計、操做簡單的方案來改變線上表結構。git

在介紹gh-ost以前，咱們先了解一下各類現有方案，以及爲何要本身開發一個新工具。github

已有的在線修改表定義方案？算法

目前，在線修改表定義的任務主要是經過這三種途徑完成的：sql

  • 在從庫上修改表定義，修改以後再提高爲新的主庫。
  • 經過MySQL的InnoDB在線DDL功能。
  • 使用修改表定義工具。如今最流行的是Percona公司的pt-online-schema-change和Facebook的OSC，也有人使用LHM或最先的oak-online-alter-table。

還有其它的好比Galera Cluster的Rolling Schema Upgrade，或者非InnoDB引擎的表等。GitHub的MySQL數據庫用的都是主從複製架構，使用可靠的InnoDB引擎。shell

爲何咱們決定去設計一個新解決方案，而不是直接從上面的幾種方案中選一個用？現有的解決方案都有着自身的侷限性，下面就對它們的不足之處作個簡單分析。咱們會主要深刻地分析基於觸發器的在線修改表定義工具的不足之處。數據庫

  • 在從庫上修改表定義的方案須要付出許多運維代價，這須要更多的服務器、更長的完成時間和更復雜的管理工做。修改操做是直接應用在具體的某個從庫或者整個拓撲架構的一些子樹上。服務器宕機、從庫數據不夠新、新部署的服務器等各類問題都須要有很是嚴密的跟蹤系統來跟進單個數據庫上的操做。一個改變操做可能會須要屢次反覆，也就須要更長時間。而把一個從庫升爲主庫也會致使短暫的停服。若是同時須要作多個更改就更難協調。咱們天天都要改好幾張表，因此在考慮解決方案時，咱們不但願有這樣的管理開銷。
  • MySQL的InnoDB在線DDL只能是在你敲命令的那個MySQL上纔是「在線」修改的。二進制文件中的日誌把修改操做序列化了，從庫應用日誌時會致使複製延遲。但若是嘗試在每一個從庫上挨個去改的話又會致使上面分析的管理代價。並且DDL仍是不可中斷的，要是在修改時把操做殺掉的話還須要更長的時間去回滾，甚至致使數據字典崩潰。這種方案也不「友好」，在系統負載高時也不能限速或者暫停。這樣的操做還有可能會耗盡你的系統資源。
  • 咱們用了pt-online-schema-change好幾年了。但是，當咱們的數據增多、業務壓力增大以後，咱們就碰到了愈來愈多的問題，甚至到了許多修改操做都被認爲是「危險操做」的地步。有一些操做只敢在非業務高峯期或者週末纔敢執行，其它的老是會致使MySQL中止服務。全部現有的在線修改表定義工具都是用MySQL觸發器來遷移數據的，所以自己就存在着一些問題。

 

基於觸發器的解決方案有什麼很差？服務器

全部在線修改表定義的工具運行原理都是類似的：建立一張與原始表定義相同的臨時表，趁上面沒有數據時先改好表定義，而後慢慢地、用增量方式把數據從原始表拷到臨時表，同時不斷的把進行中的原始表上的數據操做（全部應用在原始表上的插入、刪除、更新操做）也應用過來。當工具把全部數據都拷貝完畢，兩邊數據同步了以後，它就用這張臨時表來替代原始表。修改過程就結束了。

像pt-online-schema-change、LHM和oak-online-alter-table這些工具用的都是同步複製的方式，對錶的每一條數據修改都會馬上在同一個事務裏就應用到臨時表上。Facebook的工具用的則是異步模式，先把修改操做都記在一張修改日誌表裏，而後再取出來執行，把修改操做應用到臨時表上。這些工具全都使用觸發器來提取那些應用在目標表上的操做。

觸發器都是存儲過程，在表上有插入、刪除、修改操做時就會被觸發。觸發器可能包括好多條語句，這些語句都是和引起觸發器的那條操做在相同的事務空間內運行的，所以保證了這些操做的原子性。

通常意義上的觸發器，尤爲是基於觸發器的表定義修改操做，都有以下問題：

  • 觸發器就是存儲過程，都是解釋型代碼，MySQL不會作預編譯。把它們硬嵌入到業務操做的事務空間中，會給你要修改的表上執行的每條操做都增長命令分析和解釋的開銷。
  • 鎖：觸發器與操做語句分享相同的事務空間，當操做語句釋放了原始表上的鎖以後，觸發器再去釋放另外一張表上的鎖。在同步模式下這樣行爲的後果尤爲嚴重。主庫上的鎖競爭與寫併發有直接關係。咱們在生產環境中曾經遇到過鎖競爭致使的幾乎乃至徹底鎖住的狀況，徹底沒法訪問表或者整個數據庫。觸發器致使的另外一種鎖是在建立或銷燬觸發器時對元數據的鎖。在完成修改表定義以後從比較忙的表上刪除觸發器時，咱們曾經碰到幾十秒甚至幾分鐘沒法提供服務的狀況。
  • 沒法暫停：當主庫業務負載開始增高時，你可能會想要暫停或者取消還沒完成的修改表定義的任務。但是基於觸發器的方案沒辦法這麼作。也許你能夠暫停行拷貝的操做，但卻不能暫停觸發器，由於把觸發器停掉會致使臨時表中丟數據。因此，在整個過程當中觸發器都必須一直處於工做狀態。在一些繁忙的服務器上，咱們曾經見過即便把在線操做全停掉，最後主庫仍是被觸發器給拖死的狀況。
  • 併發修改：你們都但願能同時修改多張表的定義。考慮到上面分析的觸發器的代價，咱們並不敢以觸發器的模式同時修改多張表的定義，咱們也沒據說有哪家公司真的在線上這麼幹。
  • 測試：你們也許想測試一下修改方案是否可行，評估一下負載。基於觸發器的方案只能在從庫上經過基於語句的複製來模擬一下，因爲從庫上的複製操做是單線程的（即便用了多線程複製的方案，大部分狀況下也仍是這樣的），這樣遠不能模擬出在主庫上修改過程當中的真實狀況。

 

2、gh-ost介紹

gh-ost是gitHub’s Online Schema Transmogrifier/Transfigurator/Transformer/Thingy的縮寫，意思是GitHub的在線表定義轉換器。拋棄了pt-online-schema-change使用trigger來同步增量數據的方法，而經過模擬slave獲取row格式的binlog的方式來獲取增量數據。思路也很新穎，做者很厲害，也是是openark kit工具集的做者（主要是用python寫的一套工具集）。具體的數據流圖能夠看下圖。

GH-OST：配置使用實踐

由於binlog中記錄的是full image，因此binlog中的數據是最權威的，並且讀取的binlog在應用的時候作了以下轉化，並且copy old data是insert ignore，所以會以binlog的優先級爲最高，所以不會有問題。

源類型
目標類型
insert
replace
update
update
delete
delete

對與insert和update是沒有問題的，由於不管copy old row和apply binlog的前後順序，若是apply binlog在後，會覆蓋掉copy old row，若是apply binlog在前面，copy old row由於使用insert ignore，所以會被ignore掉；

對與delete數據，咱們能夠演算一下，abc三個操做，可能存在三種狀況（b確定在a的後面）：

a. delete old row

b. delete binlog apply

c. copy old row

1. cab，c會將數據copy到ghost表，最後b會把ghost表中的數據delete掉；

2. acb，c空操做，b也是空操做；

3. abc，b空操做，c也是空操做；

大概看完了gh-ost工做原理後，既然牽扯到了replace語句，天然表就必需要有一個主鍵或惟一鍵。若是沒有的狀況下執行gh-ost，天然會獲得gh-ost的一個錯誤提供：FATAL No PRIMARY nor UNIQUE key found in table! Bailing out.

gh-ost有如下特色：

  • 無觸發器

gh-ost不使用觸發器，它跟蹤二進制日誌文件，在對原始表的修改提交以後，用異步方式把這修改內容應用到臨時表中去。

gh-ost但願二進制文件使用基於行的日誌格式，但這並不表示若是主庫上使用的是基於語句的日誌格式，就不能用它來在線修改表定義了。事實上，咱們經常使用的方式是用一個從庫把日誌的語句模式轉成行模式，再從這個從庫上去讀日誌。搭一個這樣的從庫並不複雜。

  • 輕量級

由於不須要使用觸發器，gh-ost把修改表定義的負載和正常的業務負載解耦開了。它不須要考慮被修改的表上的併發操做和競爭等，這些在二進制日誌中都被序列化了，gh-ost只操做臨時表，徹底與原始表不相干。事實上，gh-ost也把行拷貝的寫操做與二進制日誌的寫操做序列化了，這樣，對主庫來講只是有一條鏈接在順序的向臨時表中不斷寫入數據，這樣的行爲與常見的ETL至關不一樣。

  • 可暫停

由於全部寫操做都是gh-ost生成的，而讀取二進制文件自己就是一個異步操做，因此在暫停時，gh-ost是徹底能夠把全部對主庫的寫操做全都暫停的。暫停就意味着對主庫沒有寫入和更新。不過gh-ost也有一張內部狀態跟蹤表，即便在暫停狀態下也會向那張表中不斷寫入心跳信息，寫入量能夠忽略不計。

gh-ost提供了比簡單的暫停更多的功能，除了暫停以外還能夠作：

負載：與pt-online-schema-change相近的一個功能，用戶能夠設置MySQL指標的閾值，好比設置Threads_running=30。

複製延遲：gh-ost內置了心跳功能來檢查複製延遲。用戶能夠指定查看哪一個從庫的延遲，gh-ost默認是直接查看它連上的那個從庫。

命令：用戶能夠寫一些命令，根據輸出結果來決定要不要開始操做。好比：SELECT HOUR(NOW()) BETWEEN 8 and 17.

上述全部指標即便在修改表定義的過程當中也能夠動態修改。

標誌位文件：生成一個標誌位文件，gh-ost就會馬上暫停。刪除文件，gh-ost又會恢復工做。

用戶命令：經過網絡連上gh-ost，經過命令讓它暫停。

  • 動態可控

若是別的工具在修改過程當中產生了比較高的負載，DBA只好把它停掉再修改配置，好比把一次拷貝的數據量改小些，而後再從頭開始修改過程。這樣的反覆操做代價很是大。

gh-ost經過監聽TCP或者unix socket文件來獲取命令。即便有正在進行中的修改工做，用戶也能夠向gh-ost發出命令修改配置，好比能夠這樣作：

echo throttle | nc -U /tmp/gh-ost.sock：這是暫停令, 也能夠輸入no-throttle取消暫停。

修改運行參數，gh-ost能夠接受這樣的修改方式來改變它的行爲：chunk-size=1500, max-lag-millis=2000, max-load=Thread_running=30。

  • 可審計

用上面所說的相同接口也能夠查看gh-ost的狀態，查看當前任務進度、主要配置參數、相關MySQL實例的狀況等。這些信息經過網絡發送命令就能夠獲得，所以就給了運維人員極大的靈活性，若是是使用別的工具的話通常只能是經過共享屏幕或者不斷跟蹤日誌文件最新內容。

  • 可測試

讀取二進制文件內容的操做徹底不會增長主庫的負載，在從庫上作修改表結構的操做也和在主庫上作是很是相象的（固然並不徹底同樣，但主要來講仍是差很少的）。

gh-ost自帶了–test-on-replica選項來支持測試功能，它容許你在從庫上運行起修改表結構操做，在操做結束時會暫停主從複製，讓兩張表都處於同步、就緒狀態，而後切換表、再切換回來。這樣就可讓用戶從容不迫地對兩張表進行檢查和對比。

咱們在GitHub是這樣在生產環境測試gh-ost的：咱們有許多個指定的生產從庫，在上面不提供服務，只是周而復始地不斷地把全部表定義都改來改去。對於咱們生產環境地每一張表，小到空表，大到幾百GB，都會經過修改存儲引擎的方式來進行修改（engine=innodb）,這樣並不會真正修改表結構。在每一次這樣的修改操做最後咱們都會停掉主從複製，再把原始表和臨時表的全量數據都各作一次校驗和，而後比較兩個校驗和，要求它們是一致的。而後咱們恢復主從複製，再繼續測試下一張表。咱們生產環境的每一張表都這樣用gh-ost在從庫上作過好屢次修改測試。

  • 可靠的

全部上述講到的和沒講到的內容，都是爲了讓你對gh-ost的能力創建信任。畢竟，你們在作這件事的時候已經使用相似工具作了好多年，而gh-ost只是一個新工具。

咱們在從庫上對gh-ost進行測試，在去主庫上作第一次真正改動以前咱們在從庫上成功地試了幾千次。因此，請你也在從庫上開始測試，驗證數據是無缺無損的，而後再把它用到生產環境。咱們但願你能夠放手去試。

當你執行了gh-ost以後，也許你會看見主庫的負載變高了，那你能夠發出暫停命令。用echo throttle命令生成一個文件，看看主庫的負載會不會又變得正常。試一下這些命令，你就能夠知道你能夠怎樣控制它的行爲，你的內心就會安定許多。

你發起了一次修改操做，而後估計完成時間是凌晨2點鐘，但是你又很是關心最後的切換操做，很是想看着它切換，這可怎麼辦？只須要一個標誌位文件就能夠告訴gh-ost推遲切換了，這樣gh-ost會只作完拷貝數據的操做，但不會切換表。它還會仍然繼續同步數據，保持臨時表的數據處於同步狀態。等次日早上你回到辦公室以後，刪除標誌位文件或者向gh-ost發送命令echo unpostpone，它就會作切換了。咱們不但願軟件強迫咱們看着它作事情，它應該把咱們解放出來，讓人去作人該作的事。

談到估計完成時間，–exact-rowcount選項很是有用。在最開始時要在目標表上作個代價比較大的SELECT COUNT(*)操做查出具體要拷多少行數據，gh-ost就會對它要作多少工做有了一個比較準確的估計。接下來在拷貝的過程當中，它會不斷地嘗試更新這個估計值。由於預計完成的時間點老是會不斷變化，因此已經完成的百分比就反而比較精確。若是你也曾經有過很是痛苦的經歷，看着已經完成99%了但是剩下的一點操做卻繼續了一個小時也沒完，你就會很是喜歡咱們提供的這個功能。

 

3、gh-ost工做模式

gh-ost工做時能夠連上多個MySQL實例，同時也把本身以從庫的方式連上其中一個實例來獲取二進制日誌事件。根據你的配置、數據庫集羣架構和你想在哪裏執行修改操做，能夠有許多種不一樣的工做模式。

GH-OST：配置使用實踐

一、連上從庫，在主庫上修改

這是gh-ost默認的工做模式，它會查看從庫狀況，找到集羣的主庫而且鏈接上去。修改操做的具體步驟是：

A. 在主庫上讀寫行數據；

B. 在從庫上讀取二進制日誌事件，將變動應用到主庫上；

C. 在從庫上查看錶格式、字段、主鍵、總行數等；

D. 在從庫上讀取gh-ost內部事件日誌（好比心跳）；

E. 在主庫上完成表切換；

若是主庫的二進制日誌格式是Statement，就可使用這種模式。但從庫就必須配成啓用二進制日誌（log_bin, log_slave_updates），還要設成Row格式（binlog_format=ROW），實際上gh-ost會在從庫上幫你作這些設置。

事實上，即便把從庫改爲Row格式，這仍然是對主庫侵入最少的工做模式。

二、連上主庫

若是沒有從庫，或者不想在從庫上操做，那直接用主庫也是能夠的。gh-ost就會在主庫上直接作全部的操做。仍然能夠在上面查看主從複製延遲。

A. 主庫必須產生Row格式的二進制日誌；

B. 啓動gh-ost時必須用–allow-on-master選項來開啓這種模式；

三、在從庫上修改和測試

這種模式會在從庫上作修改。gh-ost仍然會連上主庫，但全部操做都是在從庫上作的，不會對主庫產生任何影響。在操做過程當中，gh-ost也會不時地暫停，以便從庫的數據能夠保持最新。

A. –migrate-on-replica選項讓gh-ost直接在從庫上修改表。最終的切換過程也是在從庫正常複製的狀態下完成的。

B. –test-on-replica代表操做只是爲了測試目的。在進行最終的切換操做以前，複製會被中止。原始表和臨時表會相互切換，再切換回來，最終至關於原始表沒被動過。主從複製暫停的狀態下，你能夠檢查和對比這兩張表中的數據。

三種方法各有優缺點，這裏只說缺點，先說第一種的缺點，因爲會在從上面讀取binlog，但有可能主庫的binlog沒有徹底在從庫執行，因此我的感受第一種方法有丟失數據的風險。第二種方法任何操做都會再主庫操做，或多或少會對主庫負載形成影響，可是能夠經過調整一些參數下降和時刻關注這些影響，因此我的推薦使用第二種方法。至於第三種方法是偏向測試用的，這裏不作過多介紹，可是第三種方法裏有一個細節，cut-over階段有會stop slave一個操做，其實這個操做風險特別高，有時stop slave時間會很長，務必會對線上數據庫使用形成影響，因此若是使用第三種方法作測試也要在線下數據庫。

4、gh-ost要求和限制

 

需求
  • 將須要一臺服務器提供基於行式複製（RBR）格式的二進制日誌。如今僅支持FULL鏡像，MINIMAL鏡像未來會得到支持。
  • gh-ost用戶須要具備這些權限在你遷移的數據庫上：ALTER, CREATE, DELETE, DROP, INDEX, INSERT, LOCK TABLES, SELECT, TRIGGER, UPDATE。或SUPER, REPLICATION SLAVE on *.*，或REPLICATION CLIENT, REPLICATION SLAVE on *.*。SUPER權限是STOP SLAVE，START SLAVE操做所必需的，這些用於將你的binlog_format切換到ROW格式（若是它不是ROW格式，而且你明確指定了–switch-to-rbr選項）。若是你的複製從庫已是RBR（binlog_format = ROW）模式，你能夠指定–assume-rbr以免STOP SLAVE/ START SLAVE操做，所以不須要SUPER。
  • 運行–test-on-replica模式時，在切換階段以前，gh-ost會中止複製，以便你能夠比較這兩個表並確保遷移是正確的（僅測試使用）。

限制

  • 不支持外鍵，在將來可能會獲得支持。
  • 觸發器不受支持，在將來可能會獲得支持。
  • MySQL 5.7 JSON列受支持，但不能做爲PRIMARY KEY的一部分。
  • 表必須有一個PRIMARY KEY或其餘UNIQUE KEY。
  • Amazon RDS能夠工做，但有其自身的侷限性（阿里雲已經支持）。
  • 經過從庫遷移時不支持多源複製。
  • 主 – 主模式下，設置僅在主動 – 被動中受支持。在主動 – 主動（表中同時寫入兩個主動實例的表）不受支持。它可能在將來獲得支持。
  • 若是將enum字段做爲遷移Key（一般是PRIMARY KEY）的一部分，則遷移性能會下降而且可能出現很差的狀況。
  • ALTER TABLE … RENAME to some_other_name不受支持（而且不該該使用gh-ost來執行這樣的小操做）。

5、gh-ost參數介紹

經常使用參數介紹

--host

數據庫實例地址。

--port

數據庫實例端口。

--user

 

數據庫實例用戶名。

--password

數據庫實例密碼。

--database

數據庫名稱。

--table

表名稱。

 

--alter

ALTER語句的body部分，如」ALTER TABLE wing ADD COLUMN id int not null default 0」，使用gh-ost的-alter參數時，寫成–alter ADD COLUMN id int not null default 0便可。

--allow-on-master

默認狀況下gh-ost但願你鏈接一個從庫進行binlog獲取。若是你想鏈接主庫進行整個遷移操做，須要加上此選項便可。gh-ost提供了三種方案鏈接方案。

--max-load 

遷移過程當中，gh-ost會時刻關注負載狀況，負載閥值是使用者本身定義，好比數據庫的最大鏈接數，若是超過閥值，gh-ost不會退出，會等待到負載在閥值如下繼續執行。

--critical-load

這個指的是gh-ost退出閥值，當負載超過這個閥值，gh-ost會中止並退出。

--max-lag-millis

會監控從庫的主從延遲狀況，若是延遲秒數超過這個閥值，遷移不會退出，等待延遲秒數低於這個閥值繼續遷移。這個是遷移中很大的一個問題，特別是在從庫遷移時。

gh-ost監控複製延遲是經過檢查gh-ost自己在實用程序更新日誌表中注入的心跳事件來衡量的。也就是說，爲了測量這個複製延遲，gh-ost不須要發出show slave status命令，也沒有任何外部心跳機制。

當提供–throttle-control-replicas時，限流還會考慮指定主機上的延遲。經過查詢gh-ost的更新日誌表（其中gh-ost注入心跳）完成列出的主機上的延遲時間測量。

gh-ost可以利用毫秒測量複製延遲，當–max-lag-millis小於1000，即小於1秒時，gh-ost將進行限流。

--throttle-control-replicas

和–max-lag-millis參數相結合，這個參數指定主從延遲的數據庫實例。

--initially-drop-ghost-table

gh-ost執行前會建立兩張_xx_ghc和_xx_gho表，若是這兩張表存在，且加上了這個參數，那麼會自動刪除原gh表，從新建立，不然退出。_xx_gho表至關於老表的全量備份，_xx_ghc表數據是數據更改日誌，理解成增量備份。

--initially-drop-ghost-table

gh-ost操做以前，檢查並刪除已經存在的ghost表。該參數不建議使用，請手動處理原來存在的ghost表。默認不啓用該參數，gh-ost直接退出操做。

--initially-drop-socket-file

gh-ost執行時會建立socket文件，退出時不會刪除，下次執行gh-ost時會報錯，加上這個參數，gh-ost會強制刪除已經存在的socket文件。該參數不建議使用，可能會刪除一個正在運行的gh-ost程序，致使DDL失敗。

--initially-drop-old-table

gh-ost操做以前，檢查並刪除已經存在的舊錶。該參數不建議使用，請手動處理原來存在的ghost表。默認不啓用該參數，gh-ost直接退出操做。

--ok-to-drop-table

gh-ost執行完之後是否刪除老表，加上此參數會自動刪除老表。

--cut-over

自動執行rename操做，選擇cut-over類型：atomic/two-step，atomic(默認)類型的cut-over是github的算法，two-step採用的是facebook-OSC的算法。

--cut-over-lock-timeout-seconds

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

--switch-to-rbr

讓gh-ost自動將從庫的binlog_format轉換爲ROW格式。

--assume-rbr

確認gh-ost鏈接的數據庫實例的binlog_format=ROW的狀況下，能夠指定–assume-rbr，這樣能夠禁止從庫上運行stop slave,start slae,執行gh-ost用戶也不須要SUPER權限。

--panic-flag-file

這個文件被建立，遷移操做會被當即終止退出。

--throttle-flag-file

此文件存在時操做暫停，刪除文件操做會繼續。

--postpone-cut-over-flag-file

當這個文件存在的時候，gh-ost的cut-over階段將會被推遲，直到該文件被刪除。

--concurrent-rowcount

該參數若是爲True(默認值)，則進行row-copy以後，估算統計行數(使用explain select count(*)方式)，並調整ETA時間，不然，gh-ost首先預估統計行數，而後開始row-copy。

--exact-rowcount

準確統計表行數(使用select count(*)的方式)，獲得更準確的預估時間。

--execute

若是肯定執行，加上這個參數。

可選參數介紹

--default-retries

各類操做在panick前重試次數。(默認爲60)

--chunk-size

遷移過程是一步步分批次完成的，這個參數是指事務每次提交的行數，默認是1000。

--timestamp-old-table

使舊錶包含時間戳值，舊錶是在成功遷移結束時將原始表從新命名的內容。例如，若是表是gh_ost_test，那麼舊錶一般是_gh_ost_test_del。使用–timestamp-old-table後，它將是_gh_ost_test_20170221103147_del。

--throttle-http

提供一個HTTP端點，gh-ost將在給定的URL上發出HEAD請求，並在響應狀態碼不是200時進行限流。URL能夠經過交互式命令動態查詢和更新，空的URL表示禁用HTTP檢查。

--approve-renamed-columns

當作（change old_name new_name …）動做時，gh-ost分析語句以嘗試將舊列名稱與新列名稱相關聯，若是它檢測到確實是重命名操做，默認狀況下將會打印出信息並退出。但除非你提供–approve-renamed-columns，強制發出遷移操做。

若是你認爲gh-ost解析錯誤，而且實際上而且沒有重命名，你能夠改成傳入–skip-renamed-columns，這將致使gh-ost取消關聯列值，數據將不會在這些列之間複製。

--skip-foreign-key-checks

默認狀況下，gh-ost會驗證遷移表中存不存在外鍵，若是存在就會報錯並退出；在具備大量表的服務器上，此檢查可能須要很長時間。若是你肯定沒有外鍵存在（表沒有引用其餘表，也沒有被其餘表引用）並但願保存檢查時間，可使用–skip-foreign-key-checks。但若是表上有外鍵，使用這個參數則會清除外鍵，千萬注意。

--discard-foreign-keys

該操做很危險，意味着將默默丟棄表上存在的任何外鍵。目前，gh-ost不支持遷移表上的外鍵（當它在遷移表上注意到外鍵時，它會保留）。可是，它可以支持經過此標誌刪除外鍵，若是你想這麼幹，這是一個有用的選項。使用下來感受跟–skip-foreign-key-checks參數做用同樣。

--replica-server-id

gh-ost原理是經過模擬slave從而得到binlog，其默認server-id爲99999，若是你運行多個遷移，那麼你必須爲每一個gh-ost進程提供一個不一樣的，惟一的server-id。也可使用進程ID當作server-id，例如：–replica-server-id = $((1000000000 + ))。

--migrate-on-replica

一般，gh-ost用於在主服務器上遷移表。若是你只但願在從庫上執行所有遷移，使用–migrate-on-replica參數將gh-ost鏈接到從庫進行遷移。

--assume-master-host

默認狀況下，gh-ost更傾向鏈接從庫來進行遷移。gh-ost經過爬取複製拓撲來推斷主服務器的身份，你能夠經過–assume-master-host = the.master.com明確告訴gh-ost主服務器的身份。這在如下方面頗有用：
主 – 主拓撲結構（與–allow-master-master一塊兒使用），其中gh-ost能夠隨意選擇其中一個主協同者，這種狀況你能夠選擇一個特定的主庫。
tungsten複製器拓撲結構（與–tungsten一塊兒使用），其中gh-ost沒法抓取並檢測主節點。

--dml-batch-size

gh-ost從二進制日誌讀取事件，並將它們應用到ghost表上。它採用的方式是將多個事件分組應用於單個事務中。這能夠提供更好的寫入吞吐量，由於咱們不須要將每一個事務日誌同步到的磁盤。

此選項就是控制批量寫入的大小，容許的值是1 – 100，其中1表示不分組處理（二進制日誌中的每一個事件在其本身的事務中應用到ghost表上）。默認值是10。

--heartbeat-interval-millis

用來控制注入心跳事件的頻率（就是_xx_ghc表），用來測量主從延遲。你應該設置heartbeat-interval-millis <= max-lag-millis。不然，將失去粒度和效果。默認值100。其–max-lag-millis值應該在300-500之間。

--conf

指定gh-ost憑據的文件，以下格式。

[client]
user=gromit
password=123456

--debug

輸出詳細日誌。

--verbose

執行過程輸出日誌。

6、安裝使用gh-ost

直接使用二進制安裝便可

 

若是你安裝有什麼問題直接藉助搜索引擎應該就能夠解決。

而後在使用上，下面是一些通用的配置（採起在主庫進行DDL操做模式），你也能夠嘗試不一樣的配置根據上面配置的介紹來使用。


實際上變動的表若是有超長事務，依然存在mdl鎖問題致使失敗，由於在最後的新表舊錶交替階段，會有一個短暫的加鎖操做，而長事務會阻塞這個加鎖操做，因此還得在ddl前確認無長事務。

 

7、gh-ost交互式命令

gh-ost被設計爲操做友好。爲此，它容許用戶即便在運行時也能夠控制其行爲。gh-ost提供兩種方式來進行動態控制。

Unix套接字文件：經過–serve-socket-file提供或由gh-ost默認設置，該接口老是處於啓動狀態。當gh-ost自我設定時，gh-ost將在啓動時和整個遷移過程當中公佈套接字文件的標識文件。默認在/tmp下面，由gh-ost.庫名.代表.sock組成。

TCP：由–serve-tcp-port選項提供，默認沒有。

兩個接口能夠同時使用，二者都響應簡單的文本命令，這使得經過shell進行交互變得容易。

命令介紹：

help：顯示可用命令的簡要列表。

status：返回遷移進度和配置的詳細狀態摘要。

sup：返回遷移進度的簡要狀態摘要。

coordinates：返回檢查服務器的最近（儘管不是最新的）二進制日誌位置。

chunk-size=<newsize>：修改chunk大小，適用於下一刻數據複製。

dml-batch-size=<newsize>：適用於下一次應用二進制日誌事件數量。

max-lag-millis=<max-lag>：修改最大複製延遲閾值（毫秒，最小值是100，即0.1秒）。

max-load=<max-load-thresholds>：修改最大負載配置，適用於下一刻數據複製。如「max-load=Threads_running=50,threads_connected=1000」。

critical-load=<critical-load-thresholds>：修改臨界負載配置（超過這些閾值會停止操做）。

nice-ratio=<ratio>：修改nice比例，0表示不設置nice就是不睡眠線程。若是爲1則表示gh-ost檢測到複製行花費了1ms後將進行1*1ms睡眠；若是花費100ms，nice值爲0.5，則會睡眠50ms，以此類推。默認爲0。

throttle-http：改變HTTP端點。

throttle-query：改變查詢。

throttle-control-replicas=’replica1,replica2’：更改副本的列表，這些副本是gh-ost會檢查的，這須要用逗號分隔的副本列表來檢查並替換先前的列表。

throttle：強制遷移暫停。

no-throttle：取消強制遷移暫停。

unpostpone：在gh-ost推遲cut-over階段，指示gh-ost中止推遲並當即進行切換。

panic：理解放棄操做，意味着gh-ost將中斷全部操做。

下面給一些樣例：

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程