GitHub開源的MySQL在線更改Schema工具gh-ost是怎樣的

今天就跟大家聊聊有關GitHub開源的MySQL在線更改Schema工具gh-ost是怎樣的，可能很多人都不太了解，為了讓大家更加了解，小編給大家總結了以下內容，希望大家根據這篇文章可以有所收獲。

MySQL在線更改schema的工具很多，如Percona的pt-online-schema-change、 Facebook的 OSC 和 LHM  等，但這些都是基于觸發器(Trigger)的，今天咱們介紹的 gh-ost 號稱是不需要觸發器(Triggerless)支持的在線更改表結構的工具。

原文地址：gh-ost: GitHub's online schema migration tool for MySQL

本文先介紹一下當前業界已經存在的這些工具的使用場景和原理，然后再詳細介紹 gh-ost 的工作原理和特性。

今天我們開源了GitHub內部使用的一款 不需要觸發器支持的 MySQL 在線更改表結構的工具 gh-ost

開發 gh-ost 是為了應付GitHub在生產環境中面臨的持續的、不斷變化的在線修改表結構的需求。gh-ost  通過提供低影響、可控、可審計和操作友好的解決方案改變了現有的在線遷移表工具的工作模式。

MySQL表遷移及結構更改操作是業界眾所周知的問題，2009年以來已經可以通過在線(不停服務)變更的工具來解決。迅速增長，快速迭代的產品往往需要頻繁的需改數據庫的結構。增加/更改/刪除/  字段和索引等等，這些操作在MySQL中默認都會鎖表，影響線上的服務。  向這種數據庫結構層面的變更我們每天都會面臨多次，當然這種操作不應該影響用戶的正常服務。

在開始介紹 gh-ost 工具之前，咱們先來看一下當前現有的這些工具的解決方案。

在線修改表結構，已存在的場景

如今，在線修改表結構可以通過下面的三種方式來完成：

• 在從庫上修改表結構，操作會在其他的從庫上生效，將結構變更了的從庫設置為主庫

• 使用 MySQL InnoDB 存儲引擎提供的在線DDL特性

• 使用在線修改表結構的工具。現在***的是 pt-online-schema-change 和 Facebook 的 OSC;當然還有 LHM 和比較原始的  oak-online-alter-table 工具。

其他的還包括 Galera 集群的Schema滾動更新，以及一些其他的非InnoDB的存儲引擎等待，在 GitHub 我們使用通用的 主-從 架構 和  InnoDB 存儲引擎。

為什么我們決定開始一個新的解決方案，而不是使用上面的提到的這些呢?現有的每種解決方案都有其局限性，下文會對這些方式的普遍問題簡單的說明一下，但會對基于觸發器的在線變更工具的問題進行詳細說明。

• 基于主從復制的遷移方式需要很多的前置工作，如：大量的主機，較長的傳輸時間，復雜的管理等等。變更操作需要在一個指定的從庫上或者基于sub-tree的主從結構中執行。需要的情況也比較多，如：主機宕機、主機從早先的備份中恢復數據、新主機加入到集群等等，所有這些情況都有可能對我們的操作造成影響。最要命的是可能這些操作一天要進行很多次，如果使用這種方法我們操作人員每天的效率是非常高的(譯者注：現如今很少有人用這種方式了吧)

• MySQL針對Innodb存儲引擎的在線DDL操作在開始之前都需要一個短時間排它鎖(exclusive)來準備環境，所以  alter命令發出后，會首先等待該表上的其它操作完成，在alter命令之后的請求會出現等待waiting meta data  lock。同樣在ddl結束之前，也要等待alter期間所有的事務完成，也會堵塞一小段時間，這對于繁忙的數據庫服務來說危險系數是非常高的。另外  DDL操作不能中斷，如果中途kill掉，會造成長時間的事務回滾，還有可能造成元數據的損壞。它操作起來并不那么的Nice，不能限流和暫停，在大負載的環境中甚至會影響正常的業務。

