為何全世界都不更新資料庫？“EOL又咋滴，不壞絕不換掉！”

前言：去年十月，“MySQL5.7停服”一度成為資料庫行業的熱門話題。在選擇更新MySQL8.0還是遷移到其他資料庫的激烈讨論聲中，“不更新”的選項也有不少人站隊，保持原樣、不動就不會出事似乎也是求穩的優選之一。

大家為什麼不更新資料庫？更新資料庫的利弊如何衡量？是否有安全更新資料庫的政策？讓我們一起在文中尋找答案。

資料庫是應用程式和軟體的基礎。它們有時也不太可見；正如軟體的通用語言所說，它們是後端，這意味着它們位于其他所有内容之後或之下。

由此，更新資料庫時很容易落入思維陷阱：要麼忘記資料庫的存在，要麼擔心自己弄亂不該碰的東西而感到強烈焦慮。

這一觀點由David Stokes 提出，他是開源資料庫軟體支援和服務公司 Percona的技術布道者。他在網站The New Stack的采訪中說道：“有部分原因是，如果資料庫正在運作，且團隊成員不确定它的實際功能或工作原理，就不希望變更它。”

以此類推，Stokes 補充說：“誰會将某個東西從生産中取出以對其進行更新？如果它沒有按時恢複，會産生什麼後果？”

他描述了（技術人員）一種非常典型的态度：“軟體正在運作……為什麼要碰它？等到它壞了再說。”

在某些版本的開源資料庫的生命周期結束 （EOL） 的情況下，更新資料庫的問題尤其重要。

例如，在 2023 年，MySQL 5.7走到了生命盡頭，作為MySQL中非常流行的版本，它自2015年釋出以來，已存在了将近十年。同樣結束生命周期的資料庫軟體還包括PostgreSQL 11、Apache Cassandra 3 和 MongoDB 6.3 。當然，當一款軟體“退役”（此處需要一個更恰當的術語）時，供應商或社群已決定投入精力推出新版本——MongoDB 7.0于 2023 年 8 月釋出，PostgreSQL 16于 2023 年 9 月釋出，Apache Cassandra 5于 2023 年 11 月釋出。

生命周期結束（EOL）後，斷崖式下跌的軟體性能

對于許多團隊來說，EOL 代表着軟體性能斷崖式下跌，該軟體不再被修補和更新，導緻安全性問題以及潛在的性能問題風險更大。

毫無疑問，文檔不被繼續維護，任何支援（如果一開始提供支援的話）都将完全消失。在某些情況下，這可能是一個合規性問題——例如，在支付領域，獲得 PCI-DSS 認證的組織——那些需要遵守支付卡行業資料安全标準的組織——必須在釋出後最多一個月内部署任何關鍵更新檔。

Percona 的進階産品經理 Jan Wieremjewicz 回憶了 Log4J 安全漏洞：“想象一下，運作在生命周期結束的軟體上，該軟體因沒有持續修補以排除潛在的零日漏洞（zero-day vulnerability，又稱零時差漏洞，指軟體供應商和公衆未知的漏洞，容易被惡意攻擊）。”他在接受The New Stack的采訪時提到，“每當想到這一點，我都會起雞皮疙瘩！”

不更新資料庫的風險很大。從本質上講，資料庫原本應該是更廣泛系統的堅實基礎，現在卻反而變成了一種負擔， 一顆随時可能破壞看似功能穩定的系統的定時炸彈。

但同樣值得注意的是，新版本的釋出——尤其是主要版本——可以為工程團隊帶來機遇。考慮到新功能和改進的體驗是任何軟體推出時的慣例，雖然其中一些功能可以被視為營銷炒作，但重要的是要認識到，不更新可能意味着你錯失了更佳做法。

為什麼不更新？

鑒于這些重大風險，我們值得深入研究某些組織所特有的回避感（如果這不是恐懼感的話）。Wieremjewicz 着重強調（回避更新資料庫）的原因之一是軟體工程團隊的構成發生變化。

他認為，資料庫架構師“是一個瀕臨滅絕的物種”——他們正被站點可靠性工程師（SRE）擠出。“DBA 越來越少，SRE 越來越多，而SRE通常不像 DBA 那樣精通資料庫問題。”

