前言：
去年十月，「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等新興技術如何落地於運維領域，賦能企業智慧運維水平提升，構建全面運維自治能力！ 碼上報名，享早鳥優惠。
