[[419285]]

圖片來(lái)自 包圖網(wǎng)

在升級(jí)到 5.7 的同時(shí)構(gòu)建一個(gè)新的存儲(chǔ)引擎，會(huì)大大減慢 MyRocks 的進(jìn)度，因此我們選擇繼續(xù)使用 5.6，直到 MyRocks 完成，MySQL 5.6 的壽命也即將結(jié)束，決定升級(jí)到 MySQL 8.0 。

官博介紹說(shuō)，此次過(guò)程比之前的升級(jí)更具挑戰(zhàn)。MySQL 是 Oracle 公司旗下的一個(gè)開(kāi)源數(shù)據(jù)庫(kù)，它為 Facebook 的一些最重要的工作負(fù)載提供了動(dòng)力。我們積極開(kāi)發(fā) MySQL 中的新特性，以支持不斷演化的需求。

這些特性對(duì)MySQL的許多方面進(jìn)行了修改，包括客戶機(jī)連接器、存儲(chǔ)引擎、優(yōu)化器以及復(fù)制。

為了遷移工作負(fù)載，對(duì)于每個(gè)新的 MySQL 主版本，我們都需要投入大量的時(shí)間和精力。

其中的挑戰(zhàn)包括：

• 將自定義功能移植到新版本。
• 確保主要版本之間的復(fù)制兼容。
• 最小化現(xiàn)有應(yīng)用程序查詢所需的更改。
• 對(duì)阻礙服務(wù)器支持我們工作負(fù)載的性能退化進(jìn)行修復(fù)。

我們最近一次的主版本升級(jí)是到 MySQL 5.6，它花了一年多的時(shí)間才推出。當(dāng)5.7 版發(fā)布時(shí)，我們還在 5.6 版上開(kāi)發(fā) LSM 樹(shù)存儲(chǔ)引擎和 MyRocks。

在升級(jí)到 5.7 的同時(shí)構(gòu)建一個(gè)新的存儲(chǔ)引擎，會(huì)大大減慢 MyRocks 的進(jìn)度，因此我們選擇繼續(xù)使用 5.6，直到 MyRocks 完成。

MySQL 8.0 發(fā)布之際，我們正在做 MyRocks 向用戶數(shù)據(jù)庫(kù)(UDB)服務(wù)層推出的收尾。

該版本包括一些引人注目的特性，如基于寫集的并行復(fù)制和提供原子 DDL 支持的事務(wù)數(shù)據(jù)字典等。

對(duì)我們來(lái)說(shuō)，遷移到 8.0 還將帶來(lái)包括文檔存儲(chǔ)在內(nèi)的，我們已經(jīng)錯(cuò)過(guò)的 5.7 特性。

版本 5.6 的使命即將結(jié)束，我們希望在 MySQL 社區(qū)中保持活躍，尤其是在 MyRocks 存儲(chǔ)引擎上的工作。

8.0 中的增強(qiáng)功能，比如即時(shí) DDL，可以加快 MyRocks 的模式更改，但是我們需要在 8.0 的代碼庫(kù)中使用它。

考慮到更新代碼的好處，我們決定遷移到 8.0。下面將分享我們?nèi)绾谓鉀Q 8.0 遷移項(xiàng)目的難題，以及在這個(gè)過(guò)程中發(fā)現(xiàn)的一些驚喜。

當(dāng)最初確定項(xiàng)目范圍時(shí)，可以明確的是，遷移到 8.0 會(huì)比遷移到 5.6 或 MyRocks 更困難：

• 當(dāng)時(shí)，我們定制的 5.6 分支有 1700 多個(gè)代碼補(bǔ)丁需要移植到 8.0。在我們移植這些更改時(shí)，新的 Facebook 的 MySQL 特性和修復(fù)已被添加到 5.6 的代碼庫(kù)中，從而使目標(biāo)變得更加遙不可及。
• 我們有許多 MySQL 服務(wù)器在生產(chǎn)環(huán)境中運(yùn)行，為大量截然不同的應(yīng)用程序提供服務(wù)。我們還有眾多管理 MySQL 實(shí)例的軟件架構(gòu)。這些應(yīng)用執(zhí)行諸如收集統(tǒng)計(jì)數(shù)據(jù)或管理服務(wù)器備份之類的操作。
• 從 5.6 升級(jí)到 8.0 完全跳過(guò)了 5.7。在 5.6 中處于活動(dòng)狀態(tài)的 API 在 5.7 中可能被棄用，而在 8.0 中可能會(huì)被移除，這要求我們必須更新所有使用了現(xiàn)已刪除 API 的應(yīng)用程序。
• 許多 Facebook 功能與 8.0 中的類似功能并不向前兼容，需要一種棄用或遷移途徑。
• MyRocks 的增強(qiáng)功能需要在 8.0 中運(yùn)行，包括本地化分區(qū)和崩潰恢復(fù)。

