云中的 MySQL 是 DBA 的终结吗？_

作者 | Daniel Nichter

译者 | 平川

策划 | 刘燕

本文最初发布于 Daniel Nichter 的个人博客 Hack MySQL。

这篇博文是该系列 11 篇文章中的最后一篇：一篇是前言，其他 10 篇对应我写的 Efficient MySQL Performance 一书的 10 个章节。这里有完整列表。

几年前，我参加了 Oracle 在当地举办的一次聚会。令人敬畏的 Kenny Gryp 也在那里。但我记得最清楚的是和另一位 DBA 的对话，我和他不是很熟，所以不管你是谁，请原谅我后来忘记了你的名字。但我记得，当我说 MySQL 需要更多的 DBA 时，你说了什么：你说不需要，因为云正在接管 MySQL 管理。

多年后，我看到了这样的情况：招聘一个有经验的 MySQL DBA 变得极其困难；取而代之，我们招聘优秀的软件工程师（有时是刚从大学毕业的），并培训他们运维之前就有的 MySQL 机群，我们不期望他们“深入”MySQL——当然也没期望他们能成为 MySQL 专家。

现存的独立 MySQL 专家是我们这类人里的最后一批。

这里的“独立”是指使用 MySQL，但不开发它。当然，Oracle 会继续招聘和培训工程师来开发 MySQL，他们将成为他们这个开发领域的专家，但是，我这里说的是 DBA：管理 MySQL 并公开撰稿介绍 MySQL 的人 — 选择深入研究 MySQL 并进而成为专家的人，而不是被雇佣并进而成为专家的人。

那是可以的，因为现如今，MySQL DBA 的工作与其说是关于 MySQL，不如说是关于 MySQL 的一切：存储、计算、安全、合规性、数据平台和软件工程师。当然，对于更广泛的行业来说，也会有新的发展，不断出现的 Bug，以及一些需要独立专家来揭示并解决的常见问题。但总的来说，符合标准设置的 MySQL 就足够了。

这就是云的用武之地，因为没有 DBA 会真的想要在一个裸金属机群上操作 MySQL。是的，那很酷，很有技术含量——让你感觉很特别。但是，除非你是在一个稳定的（或变化非常缓慢的）环境中，否则你就要把太多的时间花费在硬件变化和问题跟踪上。

就像我们的个人电子设备一样，企业硬件的变化也非常频繁，因为销售人员需要把更新、更亮的产品卖掉。机架服务器中那些拥有 BIOS、固件和内核理想组合的 5TB 企业级 SSD 不是可以帮助 MySQL 运行得很好吗？再也不能买了。此外，最新的 BIOS 更改了风扇转速管理，这会影响 CPU 温度，进而影响 CPU 时钟速度，从而严重影响了查询响应时间。当测试备用电源板导致两者都失效时，你就翻白眼了……

正如我在 Efficient MySQL Performance 一书第 10 章所写的那样，云运行 MySQL，但它不能代替 DBA 的工作：

虽然“You”下面对勾的数量是“Cloud”下面的两倍，但“Cloud”下面的那 5 个对勾很重要，因为它们处理了所有底层工作（尤其是硬件）——最繁重而影响最小的那部分工作。根据你与 MySQL 的关系，“Cloud”下面的 5 项工作对你的影响会有所不同：

云让 DBA 可以专注于提供更好的用户体验，从与“DBA”下的勾选项有关的方面。例如，提供更好的服务器和查询指标，帮助用户（软件工程师）理解应用程序如何影响 MySQL 及其性能。这就是我们的职业发生变化的原因：我们可以在上层与软件工程师开展合作，以便更有效地理解和利用 MySQL，而不是在下层与 MySQL 搏斗。这在云计算领域尤其重要，因为在云中，“大型硬件”非常昂贵，或者按使用量付费泛滥成风。

软件工程师

云将为你运行 MySQL，但这不同于管理。你很快就会发现，云仍然给你（或你的 DBA）留下了许多需要 DBA 完成的工作。在 MySQL 世界中，在线更改模式（运行 ALTER 语句而不阻塞任何查询）是一个常见的、云无法解决的需求。因此，如果你是一名云 MySQL 新手，请注意这一点，不要对此感到惊讶：如果你关心安全性和灾难恢复（DR）等问题，那么你需要多做一些工作才能使云中的 MySQL 真正达到生产状态。

随着时间的推移，我认为云提供商将提供更多的功能。例如，亚马逊提供了服务器指标、查询指标、DR 和 HA 的解决方案；但坦率地说，我认为它们还没有好到可以在“Cloud”列下增加一个对勾。例如，关于 Amazon RDS 和 Aurora，有一个地方就让我很恼火：当你为 DR 设置跨区域复制时，如果复制由于他们的问题而停止，亚马逊并不会监控或提醒你——他们当然也不会修复这个问题。这让我很恼火，因为复制是他们的产品特性，所以在这种情况下，他们应该监控并确保它能够继续工作。但是，它可能会悄无声息地失败，除非你知道存在这种情况，自己监控并修复它。即便如此，因为这是他们在他们那边设置的，我也遇到过无法从我这边解决的情况。

如果你还是不相信，我再举一个例子：我还遇到过这样的情况，亚马逊云科技说复制是按他们的 API 设置的，但 MySQL 没有针对复制做配置——这明显是亚马逊云科技方面犯的一个严重的错误，目前还没有简单的修复方法。购者自慎。

云 MySQL 正在发展，这意味着传统 DBA 对运行 MySQL 的关注将越来越少，而对帮助软件工程师有效地使用 MySQL 的关注将越来越多。

这就是我写 Efficient MySQL Performance 这样一本书的原因：针对使用 MySQL 的软件工程师，而不是 DBA，因为后者已经赢得了众所周知的战争：MySQL 已经在世界上很大的范围内运行，而且很有效。但是，关系数据库很复杂，有时候会让软件工程师无法从 MySQL 那里获取他们最需要的东西：性能。

但是，云并不关心 MySQL 的性能。不管是快的还是慢，收费都一样。这就是为什么云永远不会成为 DBA 的终结。这也是为什么我们转了一圈又回到了我书中的第一句话：