摘要：如果现有的开源数据库运行良好，为何要动它？这可能是很多技术团队的常见心态，但是一旦版本到达生命周期的终点，其维护难度将增加，同时还可能错失令人心动的新功能。

　　数据库是所有应用程序和软件的核心。它们通常不为人所见，用软件行业的术语来说，数据库属于“后端”，即它们是支撑所有其他功能的底层架构。

　　因此，在考虑升级时，人们往往会陷入两种极端：要么忽视了数据库的存在，要么因担心影响稳定性而不敢轻易动它。

　　这是Percona技术布道者David Stokes提出的观点。他分享到：“很多时候，如果数据库工作正常，且团队对其内部机制和工作原理了解不深，他们往往选择不去动它。毕竟，谁愿意轻易动正在生产中的东西呢？万一出了问题，后果谁来承担？”

　　因此，很多团队常见的心态是：“既然现在运行正常，何必去碰它？等出了问题再说。”然而，在开源数据库版本陆续走向生命周期尽头（EOL）的背景下，升级问题变得尤为紧迫。

　　例如，在2023年，MySQL 5.7、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安全漏洞时仍心有余悸：“想象一下，如果运行着的是生命周期结束的软件，没有补丁来排除潜在的零日漏洞，那后果简直不堪设想！”

　　不升级数据库的风险无疑是巨大的。原本应作为系统坚实基础的数据库，如今却成了潜在的定时炸弹，随时可能给看似稳定的系统带来致命一击。

　　但同样值得注意的是，新版本的发布，尤其是重大更新，为工程团队带来了机遇。新软件发布时通常会带来新特性和更好的体验。虽然有些可能只是营销手段，但不可否认的是，不升级可能意味着错过了更高效的做事方式。

　　为何不升级？

　　那么，为什么有些企业还是选择回避升级呢？Wieremjewicz认为，这与软件工程团队的构成变化有关。

　　他说：“数据库管理员（DBA）这一角色正逐渐消失——取而代之的是网站可靠性工程师（SRE）。但SRE通常并不像DBA那样擅长处理数据库问题。”

　　这在一定程度上是数据库即服务（DBaaS）兴起的产物。虽然它简化了数据库配置和管理的许多方面，但也让复杂性在其他地方滋生。同时，技能和组织结构的发展速度并未跟上这种复杂性的增长。

　　Stokes说：“几年前，我们可能只有少数几个数据库，但现在我们可能有成千上万个。你仍然需要有人去检查查询，进行基本的维护工作，确保账户设置正确，密码安全，软件保持最新，数据复制和备份正常运行。”

　　这与数据库升级的问题密切相关：它凸显了问题的核心。在很多情况下，人们倾向于将数据库看作是简单易用的轻量级工具，就像乐高积木一样，可以轻松地组合和移动。然而，实际上数据库是复杂系统，它们需要不断的关注和维护，以确保其正常运行和安全性。

　　尽管数据库的复杂性和它们在维护上的需求是显而易见的，但人们往往因为害怕破坏现有的稳定状态而不愿去轻易动他们，或者将升级工作推迟到将来，认为目前它们还不需要紧急处理。这种态度可能会导致数据库的安全隐患和性能问题，因为忽视了对数据库进行适时升级和维护的重要性。

　　缺乏吸引力？

　　或许，升级数据库看起来没有其他项目那么吸引人（或具有明显的商业价值）。这非常像是“维护工作”，用Stokes的话来说。

　　他用另一种方式解释：“假设有一位高级副总裁带着一个新想法来找你时，你很难说服他先去处理那些旧系统的升级问题。毕竟，他的新想法才是当下的重点。”

　　Stokes认为，这种情况通常只有一个结果——而且那不是支持升级。

　　“数据库升级总是充满挑战，”他说，“因为它们通常涉及微妙的变化。这需要仔细阅读发布说明，并进行测试，以确保一切正常。”

　　开源数据库的独特挑战

　　开源数据库在升级时面临诸多独特挑战。在大多数情况下，你几乎要孤军奋战，可能只能依赖贡献社区来获取相关文档甚至支持。

　　在这些情况下，开源数据库能够为工程团队提供的灵活性反而成了负担。团队在无法轻易管理某些事情时就会受阻——即使是最活跃的开源项目，也只能在支持团队的具体实施方面做这么多。

　　在升级数据库的特定背景下，供应商无关性可能让企业在解决数据库问题时更加开放，甚至更具创造性。

　　即使拥有深厚知识储备和开放的团队，独自做出这些决定也是非常困难的——外部的、中立的建议在提供必要的支持和推动变革方面可能非常有价值。

　　升级的关键：提前预判和准备

　　升级数据库无疑是一项具有挑战性的任务。关键在于做好规划，并始终保持领先一步。

　　“你必须提前规划，不能等到生命周期结束才行动，你应该早点做好预判。”Wieremjewicz说。

　　未能做到这一点可能会导致严重的技术问题——甚至可能是商业问题，这些问题在后续阶段会变得更加难以纠正。

　　Stokes认为，升级数据库没有一种绝对正确的方法。如何操作最终将取决于实际执行此操作的组织的成熟度和信心。

　　“这就像学习骑自行车一样，”他说，“有些人跳上去就能自己骑——而有些人则需要有人帮你稳住座位，同时学习如何上下踩动双腿和如何掌控方向。”