高性能 MySQL 第四版（GPT 重译）（四）(3)https://developer.aliyun.com/article/1484357
跟踪变更的不良选项
您可能会问，“为什么不使用触发器跟踪我关心的表的任何更改？”这绝对是我们过去看到的一种方法，但不建议。以下是我们不建议使用触发器的一些原因：
- 已知触发器会对写入性能造成影响，这将在最糟糕的时候影响您。
- 触发器相当于将业务逻辑存储在数据库中，这是不推荐的。
- 将代码存储在数据库中可能会绕过对该代码进行测试、分期和部署的任何流程。在事件期间，触发器可能会成为您的团队的意外惊喜。
- 触发器只能支持跟踪写入操作。如果需要，它无法扩展到跟踪读取访问。
让我们看看如何使用 Percona 审计日志插件以及如何调整它。
安装和调整 Percona 审计日志
Percona 的审计日志插件作为 Percona 的 MySQL 分支的一部分提供，但默认情况下未安装或启用。您可以通过在任何新实例的引导过程中运行以下命令来安装它：
INSTALL PLUGIN audit_log SONAME 'audit_log.so'; SHOW PLUGINS;
第二个命令列出正在运行的插件，并应确认审计日志插件实际上现在作为服务器进程的一部分在运行。除了启用它，您还需要确定如何摄取其输出。这就是真正的计划发生的地方。
Percona 的审计日志插件允许您定义需要跟踪的语句动词。这允许灵活地满足各种控制要求，而不会在审计日志中产生大量与您关心的内容无关的噪音。确保您查阅其文档以正确配置该变量。
插件的一个灵活优势是您可以安装它，但实际上不监视查询。这在您仍在研究如何摄取其输出并需要在不影响正常运行的情况下关闭和打开它时非常有用。但是，这种灵活性也带来了复杂性。除了管理审计日志插件附带的配置变量之外，您还需要监视它是否始终运行。如果这对业务来说是一个关键功能，那么值得监控。由于插件可以在不重新启动服务器的情况下禁用，您需要更多的方式来确认它是否正在执行所需的操作，而不仅仅是检查磁盘上的my.cnf文件以确认它是否正在执行所需的操作。您最好使用 shell 查询来解析插件的当前状态，并确认它是否实际上正在监视查询。以下是两个示例单行查询来检查这两个方面：
# Single liner to check that the audit log plugin is active $ mysql -e "show plugins" | grep -w audit_log | grep -iw active # Single liner to check that the plugin policy is actually monitoring queries $ mysqladmin variables | grep -w audit_log_policy | grep -iw queries
这些示例假定您只想监视查询。如果您还希望使用插件来跟踪登录，您需要编辑检查。
摄取和使用审计插件日志
正如您所见，审计日志插件具有很大的灵活性，但它也只为您生成审计事件。您需要确定最佳方法来摄取这些日志，将它们放在一个可以轻松搜索和分析的地方，并合理地发现其中的异常，而不至于成为一个重大负担。插件可以简单地将输出转储到本地文件，但这可能会增加通过这些日志填满数据库主机磁盘而导致故障的风险。
更复杂的选项是使用插件将其输出发送到rsyslog，这是一个常见的 Unix 日志管理实用程序，然后使用rsyslog将所有这些事件转发到您组织选择的结构化日志平台。这个选项很吸引人，因为它将这些数据带入到您的组织已经进行结构化日志存储的地方，这降低了数据库团队之外的利益相关者查看、搜索和分析这些事件的门槛。请记住，使用rsyslog以这种方式进行日志转发将要求您熟悉它的工作原理。确保您决定并以有意义的方式记录rsyslog如何配置这个数据流。可能有许多rsyslog的默认配置对您期望的结果没有帮助，您需要尽职调查找出这些配置并相应地更改它们。
警告
确保记录审计日志插件输出的存储方式，即使是临时存储在数据库主机上。如��这些文件的传送方式变慢，插件中缓冲事件的影响可能会影响数据库服务器本身的性能。这种故障状态很难调试，因为它的唯一症状是查询执行变慢。考虑以弹性为主的整个这些日志管道的混沌测试计划。
Percona 审计日志插件是一个强大的工具，可以帮助您满足许多合规性控制要求。根据我们的经验，它比使用触发器更高效，并且与配置管理和结构化日志记录软件很好地集成，从而形成一个对多个利益相关方团队有效的解决方案。
模式更改的版本控制
第六章介绍了不同的策略和工具，有助于规模化运行模式更改。让我们谈谈这些策略所支持的合规性问题。
使用版本控制来跟踪和运行模式更改，内置跟踪请求更改的人员、审查和批准的人员以及在生产中的运行情况。这也是使用每个数据库集群单独存储库的一个很好的理由。随着公司中数据库的增长，您会发现并非所有数据库都是平等的。有些需要更严格的合规性（例如，保存财务数据的数据库），而有些则用于不太关键的产品实验。在进行审计时，为每个数据集和集群提供更改记录将是一个巨大的便利。
基于合规需求的数据和集群模式管理的分离还使得更容易控制谁可以提交或批准您选择的版本控制管理中的模式更改。在进行业务审计时，通常需要证明谁可以对数据库进行更改。拥有一个较小的人员操作圈 可以 对这些数据进行更改，符合最小权限安全原则。
数据库用户管理
对数据库的更改不仅限于模式更改。您还需要以可跟踪和可重复的方式管理数据库用户及其细粒度权限。让我们看看如何满足一些常见的合规性控制，以解决数据库访问控制问题。
使用配置管理
使数据库用户跟踪合规的一个简单方法是利用与使数据库配置更改合规的相同流程。您可以在配置管理存储库中管理所有内容，并使用源代码控制、拉取请求流程和同行审查来提供证据，证明对数据库用户的所有更改都是以可审计和可跟踪的方式完成的。
计划凭证轮换
无论是因为未经计划的安全事件还是因为您有一个需要按计划轮换凭证的控制，您都需要制定一个计划，以便在不影响应用程序正常运行时间的情况下轮换数据库用户。这可能意味着更改应用程序使用的用户名和密码字符串。如果您尚未运行最新且最好的主要版本以支持双密码，请按照以下步骤在生产中旋转数据库凭证，而不会影响服务正常运行时间：
- 首先在数据库中引入一个新的用户名/密码对。
- 测试新凭证是否具有与旧凭证相同的访问权限。理想情况下，您应该自动执行此操作，作为部署新凭证的一部分，通过比较
SHOW GRANTS并确认权限是否相同。 - 创建一个应用程序部署，替换应用程序配置中的凭证。
- 重新启动此服务的所有实例，以确保新对正在使用。
- 删除旧的用户名和密码对。
无论更改是例行还是紧急的（因为凭证泄漏或安全风险），此过程应该是相同的。由于后者不是您可以控制或完全防止发生的事件，最好将此过程自动化，或至少在运行手册中进行充分记录，并定期执行，以便在发生意外情况时，团队不会感到恐慌。
提示
在 MySQL 中旋转数据库用户密码曾经是一个复杂的协调工作，需要在不影响可用性的情况下完成。MySQL 8.0.14 引入了双密码支持，结合密码过期策略支持，使得在操作上更容易做正确的事情。
停用不再使用的数据库用户
任何未使用的数据库用户仍然在您的实例上活跃是一个您不需要的安全风险。定期审计您实例上活跃的数据库用户，与您的应用程序配置进行比较，并删除任何未被任何应用程序活跃使用的用户是很重要的。
当为您的公司满足合规需求时，您会发现许多合规控制要求组织跟踪对某些资产的任何和所有更改。这些控制在报告中很典型，比如我们在本章前面描述的 SOC 2，其中主要关注的是提供数据完整性和安全性的证据。
有几种方法可以找出一个定义的数据库用户是否正在使用。我们在第三章中广泛介绍了 Performance Schema 作为检查服务器性能的一种方式。在 Performance Schema 中有一个 users 表，存储了连接到服务器的用户的历史信息。这种历史跟踪可以追溯到服务器进程的生命周期或此表允许的最大大小，以先到者为准。由于该表跟踪已连接的用户，而不是未连接的用户，您需要循环遍历已知用户，并查看是否有任何用户不出现在此表中，作为他们可能不再使用的信号。
这是一个启用 Performance Schema 中该工具的查询：
mysql> UPDATE performance_schema.setup_instruments -> SET ENABLED=‘YES’ WHERE NAME='memory/sql/user_conn'; Query OK, 1 rows affected (0.00 sec) Rows matched: 1 Changed: 1 Warnings: 0
一旦您启用了这个功能，查找此信息的表是 performance_schema.users。
如果您为合规控制使用审计日志解决方案，比如我们之前提到的 Percona 插件，您可以使用这些日志来确定用户是否在给定的几周内连接到实例。
无论您如何确定这一点，建议设置一个政策，“在六个月的不活跃后，将删除未连接的数据库用户。” 这是一个有助于防止不需要的访问权限并且现在是一个风险的做法。
您帮助管理的数据库将受到需要这种谨慎程度的控制范围。随着您的公司不断发展并开始考虑更加合规，您需要有一个故事来展示在将数据库更改应用之前如何审查和跟踪生产数据库的变化。合规控制还将关注的另一件事是证明您在发生灾难事件时恢复数据和服务的能力。为此，我们需要转向备份和恢复，看看它们如何适用。
备份和恢复程序
第十章涵盖了不同类型的备份。备份显然很重要。它们在事件中可以极大地帮助，同时也是许多合规控制的关键部分。在大多数 SOC 2 实施中，您将有关于创建和测试备份的控制（但无论如何，您应该测试您的备份）。随着您管理的数据库集群数量增加，您很快会发现无法继续手动执行备份和备份测试等流程，甚至无法通过手动阅读日志文件报告成功和失败。
在评估出于合规原因如何管理备份时，您需要满足一些要求：
- 您需要自动化备份过程。
- 如果备份失败，您需要备份过程提醒您。
- 您需要自动化备份测试。
- 备份测试失败也应该是您可以在某处跟踪的事件。
接下来我们讨论如何安排备份和备份测试。
运行自动备份和备份测试
为了满足这些要求，��需要一个机制，不仅仅运行计划任务（例如 Linux 系统中的crond），而且可以按计划运行，并且还具有向您的监控系统和工单系统发送事件的能力，以便在失败时发出警报并为以后的审计跟踪失败。您可以通过将备份和备份测试作为监控检查运行来做到这一点，⁴但是备份可能需要一段时间才能运行，特别是如果您有一些以 TB 为单位的数据库实例。只要监控系统可以处理运行时间远远超过几秒的典型时间的检查，将备份作为监控项目运行就可以工作。因此，请确保运行监控系统的团队意识到这种用例。
如果您的监控系统无法处理这种用例，那么请确保您有一些方法留下“踪迹”以跟踪备份已经发生并成功完成，以及备份测试已经发生并成功完成。这样的踪迹可以是一个文件，其中包含备份或备份测试运行结束时您的备份过程编辑的时间戳，作为任务发生并完成的证据。一旦放置了这个踪迹，您可以使用监控系统进行更快速的检查，以确保踪迹存在。
在所有这些策略中，您想要拥有的，以及您的 SOC 2 控制要求的，是备份成功完成的记录以及任何失败的备份的记录，显示它们已转化为正确跟踪的工作项。
备份和备份测试的集中日志
您可能还会被要求展示日志，证明备份和备份测试过程成功完成。您最好准备好这样的审计项目，通过使用可以将日志发送到以保持连续性的集中日志解决方案。请记住，我们为这些业务需求构建的解决方案应该假设服务器易于且可重复替换，而不是定制的。因此，如果您在下一次审计之前退休该机器并替换它，那么随机实例上的本地日志文件并不理想。您希望任何与业务相关的资产，例如备份过程的日志，都位于任何具有正确访问策略的人都可以访问的集中位置。
通过备份进行灾难恢复规划
作为 SOC 2 的一部分，还需要进行适当的灾难恢复规划。这意味着您需要证明您测试系统生成的任何备份，您需要跟踪这些测试失败的时间以及失败已经被纠正，并且最好您需要知道数据灾难恢复需要多长时间。这最后一部分需要跟踪备份测试需要多长时间的指标。第二章提到数据库实例大小作为确定备份恢复是否在预期时间内变得过大的度量标准。使这成为一个自我改进的循环的方法是使您的备份和测试备份的脚本也发送每个任务需要多长时间的指标。这样，您就可以获得每个数据库集群备份需要多长时间以及恢复和测试这些备份需要多长时间的指标。现在您有了一种跟踪任何给定数据集是否变得过大以至于超出业务对 MTTR 的期望的方法。如果是这样，那么您有数据要么优先处理将数据集分割到可接受大小，要么重新审视业务的恢复 SLA。
关于备份的一个重要最终注意事项：您的安全利益相关者需要访问实时数据库和备份以进行控制。确保您在您喜爱的云服务提供商中的备份设置不会默认为备份存储桶的宽松访问控制。许多安全漏洞并非通过侵入实时基础设施发生，而是通过从某个存储桶泄漏的备份发生。
摘要
合规性是一个广泛的政策和控制世界，以及对每个解释的影响。它不仅影响您在业务中运行数据库的方式，还影响法律、财务和 IT 部门，甚至影响您如何部署软件更改。本章重点介绍了每种常见类型的合规性法规如何特别影响您作为数据库工程师的职责。然后我们涵盖了这些法规可能受到影响的不同实践和架构决策，您也需要考虑这些。
广义上说，摆脱与控制相关的噩梦的最佳方法是提前计划。分离应用程序用户，制定凭据轮换策略，并确保密码始终以加密方式存储——绝不是明文。确保在需要开始记录对数据库的访问之前，你有一个可信赖的日志记录管道。最后，你希望对模式更改进行控制和记录。
本章的目标不是让你一次性考虑整个基础架构中所有这些控制措施，而是让为每项法规规定的范围提供证据的任务更容易，并尽可能自动化或简化组合。最终，这些控制措施旨在保护企业和客户的隐私。对每项控制措施的目标有清晰的理解将使您和您的团队在公司发展并进入更广泛市场时更容易管理这一重要任务。
¹ 欲了解更多关于这些标准的信息，请与您友好的信息安全团队交谈，或者从 O’Reilly 获取NIST 网络安全框架口袋指南。
² 有关此内容，请参阅插件文档。
³ 作为一个开始，这里有一个关于“可靠日志转发”的整个页面。
⁴ 在博客文章“使用 Sensu 进行 DBA 任务”中，您可以看到一些将备份任务纳入数据库监控解决方案的示例。
附录 A. 升级 MySQL
升级是稳定性和功能之间的权衡。在选择升级时，您应考虑这一点。使用 MySQL 的最大优势之一是其广泛的安装基础。这意味着您可以从许多其他人测试和使用 MySQL 中获益。如果升级到太新的版本，您可能会不知不觉地引入一个错误或回归到您的环境中。如果保持太落后，您可能会遇到不明显的错误或无法利用为性能优化的功能。
为什么升级？
决定继续进行版本升级可能是一个风险的过程。通常涉及备份所有数据，测试更改，然后运行升级过程。在我们深入讨论细节之前，了解为什么您可能希望升级是很重要的。
有许多升级的原因：
安全漏洞
多年来，发现 MySQL 中的安全漏洞的可能性已经减少，但仍然有可能。您或您的安全团队可能会评估这些漏洞，并确定您应该执行升级。
已知错误
在生产环境中遇到未知或无法解释的行为时，我们建议找出您正在运行的 MySQL 版本，然后阅读最新版本的发行说明。您完全有可能发现您正在经历的情况实际上是 MySQL 中的软件错误。如果您的问题得到解决，您可能需要升级 MySQL。
新功能
MySQL 在如何添加功能方面并不总是严格遵循主要/次要/点版本发布策略。许多人可能期望点版本（例如，从 8.0.21 到 8.0.22）只包含错误修复，而次要版本更改（从 8.0 到 8.1）将包含次要功能。Oracle 经常在次要点版本中发布可能对您的工作负载产生影响的新功能。这种策略是一把双刃剑，这就是为什么在升级之前应该阅读所有的发行说明。
MySQL 终止生命周期支持
Oracle 为 MySQL 设置了终止生命周期（EOL）时间。一般来说，建议保持在支持的版本内，这样至少安全修复仍然受支持。
现在我们已经讨论了影响您升级决定的各种因素以及具体版本，让我们讨论规划和安全完成升级的过程。
升级生命周期
一旦您做出升级是正确的决定，通常会采取以下步骤：
- 阅读该版本的发行说明，包括任何次要更改。
- 阅读官方文档中的升级说明。
- 执行新版本的测试。
- 最后，升级您的服务器。
发行说明通常包含重要信息，如新功能、更改或已弃用的功能，通常还会列出已修复的错误。升级说明为您提供了如何执行升级的详细概述，并提醒您在继续之前需要了解的任何重要信息。
此外，您还应该制定一个计划，以应对引入问题的情况，比如查询开始表现不佳，或者更糟糕的是，您开始遇到崩溃错误。对于所有主要和次要版本更改（例如，从 8.0 降级到 5.7 或从 5.7 降级到 5.6），唯一的降级方法是从升级之前的备份恢复。这使得升级特别危险，因此请确保您有一个计划。
警告
需要注意的是，自 MySQL 8.0 起，您也不能降级点版本。例如，一旦您运行 8.0.25，您就无法降级到 8.0.24，而不导出所有数据并重新导入。
测试升级
一旦您阅读了发布和升级说明，您应该对任何测试的关注点或重点有很好的理解。下一步将是测试这个新版本在您的工作负载下的行为。您还需要验证您已经审查了配置文件。MySQL 的新版本通常会重命名变量或完全弃用它们。
测试是一个难以完成的步骤，每种方法都有注意事项。考虑到之前提到的关于降级的风险，您应该在升级之前尽可能多地采用这些方法。
开发环境测试
希望您有一个用于数��的开发环境。这是开始测试的好地方，可以在共享开发数据库上进行测试，也可以在独立数据库上进行测试。使用这个的主要目标是发现任何明显的语法问题。大多数开发环境不包含与生产数据相同大小的数据，因此很难进行准确的测试。例如，您可能运行您常用的查询并看到它们正常，因为它们只访问表中的 10 行。当您转到生产环境时，表中有 1000 万行，您可能会看到退化。
生产镜像
另一个选择是创建生产数据的副本，并将您的 SQL 流量发送到副本。这种方法在Etsy 的 Code As Craft 博客上的一篇博文中展示过。简而言之，您有生产数据库的第二个副本，停止使用复制，并在副本上升级 MySQL。完成后，使用tcpdump和pt-query-digest的组合将流量发送到您的实时生产系统和副本。您的应用程序仍然仅使用生产系统进行实时流量，而具有升级版本的副本可以为您提供性能指标并显示语法错误。
副本
如果您的拓扑结构有读取副本并且您有能力将副本脱离池，您可以考虑首先升级其中一个副本。这将允许您查看实际生产工作负载下的读取流量表现。如果观察到错误或退化，您可以将副本脱离池并进行调整。这种方法的缺点是您无法测试性能或写入流量。
工具
Percona Toolkit 提供了工具pt-upgrade，它接受查询作为输入，针对两个不同的目标运行这些查询，并生成报告告诉您行数、行数据或错误的任何差异。由于它可以接受许多不同类型的输入（慢查询日志、常规查询日志、二进制日志），它可以是获得额外测试覆盖的好选择。
最佳使用方法是首先收集您最感兴趣的查询，可以使用慢查询日志或二进制日志。然后设置两个相同的系统，仅将其中一个升级到新版本，并对两者运行pt-upgrade以查看差异。
大规模升级
升级 MySQL 非常简单，并且在官方 MySQL 文档中有详细介绍。简而言之，如果您正在进行原地升级，您将停止 MySQL，替换二进制文件，启动 MySQL，然后运行mysql_upgrade脚本。
如果您在数百个 MySQL 服务器上执行此操作，这可能会变得重复。我们建议尽可能自动化这个过程。您可以使用 Ansible 的一种方式来实现这一点。
这里是一个建议的安全升级过程的骨架，您可以将其用作构建 Ansible playbook 的指南，如果您选择的话：
1. 验证目标。
你要做的第一件事是防止生产系统的意外升级。如果您有一个可以查询以确定数据库是否正在接收流量的系统，这是检查的地方。如果您遵循我们在第五章的建议，应该使用read_only标志来防止对副本的意外写入。如果没有可以检查的系统，这可以作为一个很好的替代方案。如果服务器是可写的，那么您可能不希望对其进行升级，因为它可能正在接收生产写入。您还可以使用此步骤验证您是否已经升级了服务器。这样可以稍后对其运行 playbook，而它将不执行任何操作。
2. 设置停机状态。
希望你的系统正在被监控。下一步涉及设置某种形式的停机或警报抑制，以便在 MySQL 在新版本上重新启动时不会收到警报。
3. 其他前提条件。
如果您有任何其他依赖服务，比如配置管理工具或其他监控工具，在 MySQL 离线时会生成错误，现在是关闭它们的好时机。
4. 删除旧包。
我们首选的方法是此时完全删除任何已安装的 MySQL 包。这有助于避免主要版本（5.7 到 8.0）之间的任何冲突包。
5. 安装新包。
接下来，您将希望在系统上安装新包。
6. 启动 mysqld。
启动mysqld服务。
7. 运行 mysql_upgrade。
如果早于 MySQL 8.0，²运行mysql_upgrade过程。特别注意，如果您像我们建议的那样使用super_read_only运行 MySQL，则在mysql_upgrade步骤中将其设置为OFF。
8. 重新启动 mysqld。
我们更喜欢在此时对mysqld进行干净重启。这将确保它正确启动并使用升级后的文件，并且您的配置文件也在工作。
9. 验证您可以连接。
简单连接并运行SELECT 1以确保 MySQL 正常工作。
10. 恢复任何已禁用的服务。
如果关闭了任何配置管理或监控工具，请重新启用它们。
11. 清除停机状态。
将服务器从停机状态中取出，以便观察是否有任何升级过程失败的情况。
通过这个过程，您可以将您的运行手册指向任何服务器，并仅升级不接收流量的未升级节点。
摘要
升级 MySQL 有许多原因，最引人注目的是修复您正在遇到的错误或利用新功能。例如，MySQL 8.0 引入了一个功能，InnoDB 可以立即添加列，无需重建整个表。这种功能增强对于执行大量ALTER TABLE .. ADD COLUMN语句的公司来说可以节省大量时间。通过努力进行安全升级过程，最终将节省执行这些列添加语句的时间，以及改进开发人员体验。
主要版本升级可能令人生畏。您绝对应该花费大量精力测试升级是否会产生任何不良影响。通常，您希望检查升级是否导致任何查询延迟偏差或新错误。一旦您获得信心，慢慢推出并具有回滚过程。
最后，如果您有大量服务器需要管理，请考虑大力投资于尽可能自动化该过程。自动化可以使升级过程变得更容易重复，并比直接登录每台服务器更节省时间，也减少了因在错误服务器上而导致的拼写错误和意外停机的几率。
¹ 长期参与 MySQL 社区的成员 Stewart Smith，著名地提出了点二十规则：“[规则] 是指软件在发布点二十版本之前永远不会真正成熟。”虽然这不是一个严格的规则，但它突显了新版本和稳定性之间的权衡。
² MySQL 8.0 将 mysql_upgrade 过程移入了服务器启动过程中。无需作为额外步骤运行。
附录 B. Kubernetes 上的 MySQL
如果您在过去五年中一直在科技领域工作，很可能已经听说过 Kubernetes，与运行 Kubernetes 的团队合作，或者看过很多关于 Kubernetes 的会议演讲或阅读了很多博客文章。如果您的组织运行自己的 Kubernetes 集群，那么在某个时候，您会被问及是否在其中运行 MySQL 也是一个好主意。从表面上看，这似乎是一个合理的选择。管理许多 Kubernetes 集群是一个复杂的任务，通常需要专门的人力资源，因此您的组织希望利用这种专业知识来处理不仅仅是无状态工作负载。但是，有很多理由可以探索在 Kubernetes 上运行 MySQL，也有一些不太好的理由。让我们在这里揭开一些关于在 Kubernetes 上运行 MySQL 的恐惧、不确定性和怀疑。
使用 Kubernetes 配置资源
在 Kubernetes 达到技术高峰之前，许多公司要么构建了完全定制的技术堆栈来配置和管理虚拟机和裸金属服务器，要么将开源项目粘合在一起，完成资源生命周期的较小部分。然后 Kubernetes 出现了，作为一个更完整的生态系统，用于管理计算和存储资源，将其作为统一的配置堆栈的前景变得越来越吸引人。然而，像 MySQL 这样的有状态负载仍然落后，因为普遍看法是“你不能在容器上运行数据库。”
仔细界定您的目标
要记住的重要事情是“我们想在这里获得什么具体价值？”Kubernetes 对于无状态负载非常强大，因为它带来了计算资源的弹性和效率。然而，在查看统一的配置堆栈时，将胜利范围缩小到“我们只想使用 Kubernetes 来配置和配置数据库资源系统。”这意味着您需要事先明确，将使用 Kubernetes 配置的数据库工作负载将与无状态工作��载分开管理，需要不同的操作员技能集，并且将以不同方式处理容器故障。
选择您的控制平面
现在有各种 MySQL 操作员，但最佳选择将主要取决于您决定的 Kubernetes 管理 MySQL 的范围。您是否需要一个可以完成所有工作的操作员：配置、故障转移和管理连接到数据库？还是您只需将 Kubernetes 用作配置堆栈，并在服务后使用其他方法来管理数据库？早早决定您对控制平面的期望，因为这将驱动许多更精细的可操作性细节。
更详细的细节
一旦您决定开始使用 Kubernetes 配置 MySQL 资源，您需要在组织中就适合此解决方案的数据规模达成一致。请记住，这现在是一个新的操作模型，用于运行关系型数据库，而在这条少有人走的道路上，随着规模的扩大，一切都变得更加复杂。以下是一些重要事项，您在与 Kubernetes 工程团队合作时（希望您有专门的团队负责此事）需要考虑如何支持有状态工作负载：
- 单个数据库实例支持的最大数据集大小是多少？
- 您是否将卷挂载到容器中，并将容器恢复与数据挂载分开管理？还是数据将成为容器的一部分？
- 将支持的最大查询吞吐量是多少？您将如何管理资源？
- 您将如何确保运行数据库工作负载的 Kubernetes 节点专用于此，而不与无状态、更具弹性的工作负载共享？
- 您将使用什么控制平面来运行数据库实例？它是否是 Kubernetes 本地的？
- 备份将如何工作？恢复过程是什么？
- 您将如何控制并安全地推出配置更改和 MySQL 升级？
- 您将如何升级 Kubernetes 集群本身而不会造成中断？
与您的合作伙伴 Kubernetes 工程团队就这个解决方案的工作方式达成一致意见，将有助于为希望使用该解决方案的功能团队建立完善的 SLO，并在正确传达解决方案解决了什么以及团队仍需自行解决什么方面。
我们在运行 MySQL on Kubernetes 时的建议是投资于学习一个已经在 Kubernetes 生态系统中经过验证和证明的控制平面，比如 Vitess。但在尝试运行之前，也要先爬行。在您的组织中，MySQL 不应该是在 Kubernetes 上运行工作负载的第一个实验对象。始终要证明可行性，并与无状态工作负载团队一起学习尖锐的边缘，然后再尝试运行像 MySQL 这样更复杂的用例。在确定最佳的初始采用用例时，从小数据集（仅在磁盘上几个千兆字节的数据库）和较少关键数据集开始，以使您的团队、Kubernetes 团队和功能团队熟悉在 Kubernetes 上运行有状态工作负载的新操作模型，同时对业务风险较小。
在 Kubernetes 上运行有状态工作负载已经成熟了几年，并且随着那些投入大量工程时间使其更具可行性的公司的重要贡献，它仍处于初期阶段，与直接在 VM 上运行相比，您会发现缓慢和谨慎的采用方法才是长远回报的关键。特别要考虑 MySQL 在 Kubernetes 上的故障模式是什么样的，并问自己：如果一切都出错了，我该如何重新组合？我会丢失数据吗？确保您有答案。
总结
Kubernetes 是当前技术领域中增长最快的基础设施平台之一，而且理由充分。它所带来的工程速度和由云原生基金会支持的丰富生态系统使其成为公司吸引投资的有吸引力的选择。但您应该通过风险和回报的视角来考虑像在 Kubernetes 上运行 MySQL 这样的决策，以及对您的团队和公司的影响。确保您对组织的 Kubernetes 之旅中像数据存储这样的有状态服务的位置有共同的理解。想要利用 Kubernetes 对所有工作负载的现有投资是可以理解的，但这需要与数据存储层的稳定性需求进行良好的平衡。
¹关于在 Kubernetes 上运行数据库工作负载的出色“实战”会议演讲，我们推荐由 Alice Goldfuss 主持的“容器操作员手册”主题演讲。
