[[419285]]

圖片來自 包圖網(wǎng)

在升級到 5.7 的同時構建一個新的存儲引擎，會大大減慢 MyRocks 的進度，因此我們選擇繼續(xù)使用 5.6，直到 MyRocks 完成，MySQL 5.6 的壽命也即將結束，決定升級到 MySQL 8.0 。

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

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

為了遷移工作負載，對于每個新的 MySQL 主版本，我們都需要投入大量的時間和精力。

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

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

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

在升級到 5.7 的同時構建一個新的存儲引擎，會大大減慢 MyRocks 的進度，因此我們選擇繼續(xù)使用 5.6，直到 MyRocks 完成。

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

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

對我們來說，遷移到 8.0 還將帶來包括文檔存儲在內(nèi)的，我們已經(jīng)錯過的 5.7 特性。

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

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

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

當最初確定項目范圍時，可以明確的是，遷移到 8.0 會比遷移到 5.6 或 MyRocks 更困難：

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

代碼補丁

首先我們建立了 8.0 分支，用于在開發(fā)環(huán)境中進行構建和測試。然后，我們開始從 5.6 分支移植補丁的漫長過程。開始的時候有 1700 多個補丁，但我們能將其組織成幾個主要類別。

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

通過特殊關鍵字或唯一變量名所啟用的功能，也使得確定關聯(lián)變得很容易，因為我們可以搜索應用程序代碼庫來找到它們的用例。

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

我們將每個補丁分入四類之一：

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

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

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

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

客戶端和服務器類別中的每個補丁都自然而然地成為一個軟件發(fā)布里程碑。隨著所有與客戶端相關的更改的移植，我們能夠將客戶端工具和連接器代碼更新到 8.0。

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

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

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

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

遷移途徑

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

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

由 5.6 主/ 5.6 從所組成的副本集開始，最終目標是包含 8.0 主/ 8.0 從的副本集。

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

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

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

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

為了自動化遷移大量副本集，我們需要構建新的軟件架構?？梢酝ㄟ^簡單地更改配置文件中的一行，將副本集組合并在每個階段中移動它們。任何遇到問題的副本集都能單獨回滾。

基于行的復制

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

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

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

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

使用 RBR 還為我們提供了一個解決應用程序問題的替代解決方案，我們在將一些副本集移動到 8.0 主實例時遇到了這個問題，將在后面討論。

自動化驗證

大多數(shù) 8.0 遷移過程都涉及使用我們的自動化架構和應用查詢來測試和驗證 mysqld 服務器。

我們用來管理服務器的自動化基礎架構在隨著 MySQL 服務器的增長而增長。為了確保所有 MySQL 自動化組件都與 8.0 版本兼容，我們投資構建了一個測試環(huán)境，該環(huán)境利用虛擬機上的測試副本集來驗證行為。

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

當 MySQL 架構的每一部分都在我們的 8.0 服務器上進行驗證時，我們發(fā)現(xiàn)并修復了(或解決了)一些有趣的問題：

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

8.0 的默認 utf8mb4 排序規(guī)則設置導致 5.6 和 8.0 實例之間的排序規(guī)則不匹配。

8.0 表可能會使用新的 utf8mb4_0900 排序規(guī)則，即使對于由 5.6 的show create table生成的create語句也是如此，因為使用utf8mb4_general_ci 的 5.6 模式?jīng)]有顯式指定排序規(guī)則。

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

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

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

應用程序驗證

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

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

對于每個應用程序工作負載，我們在 8.0 上創(chuàng)建了測試實例，并向它們回放影子流量的查詢。

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

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

8.0 引入了新的保留關鍵字，其中一些關鍵字，如 groups 和 rank，與應用程序查詢中常用的表列名或別名相沖突。這些查詢沒有通過反引號轉義名稱，導致解析錯誤。

使用了自動轉義查詢中列名的軟件庫的應用程序沒有遇到這些問題，但并非所有應用程序都使用這些軟件庫。

解決這個問題很簡單，但是需要時間來跟蹤生成這些查詢的應用程序屬主和代碼庫。

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

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

5.6 有一個 bug，在 8.0 中得到了修復，但是修復增加了事務死鎖的可能性。

在分析了查詢之后，我們能夠通過降低隔離級別來解決該問題。這個選項對我們來說是可用的，因為我們已經(jīng)切換到基于行的復制。

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

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

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

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

內(nèi)存使用量與 5.6 相比有所增加，特別是對于 MyRocks 實例，因為必須加載 8.0 中的 InnoDB 。

默認的 performance_schema 設置啟用了所有工具集并消耗了大量內(nèi)存。我們限制了內(nèi)存使用，只啟用了少量的工具，并對代碼進行了更改，以禁用無法手動關閉的表。

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

接下來的工作

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

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

跳過 5.7 這樣的主版本會帶來一些問題，我們的遷移需要解決這些問題。

首先，我們無法就地升級服務器，需要使用邏輯轉儲和還原來構建新服務器。

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

其次，檢測 API 更改要困難得多，因為 5.7 可能會向我們的應用程序客戶端發(fā)出不推薦警告，以提示修復潛在的問題。

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

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

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

盡管我們在遷移過程中遇到了種種障礙，但我們已經(jīng)看到了運行 8.0 帶來的好處。

一些應用程序選擇了提早遷移到 8.0，以利用諸如文檔存儲和改進的日期時間支持等功能。

我們一直在考慮如何在 MyRocks 上支持像即時 DDL 這樣的存儲引擎特性。總的來說，新版本大大擴展了 MySQL@Facebook 的功能。

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

編輯：陶家龍

出處：轉載自公眾號CSDN(ID：CSDNnews)

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