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

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

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

[[413144]]

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

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

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

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

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

“盡管我們?cè)谶w移的道路上遇到了種種障礙，但我們已經(jīng)看到了運(yùn)行8.0的好處?？偟膩?lái)說(shuō)，新版本大大擴(kuò)展了我們?cè)?MySQL @ Facebook 上所能做的事情。”

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

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

本文標(biāo)題：Facebook 分享遷移到 MySQL 8.0 的經(jīng)驗(yàn)

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