Wieremjewicz也同時提到，一定程度上，這也是基于雲的資料庫即服務（DBaaS）興起所産生的影響。一方面，資料庫即服務 （DBaaS） 簡化了資料庫配置和管理的許多操作。但另一方面，它也讓複雜性蔓延到其他地方，而技能群組織結構的發展不一定能夠處理這種複雜性。

“我們擁有的資料庫已經從幾年前的少數幾個，增加至數千甚至更多。”Stokes說。“你仍然需要有人來檢查查詢并進行基本的“衛生”工作（原文為hygiene work，比喻資料庫基礎管理工作），確定帳戶正确、密碼正确、軟體版本最新、複制正常、資料正常備份。”

這種複雜性與資料庫更新問題無關，它突出了問題的核心。在資料庫被視為輕量級建構塊而非笨重、似乎無法移動的錨的時代，即使我們被提醒“資料庫是需要持續關注和維護的複雜事物”，我們也還是假裝這個問題無法被觸及，或者這是明天（尚未來臨）的難題。

缺乏吸引力？

有人可能會認為，更新資料庫根本沒有與其他項目相當的吸引力（或者更具體地說，沒有明顯的商業價值）。用Stokes的話來說，更新資料庫在很大程度上是“衛生工作”。

他換了一種表達方式解釋：“一位進階副總裁進來說，‘嘿，我有一個關于我們即将要做的新事物的絕妙想法。這是我的心血項目。我想讓你負責。’你說‘好的，但管理庫存流程的舊系統需要一些更新。’‘是的，但這是我的心血項目，我真的很需要（把這項目的優先級放在更新系統之前）。’”

Stokes認為，這種狀況隻有一條路可走——而且不利于更新。

“資料庫更新總是很棘手，”Stokes說，“因為即使在最好的情況（比如進行一些細微的改變下，也需要大量閱讀發行說明，并進行一兩次測試，以確定一切正常。”

開源資料庫的獨特挑戰

開源資料庫在更新方面尤其具有挑戰性。你幾乎隻能靠自己，可能依賴于貢獻社群來擷取相關文檔甚至技術支援。

在此情況，開源資料庫可以為工程團隊提供的靈活性反而成為負擔。團隊由于無法輕松管理開源資料庫而受到阻礙——即使是最活躍的開源項目在為團隊提供具體實施方面的支援時，能做的事也相當有限。

這就是開源資料庫軟體管理和支援服務發揮作用的重要場景。由于多種原因，這種平台或工具的不可知論（不可知論意為，除感覺或現象以外，事物的本質或本體及其他東西都無法知道）可能是有利的。

Wieremjewicz 表示：“我們能夠就解決方案提供建議——甚至可以非常真實、誠實地從一個資料庫遷移到另一個資料庫，因為我們不會通過推廣自建軟體來賺錢。”同時，“這完全是為了使用者的利益。”

在更新資料庫的特定情況下，供應商不可知論會讓組織在解決資料庫問題時更加開放甚至有創造力。當然，從 MongoDB 更新到 MongoDB 可能有意義，但如果探索一個新資料庫與你的特定技術環境更相關呢？

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

更新的關鍵：預測和準備

不可否認，更新資料庫可能具有挑戰性，至關重要的是規劃并保持領先一步。

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

如果未能這樣做，可能會産生重大的技術問題（甚至是商業問題），這些問題在以後更難糾正。

Stokes 認為沒有一種絕對正确的方法來更新資料庫，如何實施（更新方案）最終取決于實際執行操作的組織所具備的成熟度和信心。

Stokes 說：“這就和我們學習騎自行車一樣，有些人跳上車并自己完成，另一些人則需要有人幫助在轉向時穩定座椅，而你則需要學習如何上下踩踏闆。”

他确信，隻要有人需要了解資料庫，資料庫管理和支援服務就依然保有價值：“我們已經存在足夠長的時間，知道如何繞過坑窪，避免上坡。”

作者丨Richard Gall 編譯丨onehunnit

來源丨thenewstack.io/why-isnt-the-world-upgrading-its-databases/

*本文為dbaplus社群編譯整理，如需轉載請取得授權并标明出處！歡迎廣大技術人員投稿，投稿郵箱：[email protected]

活動推薦

2024 XCOPS智能運維管理人年會·廣州站将于5月24日舉辦，深究大模型、AI Agent等新興技術如何落地于運維領域，賦能企業智能運維水準提升，建構全面運維自治能力！

會議詳情：2024 XCOPS智能運維管理人年會-廣州站