• 我們用了很多年的 pt-online-schema-change 工具。然而隨著我們不斷增長的業務和流量，我們遇到了很多的問題，我們必須考慮在操作中的哪些  危險操作  (譯者注：pt工具集的文檔中經常會有一些危險提示)。某些操作必須避開高峰時段來進行，否則MySQL可能就掛了。所有現存的在線表結構修改的工具都是利用了MySQL的觸發器來執行的，這種方式有一些潛藏的問題。

基于觸發器的在線修改有哪些問題呢?

所有在線表結構修改工具的操作方式都類似：創建與原表結構一致的臨時表，該臨時表已經是按要求修改后的表結構了，緩慢增量的從原表中復制數據，同時記錄原表的更改(所有的  INSERT, DELETE, UPDATE 操作) 并應用到臨時表。當工具確認表數據已經同步完成，它會進行替換工作，將臨時表更名為原表。

pt-online-schema-change, LHM 和 oak-online-alter-table  這些工具都使用同步的方式，當原表有變更操作時利用一些事務的間隙時間將這些變化同步到臨時表。Facebook  的工具使用異步的方式將變更寫入到changelog表中，然后重復的將changelog表的變更應用到臨時表。所有的這些工具都使用觸發器來識別原表的變更操作。

當表中的每一行數據有 INSERT, DELETE, UPDATE  操作時都會調用存儲的觸發器。一個觸發器可能在一個事務空間中包含一系列查詢操作。這樣就會造成一個原子操作不單會在原表執行，還會調用相應的觸發器執行多個操作。

在基于觸發器遷移實踐中，遇到了如下的問題：

• 觸發器是以解釋型代碼的方式保存的。MySQL 不會預編譯這些代碼。  會在每次的事務空間中被調用，它們被添加到被操作的表的每個查詢行為之前的分析和解釋器中。

• 鎖表：觸發器在原始表查詢中共享相同的事務空間，而這些查詢在這張表中會有競爭鎖，觸發器在另外一張表會獨占競爭鎖。在這種極端情況下，同步方式的鎖爭奪直接關系到主庫的并發寫性能。以我們的經驗來說，在生產環境中當競爭鎖接近或者結束時，數據庫可能會由于競爭鎖而被阻塞住。觸發鎖的另一個方面是創建或銷毀時所需要的元數據鎖。我們曾經遇到過在繁忙的表中當表結構修改完成后，刪除觸發器可能需要數秒到分鐘的時間。

• 不可信：當主庫的負載上升時，我們希望降速或者暫停操作，但基于觸發器的操作并不能這么做。雖然它可以暫停行復制操作，但卻不能暫停出觸發器，如果刪除觸發器可能會造成數據丟失，因此觸發器需要在整個操作過程中都要存在。在我們比較繁忙的服務器中就遇到過由于觸發器占用CPU資源而將主庫拖死的例子。

• 并發遷移：我們或者其他的人可能比較關注多個同時修改表結構(不同的表)的場景。鑒于上述觸發器的開銷，我們沒有興趣同時對多個表進行在線修改操作，我們也不確定是否有人在生產環境中這樣做過。

• 測試：我們修改表結構可能只是為了測試，或者評估其負載開銷。基于觸發器的表結構修改操作只能通過基于語句復制的方式來進行模擬實驗，離真實的主庫操作還有一定的距離，不能真實的反映實際情況。

gh-ost

gh-ost GitHub 的在線 Schema 修改工具，下面工作原理圖：

gh-ost 具有如下特性:

• 無觸發器

• 輕量級

• 可暫停

• 可動態控制

• 可審計

• 可測試

• 值得信賴

無觸發器

gh-ost  沒有使用觸發器。它通過分析binlog日志的形式來監聽表中的數據變更。因此它的工作模式是異步的，只有當原始表的更改被提交后才會將變更同步到臨時表(ghost  table)

gh-ost 要求binlog是RBR格式 (  基于行的復制);然而也不是說你就不能在基于SBR(基于語句的復制)日志格式的主庫上執行在線變更操作。實際上是可以的。gh-ost 可以將從庫的  SBR日志轉換為RBR日志，只需要重新配置就可以了。

輕量級

