這個世界為什么不升級數據庫?你知道嗎?
如果您的開源數據庫現在運行良好,為什么還要動它?因為生命周期結束的軟件更難維護,而且您可能會錯過有價值的新功能。
譯自Why Isn’t the World Upgrading Its Databases?,作者 Richard Gall。
數據庫是應用程序和軟件的基礎。它們也有些隱形;正如軟件的通用語言所說,它們是后端,這意味著它們位于其他所有內容的后面或下面。
這意味著在升級時,很容易陷入兩個陷阱之一:要么忘記它們的存在,要么強烈擔心自己正在擺弄不應該碰的東西。
這是David Stokes提出的觀點,他是Percona的技術布道者,Percona 是一家為開源數據庫提供支持和服務的組織。
他告訴 The New Stack:“部分原因是,如果它在運行,并且 [團隊] 不確定數據庫的實際作用或工作原理,他們就不想碰它。”
他補充說:“同樣,誰會將某個東西從生產中取出以對其進行升級?如果它沒有按時恢復,會產生什么后果?”
他建議,這種態度通常是:“它現在正在運行……為什么要碰它?等到它壞了再說。”
在某些版本的開源數據庫達到其生命周期結束 (EOL) 的情況下,升級數據庫的問題尤其重要。
例如,在 2023 年,MySQL 5.7走到了盡頭,這是一個非常流行的版本,已經存在了將近十年(它早在 2015 年就發布了),PostgreSQL 11、Apache Cassandra 3 和 MongoDB 6.3 也是如此。當然,當一款軟件“退休”(因為找不到更好的術語)時,通常會有新版本,供應商或社區已決定投入精力——MongoDB 7.0于 2023 年 8 月發布,PostgreSQL 16于 2023 年 9 月發布,Apache Cassandra 5于 2023 年 11 月發布。
生命周期結束的懸崖邊緣
對于許多團隊來說,EOL 代表著懸崖邊緣。這意味著該軟件將不再被修補和更新,從而導致安全性問題以及潛在的性能問題風險更大。
當然,文檔不會得到維護,并且任何支持(如果一開始有任何支持)都將完全消失。在某些情況下,這可能是一個合規性問題——例如,在支付領域,獲得 PCI-DSS 認證的組織——那些需要遵守支付卡行業數據安全標準的組織——必須在發布后最多一個月內部署任何關鍵補丁。
Percona 的高級產品經理Jan Wieremjewicz回憶了Log4J 安全漏洞。“想象一下運行在生命周期結束的軟件上,該軟件沒有得到修補以排除潛在的零日漏洞,”他告訴 The New Stack。“每當我想到這一點,我都會起雞皮疙瘩!”
不升級數據庫的風險很大。從本質上講,原本應該是更廣泛系統的穩固基礎的東西變成了一個累贅,一個隨時可能破壞看似功能穩定的一切的定時炸彈。
但同樣值得注意的是,新版本(尤其是主要版本)的發布可以為工程團隊帶來機遇。考慮任何軟件在發布時通常具有的新功能和改進的體驗。雖然其中一些可以被視為營銷炒作,但重要的是要認識到,不升級可能意味著你錯失了更好的做事方式。
為什么不升級?
鑒于這些重大風險,值得深入研究某些組織所特有的回避感(如果不是恐懼的話)。Wieremjewicz 強調的一個原因是軟件工程團隊的構成發生了變化。
他說,數據庫架構師“是一個瀕臨滅絕的物種”——他們正被網站可靠性工程師擠出。“DBA 越來越少,SRE 越來越多,他們通常不像 DBA 那樣精通數據庫問題。”
他認為,這在一定程度上是因為基于云的數據庫即服務 (DBaaS)。一方面,數據庫即服務 (DBaaS) 簡化了數據庫配置和管理的許多方面。另一方面,它也讓復雜性蔓延到其他地方,而技能和組織結構卻以無法應對這種復雜性的方式演變。
“我們從幾年前可能只有少數幾個數據庫變成了數千個,甚至更多。”斯托克斯說。“你仍然需要有人來檢查查詢并進行基本的衛生工作,確保帳戶正確、密碼正確、軟件是最新的、復制正常、數據正在備份。”
這與數據庫升級問題無關:它突出了問題的核心。在數據庫被視為輕量級構建塊而不是笨重、看似不可移動的錨點的時代,就在我們被提醒數據庫是需要持續關注和維護的復雜事物時,我們想要假裝它們根本不能被觸及,或者它們是明天的難題。
缺乏吸引力?
有人可能會認為,升級數據庫根本沒有其他項目所具有的吸引力(或者更具體地說,沒有明顯的商業價值)。用斯托克斯的話來說,這在很大程度上是“衛生工作”。
他用另一種方式解釋道:“一位高級副總裁進來,說,‘嘿,我有一個關于我們即將要做的新事物的絕妙想法。這是我的心血項目。我想讓你負責。’你說‘好的,但管理庫存流程的舊系統需要一些升級。’‘是的,但這是我的心血項目,我真的很需要它。’”
斯托克斯認為,這只會有一種結果——而且不利于升級。
“數據庫升級總是很棘手,”他說,“因為即使在最好的情況下,它們也只是一些細微的改變。這需要大量閱讀發行說明,并希望進行一兩次測試,以確保一切正常。”
開源數據庫的獨特挑戰
在升級方面,開源數據庫特別具有挑戰性。你幾乎只能靠自己,可能依賴于貢獻社區來獲取相關文檔甚至支持。
在這些情況下,開源數據庫可以為工程團隊提供的靈活性變成了負擔。團隊受到一些他們無法輕松管理的事情的阻礙——即使是最活躍的開源項目在為團隊提供特定實現方面的支持時也只能做這么多。
這就是 Percona 發揮作用的地方。它始于一段時間前,Wieremjewicz 講述了創始人Peter Zaitsev在 MySQL 擔任開發人員后離開 MySQL 的故事,他的目標是為用戶提供更大的支持。
盡管 MySQL 是該公司起源故事的基本組成部分,但其范圍更廣泛地涵蓋了開源數據庫。該團隊很可能為使用 PostgreSQL 或 MongoDB 的公司提供支持,就像為 MySQL 提供支持一樣。
這種平臺或工具不可知論是有利的,原因有很多。
Wieremjewicz 說:“我們能夠就解決方案提供建議——甚至可以非常真實和誠實地從一個數據庫遷移到另一個數據庫,因為我們不會通過推廣我們創建的一些軟件來賺錢。”“這完全是為了用戶的利益。”
在升級數據庫的特定情況下,供應商不可知論可能允許組織在解決數據庫問題時更加開放甚至有創造力。當然,從 MongoDB 升級到 MongoDB 可能有意義,但如果探索一個新數據庫與你的特定技術環境更相關呢?
即使擁有最博學多才和最開放的團隊,也很難自己做出這些決定——外部的、不可知的建議在提供必要的支持和變革動力方面可能非常有價值。
升級的關鍵:預測和準備
不可否認,升級數據庫可能具有挑戰性。至關重要的是規劃并保持領先一步。
Wieremjewicz 說:“你必須提前計劃,不能等到生命結束才采取行動,你應該更早地預測。”
未能這樣做可能會產生重大的技術問題——甚至商業問題——這些問題在以后更難糾正。
Stokes 不認為有一種正確的方法來升級數據庫。它的方法最終取決于實際執行它的組織的成熟度和信心。
他說:“這是我們正在學習騎自行車的事情之一。”“有些人跳上去自己做——其他人需要有人在學習如何上下踩踏板和如何轉向時安撫并穩定座椅。”他確信,只要有人需要了解數據庫,Percona 就會對這些客戶保持價值:“我們已經存在足夠長的時間,知道如何繞過坑洼,避免上坡。”