使用组复制的高可用性解决方案¶

每个体系结构和部署都依赖于客户对高可用性和估计使用水平的需求和应用程序需求。例如，使用高读或高写应用程序，或两者兼有，可用性为99.999%。

本指南给出体系结构部署建议以及提供高可用性并假定使用高读/写应用程序(每秒查询20K或更多)的解决方案的技术概述。它还提供了逐步部署指南。

此解决方案假设使用雷竞技下载官网用于MySQL的Percona服务器基于Percona发行版的MySQL的部署变体雷竞技下载官网组复制。

高可用性概述¶

如何衡量可用性，在什么时候它会变成“高”可用性?

一般来说，可用性的测量是通过建立一个测量时间框架并将其除以可用的时间来完成的。这个比率很少为1，这等于100%的可用性。如果一个解决方案至少有99%或“两个9”可用，就被认为是高可用的。

下表提供了每个高可用性级别的停机时间计算:

高可用性是如何实现的?¶

实现高可用性有三个关键组件:

• 基础设施—这是数据库系统运行所依赖的物理或虚拟硬件。如果没有足够的基础设施(虚拟机、网络等)，就不可能有高可用性。最简单的例子是:没有办法使单个服务器高度可用。

• 拓扑管理-这是专门与数据库相关的软件管理，并管理其在发生故障时保持一致性的能力。许多集群或同步复制解决方案都提供了这种开箱即用的功能。然而，异步复制是由额外的软件处理的。

• 连接管理-这是专门与数据库的网络和连接方面相关的软件管理。集群解决方案通常与连接管理器捆绑在一起。但是，在异步集群中，为了实现高可用性，必须部署连接管理器。

该解决方案基于紧密耦合的数据库集群。当与Group Replication设置结合使用时，它提供了99.995%的高可用性级别group_replication_consistency =后。

故障¶

需要重新启动的数据库故障或配置更改不应该影响数据库基础设施的稳定性，如果规划和架构正确的话。故障转移是稳定性策略中不可分割的一部分，将可用性和正常运行时间的业务需求与故障转移方法结合起来至关重要。

以下是数据库环境中可能发生的三种主要类型的故障转移:

• 故障转移计划。这是预先安排的或定期发生的故障转移。计划中的故障转移可能有很多原因，包括打补丁、大数据操作、退役现有基础设施，或者只是为了测试故障转移策略。

• 计划外故障转移。当数据库意外地失去响应或出现不稳定时，就会发生这种情况。计划外故障转移还可能包括不属于计划故障转移节奏或调度参数的紧急更改。计划外故障转移通常被认为是高风险操作，因为压力大，数据损坏或数据碎片的可能性大。

• 区域故障切换或容灾故障切换。在假定额外的数据库基础设施立即可用并处于可用状态的情况下，计划外故障转移仍然有效。但是，在区域或DR故障转移中，假定存在大规模基础设施中断，需要业务将其操作移出当前可用区域。

维护窗口¶

大维护vs小维护¶

虽然一开始可能不明显，但并非所有维护活动都是相同的，并且没有相同的依赖关系。最好将需要停机时间或故障转移的维护与不影响这些重要稳定性指标的维护分开。在定义这些维护依赖关系时，实际的维护过程可能会发生变化，从而允许不同的节奏。

不中断业务维护¶

通过滚动重启和使用适当的版本升级，可以在不中断服务的情况下覆盖主要和次要维护。

正常运行时间¶

在提到数据库稳定性时，正常运行时间可能是稳定性的最大指标，并且通常是数据库环境不稳定的最明显症状。正常运行时间由三个关键组件组成，与通常的看法相反，它是基于当数据库软件无法接收传入请求(而不是保持接收错误请求的能力)时所发生的情况。

正常运行时间组件为:

• 恢复时间目标(RTO)

RTO可以用一个简单的问题来描述:“业务可以维持数据库中断多长时间?”一旦业务与最小可行恢复时间目标保持一致，就可以更直接地计划和投资满足该需求所需的基础设施。重要的是要承认，虽然每个人都希望100%的正常运行时间，但需要有符合业务需求而不是技术需求的现实期望。

• 恢复点目标(RPO)

数据库基础设施的恢复点和恢复时间之间有很大的区别。数据库可以是可用的，但不能恢复到它变得不可用时的确切状态。这就是恢复点的作用所在。这里要问的问题是“在数据库中断期间业务会损失多少数据?”所有企业在这方面都有自己的要求，但永远都要避免任何数据丢失。但这是在最坏的情况下设定的，即可能丢失多少数据以及业务保持继续运行的能力。

• 灾难恢复

RTO和RPO对于计划外的中断或基础设施的小规模故障非常有用。灾难恢复是一种大规模的停机，并不仅限于数据库基础设施。在假定主可用分区中所有资源都完全不可用的情况下，重新启动操作的能力如何?这里的假设是，不存在符合业务需求的可行恢复点或时间。虽然基于可用的基础设施、备份策略和技术堆栈，每个灾难恢复场景都是唯一的，但任何场景都有一些共同的线程。

所描述的解决方案帮助提高正常运行时间。它将帮助您显著降低RPO和RTO。由于采用紧密耦合的集群解决方案，单个节点的故障不会导致业务中断。

增加节点数量也会提高集群的弹性，公式如下:

F = (n -1) / 2

地点:

• F允许失败的数量是多少

• N集群中的节点数量。

例子¶

• 在5个节点的集群中，F =(5 - 1)/2 = 2。集群最多支持2个故障。

• 在4个节点的集群中，F =(4 - 1)/2 = 1。集群最多支持1个故障。

此解决方案还支持更严格的备份策略，将一个节点专门用于备份周期，这将有助于保持较低的RPO。

如前所述，此解决方案默认不包括灾难恢复。它需要一个额外的复制设置和控制器。