由于沒有使用觸發器，因此在操作的過程中對主庫的影響是最小的。當然在操作的過程中也不用擔心并發和鎖的問題。  變更操作都是以流的形式順序的寫到binlog文件中，gh-ost只是讀取他們并應用到gh-ost表中。實際上，gh-ost  通過讀取binlog的寫事件來進行順序的行復制操作。因此，主庫只會有一個單獨連接順序的將數據寫入到臨時表(ghost  table)。這和ETL操作有很大的不同。

可暫停

所有的寫操作都是由gh-ost控制的，并且以異步的方式讀取binlog，當限速的時候，gh-ost可以暫停向主庫寫入數據，限速意味著不會在主庫進行復制，也不會有行更新。當限速時gh-ost會創建一個內部的跟蹤(tracking)表，以最小的系統開銷向這個表中寫入心跳事件

gh-ost 支持多種方式的限速：

• 負載: 為熟悉 pt-online-schema-change 工具的用戶提供了類似的功能，可以設置MySQL中的狀態閾值，如  Threads_running=30

• 復制延遲: gh-ost 內置了心跳機制，可以指定不同的從庫，從而對主從的復制延遲時間進行監控，如果達到了設定的延遲閾值程序會自動進入限速模式。

• 查詢: 用戶可以可以設置一個限流SQL，比如 SELECT HOUR(NOW()) BETWEEN 8 and 17  這樣就可以動態的設置限流時間。

• 標示文件: 可以通過創建一個標示文件來讓程序限速，當刪除文件后可以恢復正常操作。

• 用戶命令: 可以動態的連接到 gh-ost (下文會提到) 通過網絡連接的方式實現限速。

可動態控制

現在的工具，當執行操作的過程中發現負載上升了，DBA不得不終止操作，重新配置參數，如  chunk-size，然后重新執行操作命令，我們發現這種方式效率非常低。

gh-ost 可以通過 unix socket  文件或者TCP端口(可配置)的方式來監聽請求，操作者可以在命令運行后更改相應的參數，參考下面的例子：

• echo throttle | socat - /tmp/gh-ost.sock 打開限速，同樣的，可以使用 no-throttle 來關閉限流。

• 改變執行參數: chunk-size=1500, max-lag-millis=2000, max-load=Thread_running=30  這些參數都可以在運行時變更。

可審計

同樣的，使用上文提到的程序接口可以獲取 gh-ost 的狀態。gh-ost  可以報告當前的進度，主要參數的配置以及當前服務器的標示等等。這些信息都可以通過網絡接口取到，相對于傳統的tail日志的方式要靈活很多。

可測試

因為日志文件和主庫負載關系不大，因此在從庫上執行修改表結構的操作可以更真實的體現出這些操作鎖產生的實際影響。(雖然不是十分理想，后續我們會做優化工作)。

gh-ost 內建支持測試功能，通過使用 --test-on-replica 的參數來指定: 它可以在從庫上進行變更操作，在操作結束時gh-ost  將會停止復制，交換表，反向交換表，保留2個表并保持同步，停止復制。可以在空閑時候測試和比較兩個表的數據情況。

這是我們在GitHub的生產環境中的測試：我們生產環境中有多個從庫;部分從庫并不是為用戶提供服務的，而是用來對所有表運行的連續覆蓋遷移測試。我們生產環境中的表，小的可能沒有數據，大的會達到數百GB，我們只是做個標記，并不會正在的修改表結構(engine=innodb)。當每一個遷移結束后會停止復制，我們會對原表和臨時表的數據進行完整的checksum確保他們的數據一致性。然后我們會恢復復制，再去操作下一張表。我們的生產環境的從庫中已經通過  gh-ost 成功的操作了很多表。

值得信賴

上文提到說了這么多，都是為了提高大家對 gh-ost 的信任程度。畢竟在業界它還是一個新手，類似的工具已經存在了很多年了。

在***次試手之前我們建議用戶先在從庫上測試，校驗數據的一致性。我們已經在從庫上成功的進行了數以千計的遷移操作。