代碼補(bǔ)丁

首先我們建立了 8.0 分支，用于在開(kāi)發(fā)環(huán)境中進(jìn)行構(gòu)建和測(cè)試。然后，我們開(kāi)始從 5.6 分支移植補(bǔ)丁的漫長(zhǎng)過(guò)程。開(kāi)始的時(shí)候有 1700 多個(gè)補(bǔ)丁，但我們能將其組織成幾個(gè)主要類別。

我們的大多數(shù)自定義代碼都有很好的注釋和描述，因此可以很容易地確定應(yīng)用程序是否仍然需要它，或者是否可以將它刪除。

通過(guò)特殊關(guān)鍵字或唯一變量名所啟用的功能，也使得確定關(guān)聯(lián)變得很容易，因?yàn)槲覀兛梢运阉鲬?yīng)用程序代碼庫(kù)來(lái)找到它們的用例。

有些補(bǔ)丁非常晦澀難懂，需要做調(diào)查工作 — 挖掘舊的設(shè)計(jì)文檔、郵件或代碼評(píng)審注釋，以了解它們的歷史。

我們將每個(gè)補(bǔ)丁分入四類之一：

• Drop：不再使用，或在 8.0 中具有同等功能的特性，不需要移植。
• Build/Client：支持我們構(gòu)建環(huán)境的非服務(wù)器特性，修改過(guò)的 MySQL 工具，比如 mysqlbinlog，或者增加的功能，如異步客戶端 API 等，需要移植。
• 非 MyRocks 服務(wù)器：mysqld 服務(wù)器中與 MyRocks 存儲(chǔ)引擎無(wú)關(guān)的特性，需要移植。
• MyRocks 服務(wù)器：支持 MyRocks 存儲(chǔ)引擎的特性，需要移植。

我們使用電子表格跟蹤每個(gè)補(bǔ)丁的狀態(tài)和相關(guān)歷史信息，并且在刪除補(bǔ)丁時(shí)記錄理由。

更新相同特性的多個(gè)補(bǔ)丁被組在一起進(jìn)行移植。移植并提交到 8.0 分支的補(bǔ)丁，用 5.6 提交信息進(jìn)行了注釋。

由于我們需要篩選大量的補(bǔ)丁，將不可避免地出現(xiàn)移植狀態(tài)上的差異，這些注釋幫助我們解決了此類問(wèn)題。

客戶端和服務(wù)器類別中的每個(gè)補(bǔ)丁都自然而然地成為一個(gè)軟件發(fā)布里程碑。隨著所有與客戶端相關(guān)的更改的移植，我們能夠?qū)⒖蛻舳斯ぞ吆瓦B接器代碼更新到 8.0。

一旦所有非 MyRocks 服務(wù)器特性都被移植，我們就可以為 InnoDB 服務(wù)器部署 8.0 mysqld 了。完成 MyRocks 服務(wù)器特性移植使我們能夠更新 MyRocks 安裝。

有些復(fù)雜特性需要對(duì) 8.0 進(jìn)行重大更改，一些方面存在很大的兼容性問(wèn)題。例如，上游 8.0 binlog 事件格式與我們一些對(duì) 5.6 的定制修改不兼容。

Facebook 5.6 特性使用的錯(cuò)誤代碼與上游 8.0 分配給新特性的錯(cuò)誤代碼沖突。我們最終需要修補(bǔ) 5.6 服務(wù)器，以使其與 8.0 向前兼容。

完成所有這些特性的移植花了幾年時(shí)間。到最終結(jié)束時(shí)，我們已經(jīng)評(píng)估了 2300 多個(gè)補(bǔ)丁，并將其中 1500 個(gè)移植到了 8.0 版本。

遷移途徑

我們將多個(gè) mysqld 實(shí)例組合到一個(gè) MySQL 副本集中。副本集中的每個(gè)實(shí)例都包含相同的數(shù)據(jù)，但在地理上分布到不同的數(shù)據(jù)中心，以提供數(shù)據(jù)可用性和故障切換支持。

每個(gè)副本集都有一個(gè)主實(shí)例。其余的實(shí)例都是從實(shí)例。主實(shí)例處理所有寫流量，并將數(shù)據(jù)異步復(fù)制到所有從實(shí)例。

