数据库是应用程序和软件的基础。它们有时也不太可见；正如软件的通用语言所说，它们是后端，这意味着它们位于其他所有内容之后或之下。

由此，升级数据库时很容易落入思维陷阱：要么忘记数据库的存在，要么担心自己弄乱不该碰的东西而感到强烈焦虑。

这一观点由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 代表着软件性能断崖式下跌，该软件不再被修补和更新，导致安全性问题以及潜在的性能问题风险更大。

毫无疑问，文档不被继续维护，任何支持（如果一开始提供支持的话）都将完全消失。在某些情况下，这可能是一个合规性问题——例如，在支付领域，获得 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 说：“这就和我们学习骑自行车一样，有些人跳上车并自己完成，另一些人则需要有人帮助在转向时稳定座椅，而你则需要学习如何上下踩踏板。”

他确信，只要有人需要了解数据库，数据库管理和支持服务就依然保有价值：“我们已经存在足够长的时间，知道如何绕过坑洼，避免上坡。”