如果在主庫上使用 gh-ost  用戶可以實時觀察主庫的負載情況，如果發現負載變化很大，可以通過上文提到的多種形式進行限速，直到負載恢復正常，然后再通過命令微調參數，這樣可以動態的控制操作風險。

如果遷移操作開始后預完成計時間(ETA)顯示要到夜里2點才能完成，結束時候需要切換表，你是不是要留下來盯著?你可以通過標記文件讓  gh-ost推遲切換操作。gh-ost 會完成行復制，但并不會切換表，它會持續的將原表的數據更新操作同步到臨時表中。你第二天來到辦公室，刪除標記文件或者通過接口  echo unpostpone 告訴gh-ost開始切換表。我們不想讓我們的軟件把使用者綁住，它應該是為我們拜托束縛。

說到 ETA, --exact-rowcount 參數你可能會喜歡。相對于一條漫長的 SELECT COUNT(*) 語句，gh-ost  會預估出遷移操作所需要花費的時間，還會根據當前遷移的工作狀況更新預估時間。雖然ETA的時間隨時更改，但進度百分比的顯示是準確的。

gh-ost 操作模式

gh-ost  可以同時連接多個服務器，為了獲取二進制的數據流，它會作為一個從庫，將數據從一個庫復制到另外一個。它有各種不同的操作模式，這取決于你的設置，配置，和要運行遷移環境。

a. 連接到從庫，在主庫做遷移

這是 gh-ost 默認的工作方式。gh-ost 將會檢查從庫狀態，找到集群結構中的主庫并連接，接下來進行遷移操作：

• 行數據在主庫上讀寫

• 讀取從庫的二進制日志，將變更應用到主庫

• 在從庫收集表格式，字段&索引，行數等信息

• 在從庫上讀取內部的變更事件(如心跳事件)

• 在主庫切換表

如果你的主庫的日志格式是 SBR，工具也可以正常工作。但從庫必須啟用二級制日志(log_bin, log_slave_updates) 并且設置  binlog_format=ROW ( gh-ost 是讀取從庫的二級制文件)。

如果直接在主庫上操作，當然也需要二進制日志格式是RBR。

b. 連接到主庫

如果你沒有從庫，或者不想使用從庫，你可以直接在主庫上操作。gh-ost 將會直接在主庫上進行所有操作。你需要持續關注復制延遲問題。

• 你的主庫的二進制日志必須是 RBR 格式。

• 在這個模式中你必須指定 --allow-on-master 參數

c. 在從庫遷移/測試

該模式會在從庫執行遷移操作。gh-ost 會簡單的連接到主庫，此后所有的操作都在從庫執行，不會對主庫進行任何的改動。整個操作過程中，gh-ost  將控制速度保證從庫可以及時的進行數據同步

• --migrate-on-replica 表示 gh-ost 會直接在從庫上進行遷移操作。即使在復制運行階段也可以進行表的切換操作。

• --test-on-replica 表示  遷移操作只是為了測試在切換之前復制會停止，然后會進行切換操作，然后在切換回來，你的原始表最終還是原始表。兩個表都會保存下來，復制操作是停止的。你可以對這兩個表進行一致性檢查等測試操作。

gh-ost at GitHub

我們已經在所有線上所有的數據庫在線操作中使用了gh-ost  ，我們每天都需要使用它，根據數據庫修改需求，可能每天要運行多次。憑借其審計和控制功能我們已經將它集成到了ChatOps流程中。我們的工程師可以清醒的了解到遷移操作的進度，而且可以靈活的控制其行為。

開源

gh-ost 在MIT的許可下發布到了開源社區。

雖然gh-ost在使用中很穩定，我們還在不斷的完善和改進。我們將其開源也歡迎社會各界的朋友能夠參與和貢獻。隨后我們會發布 貢獻和建議的頁面。

我們會積極的維護 gh-ost 項目，同時希望廣大的用戶可以嘗試和測試這個工具，我們做了很大努力使之更值得信賴。

看完上述內容，你們對GitHub開源的MySQL在線更改Schema工具gh-ost是怎樣的有進一步的了解嗎？如果還想了解更多知識或者相關內容，請關注億速云行業資訊頻道，感謝大家的支持。