由 5.6 主/ 5.6 從所組成的副本集開(kāi)始，最終目標(biāo)是包含 8.0 主/ 8.0 從的副本集。

我們遵循一個(gè)類似于 UDB MyRocks migration plan 的遷移規(guī)劃：

• 對(duì)于每個(gè)副本集，通過(guò)一個(gè)使用 mysqldump 生成的邏輯備份，創(chuàng)建并添加到 8.0 的從實(shí)例。這些從實(shí)例不提供任何應(yīng)用程序讀取流量。
• 在 8.0 從實(shí)例上開(kāi)啟讀取流量。
• 允許將 8.0 從實(shí)例升級(jí)為主實(shí)例。
• 禁用 5.6 實(shí)例的讀取流量。
• 移除所有 5.6 實(shí)例。

每個(gè)副本集可以獨(dú)立地通過(guò)上述步驟進(jìn)行遷移，并可根據(jù)需要停留在一個(gè)步驟上。

我們將副本集分成更小的組，在組中進(jìn)行每一次遷移。如果發(fā)現(xiàn)問(wèn)題，我們可以回滾到上一步。在某些情況下，副本集能夠在其它副本集開(kāi)始之前到達(dá)最后一步。

為了自動(dòng)化遷移大量副本集，我們需要構(gòu)建新的軟件架構(gòu)。可以通過(guò)簡(jiǎn)單地更改配置文件中的一行，將副本集組合并在每個(gè)階段中移動(dòng)它們。任何遇到問(wèn)題的副本集都能單獨(dú)回滾。

基于行的復(fù)制

作為 8.0 遷移工作的一部分，我們決定將使用基于行的復(fù)制(row-based replication，RBR)作為標(biāo)準(zhǔn)。一些 8.0 特性需要 RBR，并且它簡(jiǎn)化了 MyRocks 的移植工作。

我們的大多數(shù) MySQL 副本集已經(jīng)在使用 RBR，而那些仍然運(yùn)行基于語(yǔ)句的復(fù)制(statement-based replication，SBR)的副本集不容易遷移。

這些副本集通常有不含任何高基數(shù)鍵的表。完全轉(zhuǎn)向 RBR 是一個(gè)目標(biāo)，但添加主鍵所需的長(zhǎng)尾工作的優(yōu)先級(jí)往往低于其它項(xiàng)目。

因此，我們將 RBR 作為 8.0 的要求。在評(píng)估并向每個(gè)表添加主鍵之后，我們今年切換了最后一個(gè) SBR 副本集。

使用 RBR 還為我們提供了一個(gè)解決應(yīng)用程序問(wèn)題的替代解決方案，我們?cè)趯⒁恍└北炯苿?dòng)到 8.0 主實(shí)例時(shí)遇到了這個(gè)問(wèn)題，將在后面討論。

自動(dòng)化驗(yàn)證

大多數(shù) 8.0 遷移過(guò)程都涉及使用我們的自動(dòng)化架構(gòu)和應(yīng)用查詢來(lái)測(cè)試和驗(yàn)證 mysqld 服務(wù)器。

我們用來(lái)管理服務(wù)器的自動(dòng)化基礎(chǔ)架構(gòu)在隨著 MySQL 服務(wù)器的增長(zhǎng)而增長(zhǎng)。為了確保所有 MySQL 自動(dòng)化組件都與 8.0 版本兼容，我們投資構(gòu)建了一個(gè)測(cè)試環(huán)境，該環(huán)境利用虛擬機(jī)上的測(cè)試副本集來(lái)驗(yàn)證行為。

我們?yōu)?canary 編寫了在 5.6 版本和 8.0 版本上運(yùn)行的每個(gè)自動(dòng)化組件的集成測(cè)試，并驗(yàn)證了它們的正確性。在進(jìn)行此演練時(shí)，我們發(fā)現(xiàn)了幾個(gè)錯(cuò)誤和行為差異。

當(dāng) MySQL 架構(gòu)的每一部分都在我們的 8.0 服務(wù)器上進(jìn)行驗(yàn)證時(shí)，我們發(fā)現(xiàn)并修復(fù)了(或解決了)一些有趣的問(wèn)題：

解析錯(cuò)誤日志、mysqldump 輸出或服務(wù)器 show 命令的文本輸出的軟件很容易損壞。服務(wù)器輸出的細(xì)微變化常常會(huì)暴露出工具解析邏輯中的錯(cuò)誤。

