本文档介绍了多种可确保 Google Cloud 上 MySQL 部署的高可用性 (HA) 的架构。HA 用于衡量系统对底层基础架构故障的响应弹性。在本文档中，HA 解决了 MySQL 集群在单个云地区内的可用性。
本文档适合想要学习如何通过延长整体系统正常运行时间来提高 MySQL 数据层可靠性数据库的管理员、云架构师和 DevOps 工程师。如果您在 Compute Engine 上运行 MySQL，则本文档适合您使用。如果您使用 Cloud SQL for MySQL，则本文档不适合您使用。
对于需要永久性状态来处理请求或事务的系统或应用，必须提供数据持久层以成功处理数据查询或变更请求。如果应用必须与数据层进行交互以处理请求，则数据层的任何停机时间都会阻止应用执行必要的任务。
根据系统服务等级目标 (SLO)，您可能需要一个可提供更高可用性级别的架构拓扑。您可以通过多种方式来实现 HA，但一般而言，您可以预配冗余基础架构，以便可以快速访问您的应用。
本文档讨论以下主题：
- 定义术语，以帮助您理解 HA 数据库概念。
- 帮助您了解 HA MySQL 拓扑的几个选项。
- 提供上下文信息来帮助您了解每个选项中需要考虑的内容。
术语
有多个术语和概念都符合业界标准，并且有助于理解超出本文档范围的用途。
复制。以可靠的方式捕获和记录写入事务（INSERT、UPDATE 或 DELETE），然后依序应用于拓扑中所有数据库节点的过程。
源节点。 所有数据库写入都必须定向到源节点。您可以通过源节点读取最新状态的持久化数据。
副本节点。源数据库节点的在线副本。更改会近乎同步地从源节点复制到副本节点。您可以从副本节点中读取数据，从而了解到由于复制延迟，数据可能会略微延迟。
复制延迟。表示将事务应用到副本节点的时间与将事务应用到源节点的时间之间的差值。
正常运行时间。资源运行且能够为请求提供响应的时间百分比。
故障检测。发现已发生基础架构故障的过程。
故障切换。将备份或备用基础架构（在本例中为副本节点）升级为主要基础架构的过程。换句话说，在故障切换期间，副本节点会成为源节点。
目标恢复时间 (RTO)。从业务角度来看，表示完成数据层故障切换过程可接受的时长（所用的实际时间）。
回退。进行故障切换后恢复之前的源节点的过程。
自我修复。系统能够解决问题，无需人工操作员进行外部操作。
网络分区。拓扑中的两个节点（例如源节点和副本节点）无法通过网络相互通信时的条件。
脑裂。当两个节点同时认为自己是源节点时，就会出现此状况。
节点组。一组用于提供服务的计算资源任务。在本文档中，该服务是数据持久层。
见证或仲裁节点。一个单独的计算资源，帮助节点组确定在脑裂条件下要执行的操作。
来源选举或领导者选举。 一组对等感知节点（包括见证节点）确定哪个节点应作为源节点的过程。
节点组。一组用于提供服务的计算资源任务。在本文档中，该服务是数据持久层。
热备用。代表另一个源节点的接近副本的节点，并且可以以最短的停机时间成为新的源节点。
何时考虑使用 HA 架构
HA 架构可更好地保护数据层不停机。了解能够承受的停机时间以及各种架构各自的利弊，共同选择适合您业务使用场景的选项。
如果要增加数据层正常运行时间来满足工作负载和服务的可靠性要求，请使用 HA 拓扑。对于能够承受一段停机时间的环境，使用 HA 拓扑会产生不必要的费用并提高复杂性。例如，开发环境或测试环境通常不需要较高的数据库层可用性。
考虑您的 HA 要求
为了实现 HA，计算基础架构和存储费用预计至少是原来的双倍，因此需要考虑费用。评估可能的 MySQL HA 选项时，请考虑以下问题：
- 哪些服务或客户依赖于您的数据层？
- 您的运营预算是多少？
- 在数据持久层发生停机时，企业需要付出什么代价？
- 此流程需要的自动化程度是多少？
- 您希望达到的可用性等级是 99.5%、99.9% 还是 99.99%？
- 您需要以多快的速度进行故障切换？您的 RTO 是什么？
以下调用会产生恢复时间，在建立 RTO 时应加以考虑：
- 检测中断情况
- 辅助虚拟机 (VM) 实例就绪
- 存储故障切换
- 数据库恢复时间
- 应用恢复时间
MySQL HA 架构
在最基本的层级，数据层中的 HA 包含以下内容：
- 用于确定已发生源节点故障的一种机制。
- 在副本节点提升为源节点的情况下执行故障切换的过程。
- 更改查询路由以使应用请求到达新的源节点的过程。
- （可选）使用源节点和副本节点回退到原始拓扑的方法。
本文档讨论以下三个 HA 架构：
除了基础架构故障之外，在发生区域服务中断的情况下（不太可能发生），这些架构均有助于最大限度地减少停机时间。您可以将这些架构与域名系统 (DNS) 更改结合使用，以提供多地区 HA 来防止发生地区服务中断，但本主题不在本文档的讨论范围内。
使用地区永久性磁盘实现 HA
数据层级中的 HA 始终依赖于某类型的数据复制。最简单的复制是您无需管理的复制。
借助 Compute Engine 中的地区永久性磁盘存储选项，您可以预配一个块存储设备，以在一个地区的两个区域之间同步数据复制。地区永久性磁盘为在 Compute Engine 中实现 HA 服务提供了坚实的基础组件。
下图展示了具有地区永久性磁盘的 HA 架构。
如果您的源节点虚拟机实例因基础架构故障或可用区服务中断而不可用，则您可以强制将区域永久性磁盘挂接到同一区域的备份区域中的虚拟机实例。
要执行此任务，您必须执行以下任一操作：
- 在可以使用共享区域永久性磁盘的备份区域中启动另一个虚拟机实例。
- 在备份区域中维护热备用虚拟机实例。热备用虚拟机实例是一个运行中的虚拟机实例，与您使用的实例完全相同。连接区域永久性磁盘后，您可以启动数据库引擎。
如果及时发现数据服务中断，强制挂接操作通常会在一分钟内完成，这意味着几分钟内即可达到 RTO。
如果您的业务可以承受检测和传达服务中断所需的额外停机时间，并且您需要手动执行故障切换，则无需自动执行该过程。
如果 RTO 容忍度较低，则您可以自动执行检测和故障切换过程。如果您自动执行此架构，则系统会变得更加复杂，因为您需 要考虑在故障切换和回退过程中存在的多个边缘用例。如需详细了解如何完全自动化实现此架构，请参阅 Cloud SQL 高可用性配置。
优点
由于下列特性，使用地区永久性磁盘实现 HA 具有很多优势：
- 此架构可针对多种故障模式提供并发保护：主区域服务器基础架构故障、单区域块存储性能下降或全区域服务中断。
- 您无需复制应用或数据库层，因为地区永久性磁盘提供连续且同步的块级别数据复制，其完全由 Google Cloud 管理。地区永久性磁盘会自动检测错误和运行缓慢的问题、切换复制模式，并同步仅复制到一个区域的数据。
- 如果主要区域出现存储问题，地区永久性磁盘会自动从辅助区域执行读取操作。此操作可能会导致读取操作的延迟时间增加，但您的应用可以继续运行，无需进行任何手动操作。
注意事项
此架构的限制与此拓扑的单个地区性质以及地区永久性磁盘的以下固有约束相关：
- 地区永久性磁盘只能装载到一个数据库。即使备用数据库虚拟机实例正在运行，该实例也不能用于执行数据库读取操作。
- 此架构背后的基础技术只允许在同一地区的各区域之间复制。 因此，单独使用此架构时，无法选择进行地区故障切换。
- 与区域永久性磁盘相比，地区永久性磁盘的写入吞吐量已减半。请确保吞吐量限制在您需要的承受范围内。
- 地区永久性磁盘的写入延迟时间略高于区域永久性磁盘。我们建议您测试工作负载，以验证写入性能是否满足您的要求。
- 在故障事件和生成的切换期间，您需要强制地区永久性磁盘挂接到备用区域虚拟机。强制挂接操作通常会在一分钟的时间内执行，因此您在评估 RTO 时必须考虑此时间。
- RTO 的估算值必须包括强制挂接地区永久性磁盘所需的时间和虚拟机文件系统检测热挂接磁盘的时间。
使用热备用和见证节点实现 HA
如果您希望自动进行故障切换，则需要使用不同的架构。一种方案是部署一组节点（至少两个数据库节点），配置数据库异步复制并启动见证节点，以帮助确保在源节点选举期间可以访问仲裁节点。
源数据库节点负责处理写入事务以及处理读取查询。数据库复制过程会将更改传输到在线热备用副本节点。
因为见证节点可以是小型虚拟机，所以它提供了一个费用低廉的机制，以确保大部分组节点都可供源节点选举使用。
组节点不断评估其他组节点的状态。这些状态检查每几秒钟使用的信号称为检测信号，因为它们用于评估其他组节点的运行状况。及时评估数据库节点健康状况非常重要，因为必须快速识别健康状况不佳的源数据库节点，以便可以启动热备用的故障切换。
节点组仲裁取决于为了让集群正常启动或继续运行而必须属于活跃集群成员的投票元素的数量。要使节点组在源数据库节点选举中实现仲裁，组中的大多数节点都必须参与。为了防止出现脑裂状况，大多数节点都必须参与这一要求可以确保在网络分区的情况下，两个投票组不能同时有足够的节点进行投票。
一个组中大部分节点都包含 (n +1)/ 2 个节点，其中 n 是该组中的节点总数。例如，如果一个组中有三个节点，则至少有两个节点必须用于源节点选举。如果一个组中有五个节点，则至少需要三个节点。
组采用奇数个节点划分大小，以防出现网络分区而导致节点组的子组之间无法进行通信。即使该组均匀划分大小，仍有较大的机会出现两个子组大小小于大部分子组的情况。如果组大小为奇数，则很可能出现其中一个子组包含大部分节点或没有任何组包含大部分节点的情况。
下图将运行状况良好的节点组与性能下降的节点组进行比较。
该图显示了两个节点组 - 一个正常运行的节点组和一个性能下降的节点组。功能全面且运行状况良好的节点组包含三个组成员。在此状态下，源数据库节点和副本数据库节点提供预期用途。此节点组的必要仲裁是两个节点。
性能下降的节点组显示由于基础架构故障而不再发送源节点检测信号的状态。源数据库节点实例故障或源节点仍在运行，都可能导致出现此状态。或者，网络分区可能会阻止源节点与组中的其他节点之间进行通信。
无论哪种原因，结果都是副本和见证者确定源节点运行状况不再良好。此时，组中的大部分节点用于处理源节点选举，确定热备用节点应成为源节点，并启动故障切换。
下图显示了见证节点节点架构中的数据库事务、复制和检测流程。
在上图中，此 HA 架构依赖于热备用副本节点，以便在进行故障切换时快速开始处理生产写入。故障切换的机制（例如，源节点升级）由组中的数据库节点执行。
要实现此架构，请考虑以下两个项目：
- MySQL 组复制是一个开源的 MySQL 插件，有助于创建 HA 拓扑。
- Galera 集群和 Percona XtraDB 集群是可以实现高可用性的其他开源选项。
优点
热备用架构几乎没有移动组件，易于部署，并且具有以下几项优势：
- 只有一个额外的费用低廉的见证节点，提供完全自动的故障切换。
- 这种架构可以解决长期基础架构故障，如同处理暂时性故障（例如，由于系统重新启动）一样轻松。
- 有一些关联的复制延迟时间，提供多地区高可用性。
注意事项
故障切换是自动进行的，但以下操作任务仍然存在：
- 您需要管理源节点和副本节点之间的复制。
- 您需要管理见证节点。
- 您必须使用负载平衡器来部署和管理连接路由。
- 如果不更改应用逻辑（超出本文档的讨论范围），您无法直接读取副本节点。
使用 Orchestrator 和 ProxySQL 实现 HA
如果您组合了开源组件、Orchestrator 和 ProxySQL，则您的架构可以检测服务中断情况，并自动将流量从困扰源节点故障切换到新升级的健康状况良好的副本节点。
此外，您可以采用透明方式将查询路由到相应的读取节点或读写节点，以提升处于稳定状态的数据层性能。
Orchestrator 是一个开源 MySQL 复制拓扑管理器和故障切换解决方案。借助该软件，您可以检测、查询和重构复杂的复制拓扑，并提供可靠的故障检测、智能恢复和升级功能。
ProxySQL 是一个适用于 MySQL 的开源、高性能和高可用性数据库协议识别代理。ProxySQL 可以扩充到成千上万个后端服务器上的数百万个连接。
下图显示了组合的 Orchestrator 和 ProxySQL 架构。
如上图所示，在此架构中，数据库绑定的流量由内部负载平衡器路由到冗余的 ProxySQL 实例。这些实例根据 ProxySQL 配置将流量路由到可写入或可读取的数据库实例。
Orchestrator 提供以下故障检测和恢复步骤：
- Orchestrator 确定源数据库节点不可用。
- 系统会查询所有副本节点，以提供关于源节点状态的另一种意见。
- 如果副本节点就源节点不可用这一点提供的评估不一致，则继续进行故障切换。
- 如拓扑定义，升级的节点在故障切换期间成为新的源节点。
- 故障切换完成后，Orchestrator 有助于确保根据拓扑预配正确数量的新复制节点。
区域 A 中的源数据库与备用区域中的数据库副本之间的持续复制功能使副本保持最新状态，并将任何写入内容路由到源节点。Orchestrator 通过持续发送检测信号来检查源数据库和副本数据库的运行状况。Orchestrator 应用状态保留在单独的 Cloud SQL 数据库中。如果需要在拓扑中进行更改，Orchestrator 还可以向数据库发送命令。
故障切换完成后，ProxySQL 会将流量适当地路由到新的源节点和副本节点。服务会继续使用负载平衡器的 IP 地址来访问数据层。虚拟 IP 地址会从较早的源节点无缝切换到新的源节点。
优点
架构组件和自动化服务具有以下优势：
- 此架构中使用的软件提供了各种可观测性功能，包括复制拓扑图和查询流量可见性。
- ProxySQL 和 Orchestrator 进行协调来提供自动副本升级和故障切换功能。
- 副本升级政策可以全面配置。与其他 HA 配置不同，在故障切换发生时，您可以选择将特定副本节点升级为源节点。
- 故障切换后，系统将根据拓扑以声明方式预配新副本。
- ProxySQL 具有补充性负载均衡优势，因为它可以根据配置的政策以透明方式将读写请求路由到相应的副本节点和源节点。
注意事项
该架构会增加运营职责并产生额外的托管费用，原因如下：
- 必须部署和维护 Orchestrator 和 ProxySQL。
- Orchestrator 需要单独的数据库来维护状态。
- 您需要同时设置 Orchestrator 和 ProxySQL 来实现 HA，这会增加配置和部署的复杂性。
此外，Orchestrator 不支持多源复制、不支持所有类型的并行复制，并且不能与 Galena 或 Percona XtraDB 等集群软件结合使用。如需详细了解当前限制，请参阅 Orchestrator 常见问题解答。
后续步骤
- 了解 Cloud SQL 高可用性配置。
- 详细了解使用地区永久性磁盘的高可用性选项。
- 查看 MySQL 组复制文档。
- 了解 Gerara 集群或相关的 Percona XtraDB 集群。
- 查看 Orchestrator 文档。
- 详细了解 ProxySQL。
- 探索有关 Google Cloud 的参考架构、图表和最佳做法。查看我们的 Cloud Architecture Center。