高性能 MySQL 第四版（GPT 重译）（四）(2)https://developer.aliyun.com/article/1484356
GCP Cloud SQL
Cloud SQL 是 GCP 的托管 MySQL 产品。这种产品与 AWS 的主要区别在于它运行社区服务器，但特定功能被禁用，以便实现产品的多租户性和托管性。以下是一些你不能在 Cloud SQL 中使用的功能，尽管它运行社区服务器：
SUPER权限被禁用。- 禁用加载插件。³
- 一些客户端也被禁用，比如 mysqldump 和 mysqlimport。
与 AWS 的产品类似，您无法访问实例的 SSH。
另一方面，Cloud SQL 为您管理了许多运营任务：
- 本地高可用性支持。故障转移通过配置选项自动化。
- 数据静态加密。
- 灵活管理升级，使用多种方法。请注意，最终这些维护窗口会涉及一些停机时间（类似于 AWS Aurora），您需要平衡这一点与应用程序 SLOs 的责任。⁴
正如我们在本章开头提到的，您可能没有选择在哪个云提供商中构建这些数据库的选择，因此您更可能需要了解所选云提供商提供的托管选项以及如何使用它，或者提出直接使用虚拟机而不是托管 MySQL 的理由。
现在我们已经介绍了托管关系型数据库选项以及这些选择的复杂性，让我们谈谈稍微更复杂的路径：在云托管的虚拟机上运行 MySQL。
虚拟机上的 MySQL
托管 MySQL 的特性对于那些想快速上手的人可能非常吸引人，那么为什么有人选择自己运行呢？在虚拟机上运行 MySQL 就像在裸机上运行一样。您可以完全控制所有操作方面。您可以在单个区域运行主 MySQL，但在其他区域设置副本以用于灾难恢复，或者运行一个延迟副本。您还可以根据工作负载最优化地定制备份方法。如果性能下降或遇到问题，您可以完全控制操作系统和文件系统，允许您进行任何自查。
云中的机器类型
如 第四章 中讨论的，MySQL 的 CPU 核心数量和可用 RAM 对 MySQL 的性能有直接影响。为数据中心选择特定硬件规格的缺点是它们不能很容易地更改。如果您有一个 56 核、512 GB RAM 的机器架设，您当然可以减少安装的 RAM，但您已经为此付费了，所以除非您可以在其他地方重复使用 RAM，否则您可能在硬件上花费过多。
当您使用云提供商时，为您的工作负载优化机器规格要容易得多。主要的云提供商允许您选择设置虚拟 CPU（vCPU）范围、可用的 RAM 量、网络和磁盘限制的机器规格。随之而来的是，您可以根据工作负载的变化调整 VM 的大小。这意味着，如果您在一年中的特定时间经历高峰流量，比如假期季节，您可以临时增加机器规格以应对这种情况。一旦流量模式回落，您可以再次将它们调整为更小。这种灵活性是许多人转向云的原因。
选择正确的机器类型
如果您已经在云提供商上，选择一台机器相当简单。如果遇到 vCPU、内存或网络瓶颈，您可以找到适当的机器类型来克服，并调整大小。但如果您从数据中心搬迁，确定正确的配置可能会有些棘手。
CPU
在第四章中，我们讨论了如何为你的工作负载选择正确的 CPU。当你转移到云时，大部分指导仍然适用。请记住，与云提供商一起，你得到的是虚拟 CPU，而不是物理 CPU。这意味着 CPU 不是专门属于你的。它可能与同一物理主机上的其他租户共享。很可能，你会看到比在你自己的独立服务器上更多的延迟和利用率变化。
如果你从物理机器迁移到云提供商，估算你的 CPU 使用量也可能会有些棘手。我们成功地使用以下公式来计算 vCPU 数量：（核心数 × 95% 总 CPU 使用量）× 2。
例如，假设你在数据中心有一台 40 核服务器。在过去的 30 天里，CPU 使用率的峰值为 30%。在云提供商中以 50% 利用率运行这个需要多少核心？使用上述公式，我们会估算出 24 个核心。如果你选择的云提供商没有提供 24 核的机型，考虑四舍五入到最近的类型或确定你的提供商是否提供自定义机型。⁵
警告
随着 CPU 使用率或核心数的增加，上下文切换也会增加：在 CPU 上切换任务的行为。因此，你不希望运行在 100% 的 CPU 容量，因为你会浪费大量时间在线程之间切换。这将表现为查询的延迟。我们建议目标是 50% 的典型利用率，峰值可达到 65%–70%。如果你维持在 70% 的 CPU 或更高，你可能会看到延迟增加，你应该考虑添加更多的 CPU。
也要注意 CPU 芯片系列，如果有这个选项的话。如果你正在运行一个高流量的网络应用程序，你可能希望确保你有一个更晚一代的芯片可用。同样，如果你正在考虑后端数据处理，在那里旧的、稍慢一些的 CPU 芯片系列可能是可以的，这可能会节省成本。
内存
正如第一章和第四章所讨论的，RAM 可以极大地影响 MySQL 的性能。
选择最适合你数据工作集需求的机型规格，更倾向于过多的 RAM 而不是不足。
网络性能
虽然 CPU 和内存大小是选择机型最重要的部分，但确保你也审查了可用的网络性能限制，以确保你不会让你的应用程序挨饿。例如，如果你有一个将读取大量数据的批处理过程，你可能会发现在较小的机型上耗尽带宽。
提示
值得注意的是，云区域和区域之间的网络出口通常是有成本的。当设置副本时，这可能会让人感到惊讶，但我们仍然认为将副本放在不同的区域是很重要的，以实现冗余。
选择正确的磁盘类型
尽管机型通常是动态的，但是为数据存储做出的选择可能是你最复杂的决定。一旦你选择了一个磁盘类型并开始用它来存储数据，转移到另一种磁盘类型就会变得困难。通常情况下，你需要挂载第二个磁盘并复制数据。纠正这个问题并不是不可能的，但肯定比只需快速重启来添加更多 CPU 要复杂。
选择正确的磁盘类型也高度依赖于你期望运行的工作负载。高度读密集型的工作负载将受益于更多的内存而不是磁盘性能，因为内存访问速度快得多。如果你的工作集大于你的 InnoDB 缓冲池，你将总是需要去磁盘读取一些数据。写密集型的工作负载将总是需要去磁盘，这是大多数人开始看到他们的第一个磁盘瓶颈的地方。
附件类型
首先要做出的决定是选择本地连接的磁盘还是网络连接的磁盘。本地连接的磁盘具有提供极高性能和一致吞吐量的优点，但也容易丢失数据。这是因为它们被视为临时数据的磁盘。如果运行本地连接数据的虚拟机的硬件崩溃，你可能会丢失本地磁盘上的所有数据。同样，在某些情况下，即使关闭实例，再次启动时可能会在不同的主机机器上且磁盘为空。本地连接的磁盘通常没有任何复制或 RAID 支持。主机级磁盘故障可能导致数据丢失。如果选择这条路线，我们强烈建议考虑使用软件 RAID，以至少减少数据丢失的可能性。有关 RAID 的讨论，请参见第四章了解更多信息。
相比之下，网络连接的磁盘提供冗余性和可靠性而不是性能。这并不是说网络连接的磁盘性能不好，只是不如本地连接的性能好。你的网络连接磁盘可能会出现停顿，而本地连接的磁盘可能不会。你还可以在本地实现更高的吞吐量和 IOPS 数字。
当使用网络连接的磁盘时，云服务提供商提供方便的备份或快照工具。这些对于 MySQL 使用效果很好，假设你已经配置了符合 ACID 标准的设置⁶并且你的备份解决方案设计得当。你可以在任何时候进行磁盘快照，并通过正常的崩溃恢复无问题地恢复它。
你还可以使用磁盘快照来快速制作副本，即使磁盘大小达到数 TB。通过这样做，你可以最大程度地减少需要追赶的复制延迟量，以便副本可以使用。
请注意，如果使用本地连接的磁盘而不是网络连接的磁盘，你需要自己解决如何使用 LVM 或第三方工具如 XtraBackup 备份数据的问题。有关备份的更详细讨论，请参见第十章。
关于附件类型的最后一点是，云服务提供商不像硬件上的 RAID 卡那样提供写缓存（电池或闪存支持）。
SSD 与 HDD
总的来说，你应该为所有东西使用 SSD，尤其是你的 MySQL 数据卷。如果预算特别紧张，你可以探索 HDD 作为启动磁盘的更便宜选项。在我们的实验中，我们发现 SSD 的启动速度比 HDD 快两到三倍。如果启动时间很重要，尤其是在停机或重新启动情况下，请坚持使用 SSD。
IOPS 和吞吐量
另一个复杂的因素是确定你的 IOPS 和吞吐量需求。在选择需要的磁盘类型之前，你应该对这些需求有一个良好的了解，无论是历史还是未来的。
如果你正在迁移现有工作负载，理想情况下你已��有了这些的历史磁盘使用度量标准，这将帮助你最好地选择你的磁盘。如果没有，你可以使用pt-diskstats，来自 Percona Toolkit 软件包，收集一天的度量标准以测量峰值。
对于新数据库，投入一些时间来了解应用程序的强度。即使了解读写比这样基本的事情也有所帮助。如果其他方法都失败了，找到性能和成本之间的一个良好折中点，并设定可能需要稍后调整的期望。
附加提示
如果选择在 VM 上运行自己的 MySQL，你将需要负责比托管服务更多的事情。你需要自己做磁盘大小调整、备份等工作。如果选择这条路线，以下是一些建议要考虑的。
处理主机重新启动
您的虚拟机实际上只是在别人的硬件上运行。尽管我们不喜欢，硬件可能会出现故障，当这种情况发生时，您的虚拟机将立即终止。如果配置了，您的虚拟机将开始在另一台主机上重新启动。如果这发生在您正在提供生产流量的情况下，尤其是在接受写入的源节点上，可能会对用户造成中断。
没有什么魔法解决方案可以让您避免这个问题 - 您只能处理它。如果发生这种情况，您往往有两个选择：启动到一个副本的故障转移过程（在“复制故障转移”中有介绍），或等待源重新上线。处理未经计划的晋升可能非常棘手。我们的建议是允许服务器重新上线并让复制自然重新连接。
您可以通过遵循以下建议使这个过程更容易应对：
- 使用 SSD 引导磁盘以实现尽快重新启动。通常系统在不到五分钟内恢复在线。
- 在最多五分钟内抑制您对主机宕机的即时通知，以允许系统完全重新启动并恢复健康。
- 如果源服务器重新启动，您可以编写一个选项动态关闭
read_only标志，允许写入继续进行而无需人工干预。当与crond@reboot选项配合使用时效果很好，该选项将在系统启动时运行脚本。唯一的注意事项是您需要能够查询系统以确定系统是否应该接受写入。 - 通过自动向可能需要了解中断的团队或频道发送电子邮件或聊天消息来最大程度地沟通。“主机 FQDN 意外宕机，预计将在五分钟内恢复在线”可能足以阻止人们给您发消息甚至呼叫您。
分离操作系统和 MySQL 数据
无论您选择本地附加还是网络附加，出于以下原因，我们建议将操作系统和 MySQL 数据分开：
- 磁盘快照将仅限于 MySQL 数据，不包含任何操作系统信息。
- 对于网络附加磁盘，您可以轻松地将磁盘断开并重新连接到另一台机器。
- 对于网络附加磁盘，您可以升级或替换操作��统而无需重新复制数据到文件系统。
也要考虑放置特定文件的位置，比如 MySQL 进程 ID 文件、任何日志文件和套接字文件。我们建议这些文件与操作系统保持在一起，尽管日志可能可以留在数据磁盘上。
备份二进制日志
将您的二进制日志发送到一个存储桶。在存储桶上设置生命周期控制，在一定时间段后自动清除旧文件。同样，防止在一定时间段之前删除文件或完全禁止删除。
不要忘记考虑安全性。让全世界都能读取这个存储桶可能是一场等待发生的噩梦。控制谁可以读取或删除这些数据对于维护安全的备份策略至关重要。考虑允许所有数据库机器写入，但没有一个可以读取或删除。从受限制的帐户、机器或两者分别控制读取和删除。
自动扩展您的磁盘
对于网络附加磁盘，您支付的是预留的空间量，而不是使用的空间量。这意味着在 MySQL 数据磁盘上留下大量预留但未使用的空间可能是浪费的。您可以优化的一种方式是将磁盘空间使用率目标定为更高的百分比，比如 90%，但如何减轻磁盘空间耗尽的风险呢？
云服务提供商通常有一个可用的 API 调用来扩展你的磁盘大小。通过一点点代码，你可以确定你的服务器是否超过了 90% 的磁盘已满标记，并调用该 API 来扩展磁盘。这也可以减少接近磁盘空间耗尽而被呼叫的可能性。总的来说，这个过程可以在你花费在预留磁盘空间上产生显著差异。
我们将分享一些关于此的警告，然而：
- 考虑一下应该多频繁运行查找已用磁盘空间百分比的代码。你需要根据磁盘的吞吐量来确定，一个进程需要多长时间才能完全填满剩余的磁盘。你的代码应该比这更频繁地运行。
- 如果你的进程失控并不断扩展磁盘而没有限制，你可能会在付费提供商账单��期时惊讶地发现一个 64 TB 的卷。
- 这个磁盘扩展 API 调用可能会导致磁盘短暂停滞。请确保在负载下进行测试，以确保不会对用户产生不利影响。
摘要
如果你在成千上万家在公共云中运行的公司之一工作，当涉及如何运行你的数据库时，你有很多选择。作为数据库工程师，你将被问及要使用哪种托管解决方案，是否要完全使用托管关系数据库解决方案，以及每种选择的权衡是什么。在这些讨论中最重要的是要记住，没有免费的午餐。你的每个选择都伴随着一系列的权衡。你可以做的最有用的事情是将这些权衡框定在你的业务运营方式和成熟阶段的背景下，以帮助指导你的组织朝着最合适的方向发展。我们希望这一章能帮助你在这些讨论中具备比较手中权衡和公司需求的能力。
¹ 如果你真的想了解那个架构的细节，我们强烈推荐阅读 2017 年 Aurora 团队发表的《SIGMOD 论文》。
² 变更数据捕获是数据架构中用于确定数据何时发生变化并在域和系统之间传输该变化的设计模式。关于这方面的更多阅读，我们强烈推荐马丁·克莱普曼（O’Reilly）的《数据密集型应用设计》第十一章。
³ Cloud SQL 确实提供了自己的解决方案用于支持合规需求的审计日志记录。
⁴ 欲了解更多信息，请参阅 Cloud SQL 文档中的“最小化维护影响”。
⁵ 请注意，自定义机器类型可能比预定机器类型更昂贵。当在大量实例上工作时，选择大小时考虑成本是非常重要的。
⁶ 提醒一下，这些是innodb_flush_log_at_trx_commit=1和sync_binlog=1。
第十三章：与 MySQL 合规
数据库工程团队的角色引起了许多内部业务利益相关者的关注。正如我们已经介绍的，您不仅需要为性能和正常运行计划，还需要考虑基础设施成本、灾难恢复以及各种合规需求。
您的工作不仅限于在业务运行时管理这些数据。您还需要帮助企业保护数据并为法律要求或对业务至关重要的监管认证进行认证。您必须了解实现这些需求的业务目标，并将这些要求包含在所有数据架构设计中，包括如何自动化运营任务、管理访问权限以及将管理任务转换为自动化任务的代码。
本章涵盖了企业可能追求的不同类型的合规认证以及各种特定于数据库的关注点。我们帮助解释如何为不同的合规需求设计，并讨论访问日志记录如何成为填补合规要求的关键部分。最后，我们涵盖了数据主权作为各类企业数据架构实践中新兴关注点。
警告
本章不旨在为您提供法律建议。我们旨在帮助您在运行大量数据库时管理合规需求，以及如何从早期开始设计合规。在寻求如何正确履行特定控制的建议时，您应始终与公司的法律团队咨询。
什么是合规？
治理、风险管理和合规（GRC）是指导企业如何评估和优先考虑其资产风险以及如何遵守管理其产品所使用的个人或健康数据处理和传输的法律的原则、流程和法律。早期初创企业通常不具备许多合规需求，因为他们在找到产品市场契合度时。然而，随着业务的发展，您将开始遇到许多法规。有些法规需要适用于企业所有数据，而有些可以适用于特定部分。
在合规背景下经常使用的一个术语是控制。控制是公司内部定义和实践的过程和规则，旨在减少不希望的风险结果的机会。
让我们介绍一些您应该了解的合规法规。稍后，我们将介绍可以帮助更轻松满足这些各种要求的架构变更。
服务组织控制第 2 型
服务组织控制第 2 型（SOC 2）是一组合规控制，服务组织可以用来报告与安全、可用性、处理完整性、机密性和隐私相关的实践。寻求获得 SOC 2 认证的组织中的数据库工程师需要建立良好的数据库变更管理、备份和恢复程序以及管理数据库实例访问权限的实践。
萨班斯-奥克斯法案
2002 年萨班斯-奥克斯法案（SOX）是一项所有成为上市公司的公司都必须遵守的法案。它旨在通过提高根据证券法规定向投资者披露的公司披露的准确性和可靠性来保护投资者，并为其他目的。对于一个工程组织，SOX 职责要求证明包含影响收入的数据的数据库只能被有需要的人访问，并且对这些数据的任何更改都已记录，并且更改有记录的原因。
如果您是一家上市公司，SOX 控制 404 是一个您必须熟悉并履行的法律要求的控制。它旨在通过证据保证公司报告的财务状况得到数据访问和变更管理实践的支持，这些实践准确地将提供的服务归因于收取的收入，并为对此类数据的任何更改提供审计跟踪。
付款卡行业数据安全标准
付款卡行业数据安全标准（PCI DSS）是所有处理信用卡数据的金融机构必须遵守的标准。其目的是保护持卡人数据，防止泄露并用于欺诈交易。
作为数据库工程师，当涉及到 PCI-DSS 控制时，一个重要的方面是管理对持卡人数据的访问。这意味着您需要在架构中考虑该控制，以确保卡数据得到单独管理。我们将在本章后面讨论如何实现这一点，当我们讨论角色分离时。
健康保险可携带性和责任法案
1996 年的健康保险可携带性和责任法案（HIPAA）是一项旨在保护个人健康相关数据隐私的美国法规，当这些数据由医疗提供者、医疗计划或其业务伙伴收集和处理时适用。该法律适用于被定义为电子个人健康信息（ePHI）的数据。提供需要符合 HIPAA 合规性的产品的组织将需要他们的数据库工程师实施控制措施，如 ePHI 的访问控制、所有 ePHI 的加密以及每当访问 ePHI 时进行活动记录。
联邦风险和授权管理计划
对于在美国运营并希望与美国政府实体开展业务的公司，联邦风险和授权管理计划（FedRAMP）是联邦政府提供的认证，使企业有资格成为联邦实体的云服务提供商。这是一系列要求的标准，使得符合条件的企业有资格接待联邦实体作为客户。这些标准包括配置管理、访问控制、安全评估以及对数据访问和更改的审计。
通用数据保护条例
《通用数据保护条例》（GDPR）是欧盟于 2016 年颁布的一项法规，旨在规范个人可识别信息在欧盟人员中的存储和管理方式，无论数据处理实体的总部在何处。它引入了管理数据隐私的第一步，例如在收集私人数据之前要求同意、设定跨处理器组织对该私人数据的访问限制，并为个人提供法律途径，要求任何可能通过其在线活动收集其数据的数据处理器的系统中清除其数据。这被称为个人的“被遗忘权”。
施雷姆斯 II
2020 年，欧盟与 Facebook 的爱尔兰实体之间的案件由欧盟司法法院裁定。这一裁决，通常被称为施雷姆斯 II，对所有在欧盟运营并收集欧盟人数据的美国公司产生了广泛影响。
隐私盾是美国公司多年来在欧盟运营的法律基础。施雷姆斯裁决宣布，当美国公司实体在欧盟收集欧盟人的数据时，隐私盾不足以保护欧盟人的隐私。在取消的核心是欧盟司法法院裁定，隐私盾不足以保证欧盟人不会通过美国法律手段（即使用 1978 年《外国情报监视法案》提供的机制，或 FISA）被美国政府监视，因此，由美国实体收集的欧盟人的个人可识别数据必须留在欧盟，不得跨越到美国资产或被美国人访问。
与 GDPR 最初版本相比，该裁决使得数据架构的推理变得更加复杂。由于这项裁决是最近才做出的，执法仍然是一个未知的数量。这种情况让每家企业决定其收集和处理的数据有多少在范围内，以及以何种方式。可以肯定的是，如果您有当前或未来的欧洲客户，Schrems II 将会针对您运行的应用程序和数据基础设施。
为合规控制构建
正如您所看到的，企业的法规合规世界，以及由此产生的企业用于运营的数据，是庞大的，控制措施可能因每项法律的目标或您的企业所需的认证而有所不同。好消息是，同样的工作可以涵盖多个控制措施，从而实现效率和更一致的实践，管理基础设施时。然而，您需要了解哪些控制措施对业务是必需的，以及出于何种目的。一旦您的公司发展到需要开始实施这些法规合规控制的规模，您将成为向不同类型的审计员提供合规证据的人。了解每项控制措施的目的将有助于提供正确类型的证据，使��计更加容易。
提示
为合规性构建是一个持续的过程，不能在需要时轻松“添加”。本章中提出的许多架构建议（角色分离、跟踪变更等）是您在公司过了“仍在寻找市场适应性”阶段后应该考虑和倡导的事项。这些实践将使您的业务在合规性真正成为一个需求而不仅仅是“好有的”时，为成功打下基础。
机密管理
在讨论如何管理机密之前，让我们首先明确您基础设施中可能属于该定义的事物：
- 应用程序与数据库交互的密码字符串
- 供支持人员/运营人员管理数据库实例的密码字符串
- 可以访问/修改数据的 API 令牌
- SSH 私钥
- 证书密钥
您组织中需要的一个核心能力是以安全和独立的方式管理机密，而不是与配置管理混为一谈。您需要一种交付和轮换敏感数据（如数据库访问凭据）的方式，无论是供应用程序还是团队使用，用于报告目的。
如果您在云环境中运行应用程序和数据库，我们强烈建议您在考虑构建自己的解决方案之前，先了解该云服务提供商的首选机密管理解决方案。您需要的是至少提供符合国家标准与技术研究所（NIST）标准可接受级别的加密，因为这是许多法规（包括 HIPAA 和 FedRAMP）所要求的。
如果您的云服务提供商没有一个可接受的机密管理解决方案，您可能需要自行托管。这可能是您的组织的一项新尝试，需要比本书所涵盖的更广泛的努力。
无论您使用托管解决方案还是最终需要自行运行，都要意识到这种机密管理解决方案给您的架构带来的复杂性。这种解决方案的目标是管理机密，而不是成为产品的单点故障。提前与您的法律团队和安全组织明确讨论解决方案可用时会发生什么的权衡将会很有帮助。关于缓存哪些机密以及以何种方式缓存的明确对话将有助于避免后期期望不一致。
通常，公司在早期发展阶段基于便利性做出的决定需要在计划合规控制之前进行调整。您应该准备向领导层解释为什么在改善安全姿势和降低风险的背景下这项工作很重要。
不要共享用户
不要跨服务共享数据库凭据。如果您的数据库意外泄漏，现在必须评估应用程序堆栈和流程中有多少部分需要获取新的数据库凭据对，这种决策的效果将成倍增长。作为数据库工程师，加入一家初创公司是很常见的，人们通常会采取看似方便的捷径，“所有代码都使用相同的对来访问数据库。” 相信我们：这是一种非常昂贵的捷径，如果您限制每个数据库用户的访问权限仅限于其所需的服务，您的未来自己会感谢您。
现在我们已经介绍了这个基本但至关重要的基本实践，让我们谈谈在选择存储数据库凭据或秘密的解决方案时需要考虑的事项。
不要在代码存储库中检查生产数据库凭据
这可能看起来很明显，但我们在许多大大小小公司的安全事件报告中仍然看到这种情况发生。保持谦卑的心态很重要，不要假设这种错误在您的组织中不太可能发生。信任但验证的方法将在很大程度上有助于防止未来的痛苦。在合并拉取请求之前扫描代码存储库中的潜在秘密字符串是一种常见做法（也是像 GitHub 这样的托管存储库服务可以为您执行的操作）。如果您的组织尚未考虑这一点，您可能需要成为这种需求的倡导者。请记住，合规性和安全性对整个组织都是必需的，尽管并非所有事情都可以或应该由数据库团队完成，但您是整个工程组织讨论这些优先事项的利益相关者之一。
这些实践对于正确开始合规性和安全姿势至关重要。它们将使我们在使用秘密管理时即将涵盖的一些操作变得更加简单，并且在有必要进行紧急更改时将进一步降低业务风险。
让我们谈谈在选择秘密管理解决方案时的权衡。
选择一个秘密管理解决方案
选择一个秘密管理解决方案将取决于您运行的环境以及最容易与数据库和应用程序堆栈集成的内容。在方便性和满足所有需求之间总会存在权衡。因此，您需要明确向所有利益相关者（其中一些不是工程师）说明限制是什么，可用性或弹性的权衡是什么。在检查您的云（或私有）基础设施可以提供的内容时，您应考虑以下一些权衡：
空间限制
许多由云提供的秘密管理解决方案对秘密的长度做出了假设，这可能会导致意外惊喜，如果您想存储比数据库用户和密码对更长的内容。如果您的合规控制要求将更长的文本字符串（例如 SSH 密钥或 SSL 的私有证书）也视为秘密，您应该查看您可以在给定密钥上存储的最大大小。一些组织后来会遇到的雷区之一是，随着秘密足迹的增长，需要一个新的不同的秘密管理解决方案来容纳更长的秘密。现在他们必须处理迁移（可能会影响正常运行时间）或管理工具和与两个单独的秘密解决方案集成的复杂性。
秘密轮换
如果你在公共云中运行并且可以使用他们提供的托管密钥管理解决方案，那么对你来说有个好消息：截至目前，所有三个主要的云服务提供商都提供了一些自动化轮换密钥的方法，以及版本控制，使得服务过渡到新密钥对你的服务更加无缝。然而，如果你选择的密钥管理解决方案不支持轮换密钥，那么你需要计划如何进行这项工作，无论是作为计划更改（例如，你可能有一个要求数据库凭据定期轮换的控制）还是作为紧急变更（例如，有人意外地在公共存储库中检查了数据库密码）。如何在不影响正在运行的应用程序的情况下进行这项工作？这在很大程度上取决于你如何向正在运行的应用程序传递配置更改以及你的部署流水线的运作方式。这是如何编排的一般想法。这个变更是一个部署。即使你的应用程序将数据库凭据作为配置行访问，你仍然需要将这个配置更改传播到你的所有设备，并通常还需要编排一个重新启动，而不影响整个服务的可用性。
区域可用性
要考虑你的密钥管理解决方案不仅用于存储密钥，还用于传递密钥。如果你要避免像在代码中存储密钥这样的已知不良做法，你需要让你的应用程序能够在运行时检索它需要处理请求的密钥。这意味着你现在必须考虑如何检索这些密钥，如果你的应用程序无法访问密钥管理服务会发生什么，以及这种新依赖引入了什么故障模式。如果你负责需要在许多地理区域运行的应用程序，你的密钥管理解决方案的区域能力就成为另一个需要考虑的因素。你的云提供商的解决方案是否会自动将密钥复制到其他区域？还是你必须构建这种能力？
角色和数据的分离
这些监管法律的一个重要目标是根据数据泄露的风险将数据分开，无论是对企业还是对其客户。这就是最小权限的概念，无论是对人类访问还是对应用程序代码访问。这种分离允许根据数据内容和相关风险进行更合适的控制和变更跟踪。
为合规性原因进行分片
可能会迫使特定数据集分开到专用集群的一个因素是具有非常不同控制要求的不同合规性要求。比如说，你是一个市场传播提供商，正在创建一个侧重于医疗技术的新产品。目前正在使用的数据与健康无关，并且不受多项法律要求约束。一旦企业进入健康技术领域，你现在就有了一部分客户及其数据，你的公司承担了作为个人健康信息（PHI）处理者的法律责任。在这种情况下，最好从一开始就在专用数据存储中开发新产品，这样你就可以更适当地应用 HIPAA 合规性控制，而不会给现有数据集及其依赖的应用程序增加不必要的负担。
分开数据库用户
随着您的产品变得更加复杂，支持其的技术堆栈也随之增长，您将开始拥有多个具有数据访问权限的应用程序。在组织早期就开始良好控制数据访问权限非常重要，不要在多个代码库之间共享相同的数据库访问凭据。安全事件和凭据意外泄露是发生在各种公司的事件，无论规模大小，当这些事件发生时，您将受益于泄露的秘密影响已知且隔离的业务操作范围，因为您在匆忙更换该秘密时。
变更跟踪
许多合规法规都涉及跟踪变更的控制：影响财务报告的数据子集的变更，生成发票的系统的变更，以及这些变更如何被审查、测试和跟踪。这种合规控制首次显而易见的地方之一是数据库。随着您为扩大合规责任的业务工作，像“如何审查、应用和跟踪生产中的模式更改”这样的流程需要比简单地“工程师登录生产源节点并进行更改”更严格和更有计划。如果您通过与内部审计团队或合规团队一起规划如何处理审计来做好准备，这将减轻很多负担。
这里的目标是避免年度审计成为一个重大干扰事件，团队在为审计团队收集证据而忙碌。相反，如果您对这些正常业务操作的工作方式进行一些更改，您可以获得“内置”证据，这样收集和用于审计的证据就会简单得多。您将在本节中看到一个关于从所有方面生成结构化日志的重复主题。这是有意的。这在很大程度上有助于以相同方式跟踪各种变更，这种一致性有助于企业以更少的干扰实现其审计需求。您可以看到这一切是如何在图 13-1 中结合在一起的。
图 13-1。不同操作任务的示例，所有任务都将结构化日志发送到一个地方，使审计更容易
让我们看看数据库系统的不同变更类型以及如何为其自动化合规跟踪。
数据访问日志记录
许多合规控制要求您保留��特定数据集的更改或访问的日志。这可以用于跟踪财务数据的更改，也可以用于 PCI 或 HIPAA 等法规，其中数据足够敏感，所有访问都需要被跟踪。
您可以直接在数据库级别解决这个需求，通过利用Percona 的审计日志插件（如果您使用 Percona 的分支）或等效的MySQL 企业审计插件（如果您使用 MySQL 社区服务器）。这样做的好处是，现在您可以在数据更改之前的最后一跳跟踪变更，特别是如果您处于一个数据库可以通过多个路径进行更改的环境中。
高性能 MySQL 第四版（GPT 重译）（四）(4)https://developer.aliyun.com/article/1484358