8.0 的默認(rèn) utf8mb4 排序規(guī)則設(shè)置導(dǎo)致 5.6 和 8.0 實(shí)例之間的排序規(guī)則不匹配。

8.0 表可能會(huì)使用新的 utf8mb4_0900 排序規(guī)則，即使對(duì)于由 5.6 的show create table生成的create語(yǔ)句也是如此，因?yàn)槭褂胾tf8mb4_general_ci 的 5.6 模式?jīng)]有顯式指定排序規(guī)則。

這些表差異通常會(huì)導(dǎo)致復(fù)制和模式驗(yàn)證工具出現(xiàn)問(wèn)題;某些復(fù)制失敗的錯(cuò)誤代碼發(fā)生了變化，我們必須修復(fù)我們的自動(dòng)化程序來(lái)正確處理它們。

8.0 版本的數(shù)據(jù)字典廢棄了 table.frm 文件，但是我們的一些自動(dòng)化系統(tǒng)使用它們來(lái)檢測(cè)表模式的修改。

我們必須更新自動(dòng)化系統(tǒng)，以支持 8.0 中引入的動(dòng)態(tài)權(quán)限。

應(yīng)用程序驗(yàn)證

我們希望遷移對(duì)應(yīng)用程序盡可能透明，但是有些應(yīng)用程序的查詢會(huì)出現(xiàn)性能退化，或者在 8.0 上會(huì)失敗。

對(duì)于 MyRocks 遷移，我們構(gòu)建了一個(gè) MySQL 影子測(cè)試框架，該框架捕獲生產(chǎn)流量并將其重放到測(cè)試實(shí)例中。

對(duì)于每個(gè)應(yīng)用程序工作負(fù)載，我們?cè)?8.0 上創(chuàng)建了測(cè)試實(shí)例，并向它們回放影子流量的查詢。

我們捕獲并記錄了從 8.0 服務(wù)器返回的錯(cuò)誤，并發(fā)現(xiàn)了一些有趣的問(wèn)題。不幸的是，并非所有這些問(wèn)題都是在測(cè)試過(guò)程中發(fā)現(xiàn)的。

例如，事務(wù)死鎖是應(yīng)用程序在遷移過(guò)程中發(fā)現(xiàn)的。在研究不同的解決方案時(shí)，我們可以暫時(shí)將這些應(yīng)用程序回滾到 5.6 版本。

8.0 引入了新的保留關(guān)鍵字，其中一些關(guān)鍵字，如 groups 和 rank，與應(yīng)用程序查詢中常用的表列名或別名相沖突。這些查詢沒(méi)有通過(guò)反引號(hào)轉(zhuǎn)義名稱，導(dǎo)致解析錯(cuò)誤。

使用了自動(dòng)轉(zhuǎn)義查詢中列名的軟件庫(kù)的應(yīng)用程序沒(méi)有遇到這些問(wèn)題，但并非所有應(yīng)用程序都使用這些軟件庫(kù)。

解決這個(gè)問(wèn)題很簡(jiǎn)單，但是需要時(shí)間來(lái)跟蹤生成這些查詢的應(yīng)用程序?qū)僦骱痛a庫(kù)。

在 5.6 和 8.0 之間還發(fā)現(xiàn)了有些 REGEXP 不兼容。

一些包含在 InnoDB 上的 insert ... on duplicate key 查詢的應(yīng)用程序遇到了 repeatable-read 事務(wù)死鎖。

5.6 有一個(gè) bug，在 8.0 中得到了修復(fù)，但是修復(fù)增加了事務(wù)死鎖的可能性。

在分析了查詢之后，我們能夠通過(guò)降低隔離級(jí)別來(lái)解決該問(wèn)題。這個(gè)選項(xiàng)對(duì)我們來(lái)說(shuō)是可用的，因?yàn)槲覀円呀?jīng)切換到基于行的復(fù)制。

我們自定義的 5.6 文檔存儲(chǔ)和 JSON 函數(shù)與 8.0 不兼容。使用文檔存儲(chǔ)的應(yīng)用程序需要將文檔類型轉(zhuǎn)換為文本以進(jìn)行遷移。

對(duì)于 JSON 函數(shù)，我們向 8.0 服務(wù)器中添加了兼容 5.6 的版本，以便應(yīng)用程序以后可以遷移到 8.0 API。

我們對(duì) 8.0 服務(wù)器的查詢和性能測(cè)試發(fā)現(xiàn)了一些需要立即解決的問(wèn)題：

