如果您的開源數(shù)據(jù)庫現(xiàn)在運行良好，為什么還要動它？因為生命周期結束的軟件更難維護，而且您可能會錯過有價值的新功能。

譯自Why Isn’t the World Upgrading Its Databases?，作者 Richard Gall。

數(shù)據(jù)庫是應用程序和軟件的基礎。它們也有些隱形；正如軟件的通用語言所說，它們是后端，這意味著它們位于其他所有內容的后面或下面。

這意味著在升級時，很容易陷入兩個陷阱之一：要么忘記它們的存在，要么強烈擔心自己正在擺弄不應該碰的東西。

這是David Stokes提出的觀點，他是Percona的技術布道者，Percona 是一家為開源數(shù)據(jù)庫提供支持和服務的組織。

他告訴 The New Stack：“部分原因是，如果它在運行，并且 [團隊] 不確定數(shù)據(jù)庫的實際作用或工作原理，他們就不想碰它。”

他補充說：“同樣，誰會將某個東西從生產中取出以對其進行升級？如果它沒有按時恢復，會產生什么后果？”

他建議，這種態(tài)度通常是：“它現(xiàn)在正在運行……為什么要碰它？等到它壞了再說。”

在某些版本的開源數(shù)據(jù)庫達到其生命周期結束 (EOL) 的情況下，升級數(shù)據(jù)庫的問題尤其重要。

例如，在 2023 年，MySQL 5.7走到了盡頭，這是一個非常流行的版本，已經存在了將近十年（它早在 2015 年就發(fā)布了)，PostgreSQL 11、Apache Cassandra 3 和 MongoDB 6.3 也是如此。當然，當一款軟件“退休”（因為找不到更好的術語）時，通常會有新版本，供應商或社區(qū)已決定投入精力——MongoDB 7.0于 2023 年 8 月發(fā)布，PostgreSQL 16于 2023 年 9 月發(fā)布，Apache Cassandra 5于 2023 年 11 月發(fā)布。

生命周期結束的懸崖邊緣

對于許多團隊來說，EOL 代表著懸崖邊緣。這意味著該軟件將不再被修補和更新，從而導致安全性問題以及潛在的性能問題風險更大。

當然，文檔不會得到維護，并且任何支持（如果一開始有任何支持）都將完全消失。在某些情況下，這可能是一個合規(guī)性問題——例如，在支付領域，獲得 PCI-DSS 認證的組織——那些需要遵守支付卡行業(yè)數(shù)據(jù)安全標準的組織——必須在發(fā)布后最多一個月內部署任何關鍵補丁。

Percona 的高級產品經理Jan Wieremjewicz回憶了Log4J 安全漏洞。“想象一下運行在生命周期結束的軟件上，該軟件沒有得到修補以排除潛在的零日漏洞，”他告訴 The New Stack。“每當我想到這一點，我都會起雞皮疙瘩！”

不升級數(shù)據(jù)庫的風險很大。從本質上講，原本應該是更廣泛系統(tǒng)的穩(wěn)固基礎的東西變成了一個累贅，一個隨時可能破壞看似功能穩(wěn)定的一切的定時炸彈。

但同樣值得注意的是，新版本（尤其是主要版本）的發(fā)布可以為工程團隊帶來機遇。考慮任何軟件在發(fā)布時通常具有的新功能和改進的體驗。雖然其中一些可以被視為營銷炒作，但重要的是要認識到，不升級可能意味著你錯失了更好的做事方式。

為什么不升級？

鑒于這些重大風險，值得深入研究某些組織所特有的回避感（如果不是恐懼的話）。Wieremjewicz 強調的一個原因是軟件工程團隊的構成發(fā)生了變化。

他說，數(shù)據(jù)庫架構師“是一個瀕臨滅絕的物種”——他們正被網站可靠性工程師擠出。“DBA 越來越少，SRE 越來越多，他們通常不像 DBA 那樣精通數(shù)據(jù)庫問題。”

他認為，這在一定程度上是因為基于云的數(shù)據(jù)庫即服務 (DBaaS)。一方面，數(shù)據(jù)庫即服務 (DBaaS) 簡化了數(shù)據(jù)庫配置和管理的許多方面。另一方面，它也讓復雜性蔓延到其他地方，而技能和組織結構卻以無法應對這種復雜性的方式演變。

