Facebook 在一篇博客中分享了該公司在某種程度上艱難的大規(guī)?？缭绞竭w移到 MySQL 8.0 版本的經(jīng)驗。此前，其一直使用的是 MySQL 5.6 版本。

MySQL 是由 Oracle 開發(fā)的開源數(shù)據(jù)庫，為 Facebook 的一些最重要的工作負載提供支持。Facebook 方面稱，MySQL 的每個新主要版本都需要其花費大量時間和精力來遷移工作負載。其中挑戰(zhàn)包括有：

• 將其自定義功能移植到新版本
• 確保復(fù)制在主要版本之間兼容
• 最小化現(xiàn)有應(yīng)用程序查詢所需的更改
• 修復(fù)阻止服務(wù)器支持其工作負載的性能回歸

[[413144]]

根據(jù)透露，F(xiàn)acebook 上次升級到 MySQL 5.6 花了一年多的時間;而此向 MySQL 8.0 的升級也花了好幾年的時間。在 5.7 版本發(fā)布的時候，F(xiàn)acebook 仍在開發(fā) 5.6 版上的 LSM-Tree 存儲引擎 MyRocks。鑒于在構(gòu)建新存儲引擎的同時升級到 5.7 會顯著減緩 MyRocks 的進度，因此該團隊選擇繼續(xù)使用 5.6 直到 MyRocks 完成。而 MySQL 8.0 則剛好是在 MyRocks 完成時發(fā)布的，所以 Facebook 選擇升級以改進其存儲引擎。

Facebook 指出，遷移到 8.0 明顯比遷移到 5.6 要更困難。他們有 1700 個代碼補丁要從其定制的 MySQL 5.6 分支遷移到 8.0。由于 Facebook 的 MySQL 新功能和不斷添加到 5.6 代碼庫中的修復(fù)，使得這項工作變得非常復(fù)雜。

因為從 5.6 到 8.0 的升級完全跳過了 5.7，一些在 5.6 中活躍的 API 要么被棄用、要么被完全刪除;這也就意味著任何使用舊 API 的應(yīng)用程序都需要更新。且 Facebook 的一些功能也與 8.0 中的類似功能不向前兼容，需要棄用和向前遷移。

還有自定義代碼文檔參差不齊的問題。Facebook 稱，它的大多數(shù)自定義代碼都有良好的注釋和文檔。但其他的代碼沒有很好的文檔，F(xiàn)acebook 需要挖掘舊的文件、帖子和代碼注釋來了解歷史。

最終，F(xiàn)acebook 方面評估了 2300 多個補丁并將其中的 1500 個移植到了 MySQL 8.0。“我們已將許多 InnoDB 副本集轉(zhuǎn)換為完全在 8.0 上運行。其余的大多數(shù)都處于遷移路徑的不同階段?，F(xiàn)在我們的大部分自定義功能都已移植到 8.0，更新到 Oracle 的次要版本相對容易，我們計劃跟上最新版本的步伐。”

“盡管我們在遷移的道路上遇到了種種障礙，但我們已經(jīng)看到了運行8.0的好處?？偟膩碚f，新版本大大擴展了我們在 MySQL @ Facebook 上所能做的事情。”

更多詳情可查看官方博客。

本站新聞禁止未經(jīng)授權(quán)轉(zhuǎn)載，違者依法追究相關(guān)法律責任。授權(quán)請聯(lián)系：oscbianji#oschina.cn

本文標題：Facebook 分享遷移到 MySQL 8.0 的經(jīng)驗

本文地址：https://www.oschina.net/news/151964/facebook-mysql-8-0-migration