• 我們發(fā)現(xiàn)在 ACL 緩存部分出現(xiàn)了新的互斥爭(zhēng)用熱點(diǎn)。當(dāng)大量連接同時(shí)打開(kāi)時(shí)，它們都會(huì)阻塞 ACL 檢查。
• 當(dāng)存在大量 binlog 文件并且 binlog 的高速寫入導(dǎo)致頻繁輪換文件時(shí)，binlog 索引訪問(wèn)也發(fā)現(xiàn)了類似的爭(zhēng)用。
• 幾個(gè)涉及臨時(shí)表的查詢被中斷。這些查詢會(huì)返回意外錯(cuò)誤，或者運(yùn)行時(shí)間太長(zhǎng)以致超時(shí)。

內(nèi)存使用量與 5.6 相比有所增加，特別是對(duì)于 MyRocks 實(shí)例，因?yàn)楸仨毤虞d 8.0 中的 InnoDB 。

默認(rèn)的 performance_schema 設(shè)置啟用了所有工具集并消耗了大量?jī)?nèi)存。我們限制了內(nèi)存使用，只啟用了少量的工具，并對(duì)代碼進(jìn)行了更改，以禁用無(wú)法手動(dòng)關(guān)閉的表。

然而，并不是所有增加的內(nèi)存都是分配給 performance_schema 的。我們需要檢查和修改各種 InnoDB 內(nèi)部數(shù)據(jù)結(jié)構(gòu)，以進(jìn)一步減少內(nèi)存占用。這一努力使 8.0 的內(nèi)存使用率降到了可以接受的水平。

接下來(lái)的工作

到目前為止，8.0 的移植已經(jīng)花了幾年時(shí)間。我們已將許多 InnoDB 副本集轉(zhuǎn)換為完全在 8.0 上運(yùn)行。剩下的大部分都處于遷移途徑的不同階段。

現(xiàn)在，我們的大多數(shù)定制功能都已移植到 8.0，更新到 Oracle 的次版本相對(duì)容易些，我們計(jì)劃跟上最新版本的步伐。

跳過(guò) 5.7 這樣的主版本會(huì)帶來(lái)一些問(wèn)題，我們的遷移需要解決這些問(wèn)題。

首先，我們無(wú)法就地升級(jí)服務(wù)器，需要使用邏輯轉(zhuǎn)儲(chǔ)和還原來(lái)構(gòu)建新服務(wù)器。

但是，對(duì)于非常大的 mysqld 實(shí)例，這可能需要在活躍生產(chǎn)服務(wù)器上運(yùn)行很多天，而且這個(gè)脆弱的過(guò)程可能會(huì)在完成之前被中斷。對(duì)于這些大型實(shí)例，我們必須修改備份和恢復(fù)系統(tǒng)來(lái)應(yīng)對(duì)重建。

其次，檢測(cè) API 更改要困難得多，因?yàn)?5.7 可能會(huì)向我們的應(yīng)用程序客戶端發(fā)出不推薦警告，以提示修復(fù)潛在的問(wèn)題。

而我們需要在遷移生產(chǎn)工作負(fù)載之前，運(yùn)行額外的影子測(cè)試來(lái)查找失敗。使用自動(dòng)轉(zhuǎn)義模式對(duì)象名稱的 mysql 客戶端軟件，有助于減少兼容性問(wèn)題的數(shù)量。

在一個(gè)副本集中支持兩個(gè)主版本非常困難。一旦副本集將其主實(shí)例升級(jí)為 8.0，最好盡快禁用并移除 5.6 實(shí)例。

應(yīng)用程序用戶往往會(huì)發(fā)現(xiàn)只有 8.0 支持的新特性，比如 utf8mb4_0900 排序規(guī)則，使用這些排序規(guī)則可能中斷 8.0 和 5.6 實(shí)例之間的復(fù)制流。

盡管我們?cè)谶w移過(guò)程中遇到了種種障礙，但我們已經(jīng)看到了運(yùn)行 8.0 帶來(lái)的好處。

一些應(yīng)用程序選擇了提早遷移到 8.0，以利用諸如文檔存儲(chǔ)和改進(jìn)的日期時(shí)間支持等功能。

我們一直在考慮如何在 MyRocks 上支持像即時(shí) DDL 這樣的存儲(chǔ)引擎特性。總的來(lái)說(shuō)，新版本大大擴(kuò)展了 MySQL@Facebook 的功能。

作者：Herman Lee，Pradeep Nayak，譯者：王雪迎

編輯：陶家龍

出處：轉(zhuǎn)載自公眾號(hào)CSDN(ID：CSDNnews)

鏈接：https://engineering.fb.com/2021/07/22/data-infrastructure/mysql/