“我們從幾年前可能只有少數(shù)幾個數(shù)據(jù)庫變成了數(shù)千個，甚至更多。”斯托克斯說。“你仍然需要有人來檢查查詢并進行基本的衛(wèi)生工作，確保帳戶正確、密碼正確、軟件是最新的、復制正常、數(shù)據(jù)正在備份。”

這與數(shù)據(jù)庫升級問題無關：它突出了問題的核心。在數(shù)據(jù)庫被視為輕量級構建塊而不是笨重、看似不可移動的錨點的時代，就在我們被提醒數(shù)據(jù)庫是需要持續(xù)關注和維護的復雜事物時，我們想要假裝它們根本不能被觸及，或者它們是明天的難題。

缺乏吸引力？

有人可能會認為，升級數(shù)據(jù)庫根本沒有其他項目所具有的吸引力（或者更具體地說，沒有明顯的商業(yè)價值）。用斯托克斯的話來說，這在很大程度上是“衛(wèi)生工作”。

他用另一種方式解釋道：“一位高級副總裁進來，說，‘嘿，我有一個關于我們即將要做的新事物的絕妙想法。這是我的心血項目。我想讓你負責。’你說‘好的，但管理庫存流程的舊系統(tǒng)需要一些升級。’‘是的，但這是我的心血項目，我真的很需要它。’”

斯托克斯認為，這只會有一種結果——而且不利于升級。

“數(shù)據(jù)庫升級總是很棘手，”他說，“因為即使在最好的情況下，它們也只是一些細微的改變。這需要大量閱讀發(fā)行說明，并希望進行一兩次測試，以確保一切正常。”

開源數(shù)據(jù)庫的獨特挑戰(zhàn)

在升級方面，開源數(shù)據(jù)庫特別具有挑戰(zhàn)性。你幾乎只能靠自己，可能依賴于貢獻社區(qū)來獲取相關文檔甚至支持。

在這些情況下，開源數(shù)據(jù)庫可以為工程團隊提供的靈活性變成了負擔。團隊受到一些他們無法輕松管理的事情的阻礙——即使是最活躍的開源項目在為團隊提供特定實現(xiàn)方面的支持時也只能做這么多。

這就是 Percona 發(fā)揮作用的地方。它始于一段時間前，Wieremjewicz 講述了創(chuàng)始人Peter Zaitsev在 MySQL 擔任開發(fā)人員后離開 MySQL 的故事，他的目標是為用戶提供更大的支持。

盡管 MySQL 是該公司起源故事的基本組成部分，但其范圍更廣泛地涵蓋了開源數(shù)據(jù)庫。該團隊很可能為使用 PostgreSQL 或 MongoDB 的公司提供支持，就像為 MySQL 提供支持一樣。

這種平臺或工具不可知論是有利的，原因有很多。

Wieremjewicz 說：“我們能夠就解決方案提供建議——甚至可以非常真實和誠實地從一個數(shù)據(jù)庫遷移到另一個數(shù)據(jù)庫，因為我們不會通過推廣我們創(chuàng)建的一些軟件來賺錢。”“這完全是為了用戶的利益。”

在升級數(shù)據(jù)庫的特定情況下，供應商不可知論可能允許組織在解決數(shù)據(jù)庫問題時更加開放甚至有創(chuàng)造力。當然，從 MongoDB 升級到 MongoDB 可能有意義，但如果探索一個新數(shù)據(jù)庫與你的特定技術環(huán)境更相關呢？

即使擁有最博學多才和最開放的團隊，也很難自己做出這些決定——外部的、不可知的建議在提供必要的支持和變革動力方面可能非常有價值。

升級的關鍵：預測和準備

不可否認，升級數(shù)據(jù)庫可能具有挑戰(zhàn)性。至關重要的是規(guī)劃并保持領先一步。

Wieremjewicz 說：“你必須提前計劃，不能等到生命結束才采取行動，你應該更早地預測。”

未能這樣做可能會產生重大的技術問題——甚至商業(yè)問題——這些問題在以后更難糾正。

Stokes 不認為有一種正確的方法來升級數(shù)據(jù)庫。它的方法最終取決于實際執(zhí)行它的組織的成熟度和信心。

他說：“這是我們正在學習騎自行車的事情之一。”“有些人跳上去自己做——其他人需要有人在學習如何上下踩踏板和如何轉向時安撫并穩(wěn)定座椅。”他確信，只要有人需要了解數(shù)據(jù)庫，Percona 就會對這些客戶保持價值：“我們已經存在足夠長的時間，知道如何繞過坑洼，避免上坡。”