建站
咨詢
售后
建站咨詢
新聞中心
MySQL在線更改schema的工具很多，如Percona的pt-online-schema-change、 Facebook的 OSC 和 LHM 等，但這些都是基于觸發(fā)器(Trigger)的，今天咱們介紹的 gh-ost 號(hào)稱是不需要觸發(fā)器(Triggerless)支持的在線更改表結(jié)構(gòu)的工具。
成都創(chuàng)新互聯(lián)專注于網(wǎng)站建設(shè)|成都網(wǎng)站維護(hù)公司|優(yōu)化|托管以及網(wǎng)絡(luò)推廣，積累了大量的網(wǎng)站設(shè)計(jì)與制作經(jīng)驗(yàn)，為許多企業(yè)提供了網(wǎng)站定制設(shè)計(jì)服務(wù)，案例作品覆蓋搬家公司等行業(yè)。能根據(jù)企業(yè)所處的行業(yè)與銷(xiāo)售的產(chǎn)品，結(jié)合品牌形象的塑造，量身策劃品質(zhì)網(wǎng)站。
原文地址：gh-ost: GitHub's online schema migration tool for MySQL
本文先介紹一下當(dāng)前業(yè)界已經(jīng)存在的這些工具的使用場(chǎng)景和原理，然后再詳細(xì)介紹 gh-ost 的工作原理和特性。
今天我們開(kāi)源了GitHub內(nèi)部使用的一款 不需要觸發(fā)器支持的 MySQL 在線更改表結(jié)構(gòu)的工具 gh-ost
開(kāi)發(fā) gh-ost 是為了應(yīng)付GitHub在生產(chǎn)環(huán)境中面臨的持續(xù)的、不斷變化的在線修改表結(jié)構(gòu)的需求。gh-ost 通過(guò)提供低影響、可控、可審計(jì)和操作友好的解決方案改變了現(xiàn)有的在線遷移表工具的工作模式。
MySQL表遷移及結(jié)構(gòu)更改操作是業(yè)界眾所周知的問(wèn)題，2009年以來(lái)已經(jīng)可以通過(guò)在線(不停服務(wù))變更的工具來(lái)解決。迅速增長(zhǎng)，快速迭代的產(chǎn)品往往需要頻繁的需改數(shù)據(jù)庫(kù)的結(jié)構(gòu)。增加/更改/刪除/ 字段和索引等等，這些操作在MySQL中默認(rèn)都會(huì)鎖表，影響線上的服務(wù)。 向這種數(shù)據(jù)庫(kù)結(jié)構(gòu)層面的變更我們每天都會(huì)面臨多次，當(dāng)然這種操作不應(yīng)該影響用戶的正常服務(wù)。
在開(kāi)始介紹 gh-ost 工具之前，咱們先來(lái)看一下當(dāng)前現(xiàn)有的這些工具的解決方案。
在線修改表結(jié)構(gòu)，已存在的場(chǎng)景
如今，在線修改表結(jié)構(gòu)可以通過(guò)下面的三種方式來(lái)完成：
- 在從庫(kù)上修改表結(jié)構(gòu)，操作會(huì)在其他的從庫(kù)上生效，將結(jié)構(gòu)變更了的從庫(kù)設(shè)置為主庫(kù)
- 使用 MySQL InnoDB 存儲(chǔ)引擎提供的在線DDL特性
- 使用在線修改表結(jié)構(gòu)的工具。現(xiàn)在***的是 pt-online-schema-change 和 Facebook 的 OSC;當(dāng)然還有 LHM 和比較原始的 oak-online-alter-table 工具。
其他的還包括 Galera 集群的Schema滾動(dòng)更新，以及一些其他的非InnoDB的存儲(chǔ)引擎等待，在 GitHub 我們使用通用的 主-從 架構(gòu) 和 InnoDB 存儲(chǔ)引擎。
為什么我們決定開(kāi)始一個(gè)新的解決方案，而不是使用上面的提到的這些呢?現(xiàn)有的每種解決方案都有其局限性，下文會(huì)對(duì)這些方式的普遍問(wèn)題簡(jiǎn)單的說(shuō)明一下，但會(huì)對(duì)基于觸發(fā)器的在線變更工具的問(wèn)題進(jìn)行詳細(xì)說(shuō)明。
- 基于主從復(fù)制的遷移方式需要很多的前置工作，如：大量的主機(jī)，較長(zhǎng)的傳輸時(shí)間，復(fù)雜的管理等等。變更操作需要在一個(gè)指定的從庫(kù)上或者基于sub-tree的主從結(jié)構(gòu)中執(zhí)行。需要的情況也比較多，如：主機(jī)宕機(jī)、主機(jī)從早先的備份中恢復(fù)數(shù)據(jù)、新主機(jī)加入到集群等等，所有這些情況都有可能對(duì)我們的操作造成影響。最要命的是可能這些操作一天要進(jìn)行很多次，如果使用這種方法我們操作人員每天的效率是非常高的(譯者注：現(xiàn)如今很少有人用這種方式了吧)
- MySQL針對(duì)Innodb存儲(chǔ)引擎的在線DDL操作在開(kāi)始之前都需要一個(gè)短時(shí)間排它鎖(exclusive)來(lái)準(zhǔn)備環(huán)境，所以 alter命令發(fā)出后，會(huì)首先等待該表上的其它操作完成，在alter命令之后的請(qǐng)求會(huì)出現(xiàn)等待waiting meta data lock。同樣在ddl結(jié)束之前，也要等待alter期間所有的事務(wù)完成，也會(huì)堵塞一小段時(shí)間，這對(duì)于繁忙的數(shù)據(jù)庫(kù)服務(wù)來(lái)說(shuō)危險(xiǎn)系數(shù)是非常高的。另外 DDL操作不能中斷，如果中途kill掉，會(huì)造成長(zhǎng)時(shí)間的事務(wù)回滾，還有可能造成元數(shù)據(jù)的損壞。它操作起來(lái)并不那么的Nice，不能限流和暫停，在大負(fù)載的環(huán)境中甚至?xí)绊懻５臉I(yè)務(wù)。
- 我們用了很多年的 pt-online-schema-change 工具。然而隨著我們不斷增長(zhǎng)的業(yè)務(wù)和流量，我們遇到了很多的問(wèn)題，我們必須考慮在操作中的哪些 危險(xiǎn)操作 (譯者注：pt工具集的文檔中經(jīng)常會(huì)有一些危險(xiǎn)提示)。某些操作必須避開(kāi)高峰時(shí)段來(lái)進(jìn)行，否則MySQL可能就掛了。所有現(xiàn)存的在線表結(jié)構(gòu)修改的工具都是利用了MySQL的觸發(fā)器來(lái)執(zhí)行的，這種方式有一些潛藏的問(wèn)題。
基于觸發(fā)器的在線修改有哪些問(wèn)題呢?
所有在線表結(jié)構(gòu)修改工具的操作方式都類似：創(chuàng)建與原表結(jié)構(gòu)一致的臨時(shí)表，該臨時(shí)表已經(jīng)是按要求修改后的表結(jié)構(gòu)了，緩慢增量的從原表中復(fù)制數(shù)據(jù)，同時(shí)記錄原表的更改(所有的 INSERT, DELETE, UPDATE 操作) 并應(yīng)用到臨時(shí)表。當(dāng)工具確認(rèn)表數(shù)據(jù)已經(jīng)同步完成，它會(huì)進(jìn)行替換工作，將臨時(shí)表更名為原表。
pt-online-schema-change, LHM 和 oak-online-alter-table 這些工具都使用同步的方式，當(dāng)原表有變更操作時(shí)利用一些事務(wù)的間隙時(shí)間將這些變化同步到臨時(shí)表。Facebook 的工具使用異步的方式將變更寫(xiě)入到changelog表中，然后重復(fù)的將changelog表的變更應(yīng)用到臨時(shí)表。所有的這些工具都使用觸發(fā)器來(lái)識(shí)別原表的變更操作。
當(dāng)表中的每一行數(shù)據(jù)有 INSERT, DELETE, UPDATE 操作時(shí)都會(huì)調(diào)用存儲(chǔ)的觸發(fā)器。一個(gè)觸發(fā)器可能在一個(gè)事務(wù)空間中包含一系列查詢操作。這樣就會(huì)造成一個(gè)原子操作不單會(huì)在原表執(zhí)行，還會(huì)調(diào)用相應(yīng)的觸發(fā)器執(zhí)行多個(gè)操作。
在基于觸發(fā)器遷移實(shí)踐中，遇到了如下的問(wèn)題：
- 觸發(fā)器是以解釋型代碼的方式保存的。MySQL 不會(huì)預(yù)編譯這些代碼。 會(huì)在每次的事務(wù)空間中被調(diào)用，它們被添加到被操作的表的每個(gè)查詢行為之前的分析和解釋器中。
- 鎖表：觸發(fā)器在原始表查詢中共享相同的事務(wù)空間，而這些查詢?cè)谶@張表中會(huì)有競(jìng)爭(zhēng)鎖，觸發(fā)器在另外一張表會(huì)獨(dú)占競(jìng)爭(zhēng)鎖。在這種極端情況下，同步方式的鎖爭(zhēng)奪直接關(guān)系到主庫(kù)的并發(fā)寫(xiě)性能。以我們的經(jīng)驗(yàn)來(lái)說(shuō)，在生產(chǎn)環(huán)境中當(dāng)競(jìng)爭(zhēng)鎖接近或者結(jié)束時(shí)，數(shù)據(jù)庫(kù)可能會(huì)由于競(jìng)爭(zhēng)鎖而被阻塞住。觸發(fā)鎖的另一個(gè)方面是創(chuàng)建或銷(xiāo)毀時(shí)所需要的元數(shù)據(jù)鎖。我們?cè)?jīng)遇到過(guò)在繁忙的表中當(dāng)表結(jié)構(gòu)修改完成后，刪除觸發(fā)器可能需要數(shù)秒到分鐘的時(shí)間。
- 不可信：當(dāng)主庫(kù)的負(fù)載上升時(shí)，我們希望降速或者暫停操作，但基于觸發(fā)器的操作并不能這么做。雖然它可以暫停行復(fù)制操作，但卻不能暫停出觸發(fā)器，如果刪除觸發(fā)器可能會(huì)造成數(shù)據(jù)丟失，因此觸發(fā)器需要在整個(gè)操作過(guò)程中都要存在。在我們比較繁忙的服務(wù)器中就遇到過(guò)由于觸發(fā)器占用CPU資源而將主庫(kù)拖死的例子。
- 并發(fā)遷移：我們或者其他的人可能比較關(guān)注多個(gè)同時(shí)修改表結(jié)構(gòu)(不同的表)的場(chǎng)景。鑒于上述觸發(fā)器的開(kāi)銷(xiāo)，我們沒(méi)有興趣同時(shí)對(duì)多個(gè)表進(jìn)行在線修改操作，我們也不確定是否有人在生產(chǎn)環(huán)境中這樣做過(guò)。
- 測(cè)試：我們修改表結(jié)構(gòu)可能只是為了測(cè)試，或者評(píng)估其負(fù)載開(kāi)銷(xiāo)?；谟|發(fā)器的表結(jié)構(gòu)修改操作只能通過(guò)基于語(yǔ)句復(fù)制的方式來(lái)進(jìn)行模擬實(shí)驗(yàn)，離真實(shí)的主庫(kù)操作還有一定的距離，不能真實(shí)的反映實(shí)際情況。
gh-ost
gh-ost GitHub 的在線 Schema 修改工具，下面工作原理圖：
gh-ost 具有如下特性:
- 無(wú)觸發(fā)器
- 輕量級(jí)
- 可暫停
- 可動(dòng)態(tài)控制
- 可審計(jì)
- 可測(cè)試
- 值得信賴
無(wú)觸發(fā)器
gh-ost 沒(méi)有使用觸發(fā)器。它通過(guò)分析binlog日志的形式來(lái)監(jiān)聽(tīng)表中的數(shù)據(jù)變更。因此它的工作模式是異步的，只有當(dāng)原始表的更改被提交后才會(huì)將變更同步到臨時(shí)表(ghost table)
gh-ost 要求binlog是RBR格式 ( 基于行的復(fù)制);然而也不是說(shuō)你就不能在基于SBR(基于語(yǔ)句的復(fù)制)日志格式的主庫(kù)上執(zhí)行在線變更操作。實(shí)際上是可以的。gh-ost 可以將從庫(kù)的 SBR日志轉(zhuǎn)換為RBR日志，只需要重新配置就可以了。
輕量級(jí)
由于沒(méi)有使用觸發(fā)器，因此在操作的過(guò)程中對(duì)主庫(kù)的影響是最小的。當(dāng)然在操作的過(guò)程中也不用擔(dān)心并發(fā)和鎖的問(wèn)題。 變更操作都是以流的形式順序的寫(xiě)到binlog文件中，gh-ost只是讀取他們并應(yīng)用到gh-ost表中。實(shí)際上，gh-ost 通過(guò)讀取binlog的寫(xiě)事件來(lái)進(jìn)行順序的行復(fù)制操作。因此，主庫(kù)只會(huì)有一個(gè)單獨(dú)連接順序的將數(shù)據(jù)寫(xiě)入到臨時(shí)表(ghost table)。這和ETL操作有很大的不同。
可暫停
所有的寫(xiě)操作都是由gh-ost控制的，并且以異步的方式讀取binlog，當(dāng)限速的時(shí)候，gh-ost可以暫停向主庫(kù)寫(xiě)入數(shù)據(jù)，限速意味著不會(huì)在主庫(kù)進(jìn)行復(fù)制，也不會(huì)有行更新。當(dāng)限速時(shí)gh-ost會(huì)創(chuàng)建一個(gè)內(nèi)部的跟蹤(tracking)表，以最小的系統(tǒng)開(kāi)銷(xiāo)向這個(gè)表中寫(xiě)入心跳事件
gh-ost 支持多種方式的限速：
- 負(fù)載: 為熟悉 pt-online-schema-change 工具的用戶提供了類似的功能，可以設(shè)置MySQL中的狀態(tài)閾值，如 Threads_running=30
- 復(fù)制延遲: gh-ost 內(nèi)置了心跳機(jī)制，可以指定不同的從庫(kù)，從而對(duì)主從的復(fù)制延遲時(shí)間進(jìn)行監(jiān)控，如果達(dá)到了設(shè)定的延遲閾值程序會(huì)自動(dòng)進(jìn)入限速模式。
- 查詢: 用戶可以可以設(shè)置一個(gè)限流SQL，比如 SELECT HOUR(NOW()) BETWEEN 8 and 17 這樣就可以動(dòng)態(tài)的設(shè)置限流時(shí)間。
- 標(biāo)示文件: 可以通過(guò)創(chuàng)建一個(gè)標(biāo)示文件來(lái)讓程序限速，當(dāng)刪除文件后可以恢復(fù)正常操作。
- 用戶命令: 可以動(dòng)態(tài)的連接到 gh-ost (下文會(huì)提到) 通過(guò)網(wǎng)絡(luò)連接的方式實(shí)現(xiàn)限速。
可動(dòng)態(tài)控制
現(xiàn)在的工具，當(dāng)執(zhí)行操作的過(guò)程中發(fā)現(xiàn)負(fù)載上升了，DBA不得不終止操作，重新配置參數(shù)，如 chunk-size，然后重新執(zhí)行操作命令，我們發(fā)現(xiàn)這種方式效率非常低。
gh-ost 可以通過(guò) unix socket 文件或者TCP端口(可配置)的方式來(lái)監(jiān)聽(tīng)請(qǐng)求，操作者可以在命令運(yùn)行后更改相應(yīng)的參數(shù)，參考下面的例子：
- echo throttle | socat - /tmp/gh-ost.sock 打開(kāi)限速，同樣的，可以使用 no-throttle 來(lái)關(guān)閉限流。
- 改變執(zhí)行參數(shù): chunk-size=1500, max-lag-millis=2000, max-load=Thread_running=30 這些參數(shù)都可以在運(yùn)行時(shí)變更。
可審計(jì)
同樣的，使用上文提到的程序接口可以獲取 gh-ost 的狀態(tài)。gh-ost 可以報(bào)告當(dāng)前的進(jìn)度，主要參數(shù)的配置以及當(dāng)前服務(wù)器的標(biāo)示等等。這些信息都可以通過(guò)網(wǎng)絡(luò)接口取到，相對(duì)于傳統(tǒng)的tail日志的方式要靈活很多。
可測(cè)試
因?yàn)槿罩疚募椭鲙?kù)負(fù)載關(guān)系不大，因此在從庫(kù)上執(zhí)行修改表結(jié)構(gòu)的操作可以更真實(shí)的體現(xiàn)出這些操作鎖產(chǎn)生的實(shí)際影響。(雖然不是十分理想，后續(xù)我們會(huì)做優(yōu)化工作)。
gh-ost 內(nèi)建支持測(cè)試功能，通過(guò)使用 --test-on-replica 的參數(shù)來(lái)指定: 它可以在從庫(kù)上進(jìn)行變更操作，在操作結(jié)束時(shí)gh-ost 將會(huì)停止復(fù)制，交換表，反向交換表，保留2個(gè)表并保持同步，停止復(fù)制?？梢栽诳臻e時(shí)候測(cè)試和比較兩個(gè)表的數(shù)據(jù)情況。
這是我們?cè)贕itHub的生產(chǎn)環(huán)境中的測(cè)試：我們生產(chǎn)環(huán)境中有多個(gè)從庫(kù);部分從庫(kù)并不是為用戶提供服務(wù)的，而是用來(lái)對(duì)所有表運(yùn)行的連續(xù)覆蓋遷移測(cè)試。我們生產(chǎn)環(huán)境中的表，小的可能沒(méi)有數(shù)據(jù)，大的會(huì)達(dá)到數(shù)百GB，我們只是做個(gè)標(biāo)記，并不會(huì)正在的修改表結(jié)構(gòu)(engine=innodb)。當(dāng)每一個(gè)遷移結(jié)束后會(huì)停止復(fù)制，我們會(huì)對(duì)原表和臨時(shí)表的數(shù)據(jù)進(jìn)行完整的checksum確保他們的數(shù)據(jù)一致性。然后我們會(huì)恢復(fù)復(fù)制，再去操作下一張表。我們的生產(chǎn)環(huán)境的從庫(kù)中已經(jīng)通過(guò) gh-ost 成功的操作了很多表。
值得信賴
上文提到說(shuō)了這么多，都是為了提高大家對(duì) gh-ost 的信任程度。畢竟在業(yè)界它還是一個(gè)新手，類似的工具已經(jīng)存在了很多年了。
在***次試手之前我們建議用戶先在從庫(kù)上測(cè)試，校驗(yàn)數(shù)據(jù)的一致性。我們已經(jīng)在從庫(kù)上成功的進(jìn)行了數(shù)以千計(jì)的遷移操作。
如果在主庫(kù)上使用 gh-ost 用戶可以實(shí)時(shí)觀察主庫(kù)的負(fù)載情況，如果發(fā)現(xiàn)負(fù)載變化很大，可以通過(guò)上文提到的多種形式進(jìn)行限速，直到負(fù)載恢復(fù)正常，然后再通過(guò)命令微調(diào)參數(shù)，這樣可以動(dòng)態(tài)的控制操作風(fēng)險(xiǎn)。
如果遷移操作開(kāi)始后預(yù)完成計(jì)時(shí)間(ETA)顯示要到夜里2點(diǎn)才能完成，結(jié)束時(shí)候需要切換表，你是不是要留下來(lái)盯著?你可以通過(guò)標(biāo)記文件讓 gh-ost推遲切換操作。gh-ost 會(huì)完成行復(fù)制，但并不會(huì)切換表，它會(huì)持續(xù)的將原表的數(shù)據(jù)更新操作同步到臨時(shí)表中。你第二天來(lái)到辦公室，刪除標(biāo)記文件或者通過(guò)接口 echo unpostpone 告訴gh-ost開(kāi)始切換表。我們不想讓我們的軟件把使用者綁住，它應(yīng)該是為我們拜托束縛。
說(shuō)到 ETA, --exact-rowcount 參數(shù)你可能會(huì)喜歡。相對(duì)于一條漫長(zhǎng)的 SELECT COUNT(*) 語(yǔ)句，gh-ost 會(huì)預(yù)估出遷移操作所需要花費(fèi)的時(shí)間，還會(huì)根據(jù)當(dāng)前遷移的工作狀況更新預(yù)估時(shí)間。雖然ETA的時(shí)間隨時(shí)更改，但進(jìn)度百分比的顯示是準(zhǔn)確的。
gh-ost 操作模式
gh-ost 可以同時(shí)連接多個(gè)服務(wù)器，為了獲取二進(jìn)制的數(shù)據(jù)流，它會(huì)作為一個(gè)從庫(kù)，將數(shù)據(jù)從一個(gè)庫(kù)復(fù)制到另外一個(gè)。它有各種不同的操作模式，這取決于你的設(shè)置，配置，和要運(yùn)行遷移環(huán)境。
a. 連接到從庫(kù)，在主庫(kù)做遷移
這是 gh-ost 默認(rèn)的工作方式。gh-ost 將會(huì)檢查從庫(kù)狀態(tài)，找到集群結(jié)構(gòu)中的主庫(kù)并連接，接下來(lái)進(jìn)行遷移操作：
- 行數(shù)據(jù)在主庫(kù)上讀寫(xiě)
- 讀取從庫(kù)的二進(jìn)制日志，將變更應(yīng)用到主庫(kù)
- 在從庫(kù)收集表格式，字段&索引，行數(shù)等信息
- 在從庫(kù)上讀取內(nèi)部的變更事件(如心跳事件)
- 在主庫(kù)切換表
如果你的主庫(kù)的日志格式是 SBR，工具也可以正常工作。但從庫(kù)必須啟用二級(jí)制日志(log_bin, log_slave_updates) 并且設(shè)置 binlog_format=ROW ( gh-ost 是讀取從庫(kù)的二級(jí)制文件)。
如果直接在主庫(kù)上操作，當(dāng)然也需要二進(jìn)制日志格式是RBR。
b. 連接到主庫(kù)
如果你沒(méi)有從庫(kù)，或者不想使用從庫(kù)，你可以直接在主庫(kù)上操作。gh-ost 將會(huì)直接在主庫(kù)上進(jìn)行所有操作。你需要持續(xù)關(guān)注復(fù)制延遲問(wèn)題。
- 你的主庫(kù)的二進(jìn)制日志必須是 RBR 格式。
- 在這個(gè)模式中你必須指定 --allow-on-master 參數(shù)
c. 在從庫(kù)遷移/測(cè)試
該模式會(huì)在從庫(kù)執(zhí)行遷移操作。gh-ost 會(huì)簡(jiǎn)單的連接到主庫(kù)，此后所有的操作都在從庫(kù)執(zhí)行，不會(huì)對(duì)主庫(kù)進(jìn)行任何的改動(dòng)。整個(gè)操作過(guò)程中，gh-ost 將控制速度保證從庫(kù)可以及時(shí)的進(jìn)行數(shù)據(jù)同步
- --migrate-on-replica 表示 gh-ost 會(huì)直接在從庫(kù)上進(jìn)行遷移操作。即使在復(fù)制運(yùn)行階段也可以進(jìn)行表的切換操作。
- --test-on-replica 表示 遷移操作只是為了測(cè)試在切換之前復(fù)制會(huì)停止，然后會(huì)進(jìn)行切換操作，然后在切換回來(lái)，你的原始表最終還是原始表。兩個(gè)表都會(huì)保存下來(lái)，復(fù)制操作是停止的。你可以對(duì)這兩個(gè)表進(jìn)行一致性檢查等測(cè)試操作。
gh-ost at GitHub
我們已經(jīng)在所有線上所有的數(shù)據(jù)庫(kù)在線操作中使用了gh-ost ，我們每天都需要使用它，根據(jù)數(shù)據(jù)庫(kù)修改需求，可能每天要運(yùn)行多次。憑借其審計(jì)和控制功能我們已經(jīng)將它集成到了ChatOps流程中。我們的工程師可以清醒的了解到遷移操作的進(jìn)度，而且可以靈活的控制其行為。
開(kāi)源
gh-ost 在MIT的許可下發(fā)布到了開(kāi)源社區(qū)。
雖然gh-ost在使用中很穩(wěn)定，我們還在不斷的完善和改進(jìn)。我們將其開(kāi)源也歡迎社會(huì)各界的朋友能夠參與和貢獻(xiàn)。隨后我們會(huì)發(fā)布 貢獻(xiàn)和建議的頁(yè)面。
我們會(huì)積極的維護(hù) gh-ost 項(xiàng)目，同時(shí)希望廣大的用戶可以嘗試和測(cè)試這個(gè)工具，我們做了很大努力使之更值得信賴。
譯者注
gh-ost 是MySQL業(yè)界在線修改表結(jié)構(gòu)工具中的一名新秀，通常我們都是通過(guò)Percona的pt-online-schema-change工具來(lái)做這項(xiàng)工作，gh-ost的出現(xiàn)給我們帶來(lái)了一種全新的方式。本文是翻譯了一篇gh-ost的介紹文章，還沒(méi)有嘗試過(guò)這個(gè)工具。歡迎喜歡嘗鮮網(wǎng)友談?wù)勈褂酶惺堋?/p>
本文標(biāo)題：GitHub開(kāi)源的MySQL在線更改Schema工具
URL標(biāo)題：http://www.dlmjj.cn/article/djedcpp.html
