MySQL 分布式集群探索-MGR-分布式恢复

Posted 2021-08-30 shark_西瓜甜

分布式恢复

17.9.5.1分布式恢复基础

17.9.5.2从时间点恢复

17.9.5.3视图更改

17.9.5.4分布式恢复的使用建议和限制

本节描述了加入组的成员与组中其余服务器的连接过程，称为分布式恢复。分布式恢复可以概括为一个过程，通过该过程，服务器可以从组中获取丢失的事务，这样它就可以加入处理了与其他组成员相同的事务集的组。

分布式恢复基础知识

每当成员加入复制组时，它都会连接到现有成员以执行状态传输。加入组的服务器传输加入组之前在组中发生的所有事务，这些事务由现有成员（称为施主）提供。接下来，加入组的服务器将应用此状态传输过程中在组中发生的事务。当加入组的服务器赶上组中的其余服务器时，它将开始正常加入组。这个过程称为分布式恢复。

第一阶段

在第一阶段，加入组的服务器选择组上的一个联机服务器作为缺少该组的状态的提供者。捐赠者负责向加入组的服务器提供其在加入组之前丢失的所有数据。这是通过依赖一个标准的异步复制通道来实现的，该通道建立在施主和加入组的服务器之间，请参见第16.2.2节“复制通道”。通过此复制通道，将复制施主的二进制日志，直到加入组的服务器成为组的一部分时发生视图更改为止。加入组的服务器在接收捐赠方的二进制日志时应用这些日志。

在复制二进制日志时，加入组的服务器还缓存组内交换的每个事务。换言之，它正在侦听在加入组后以及应用来自捐赠者的缺失状态时发生的事务。当第一阶段结束并且到施主的复制通道关闭时，加入组的服务器随后开始第二阶段：追赶。

第二阶段

在此阶段，加入组的服务器继续执行缓存的事务。当排队等待执行的事务数最终达到零时，该成员被声明为联机。

恢复力

当加入组的服务器从中获取二进制日志时，恢复过程可以承受施主失败。在这种情况下，无论何时在阶段1中某个施主出现故障，加入组的服务器都会故障切换到新的施主并从该施主恢复。当这种情况发生时，加入组的服务器将关闭与加入组的失败服务器的连接，并打开与新捐赠者的连接。这是自动发生的。

从某个时间点恢复过来

为了将加入组的服务器与施主同步到特定时间点，加入组的服务器和施主使用mysql全局事务标识符（GTID）机制。请参阅第16.1.3节，“使用全局事务标识符的复制”。但是，GTID仅提供了一种方法来实现加入组的服务器缺少哪些事务，它们无助于标记加入组的服务器必须赶上的特定时间点，也无助于传递认证信息。这是二进制日志视图标记的工作，它标记二进制日志流中的视图更改，还包含其他元数据信息，为加入组的服务器提供丢失的认证相关数据。

视图和视图更改

要解释视图更改标记的概念，了解视图和视图更改是什么很重要。

视图对应于积极参与当前配置的一组成员，换句话说，在特定的时间点。它们在系统中是正确的和在线的。

当对组配置进行修改（如成员加入或离开）时，会发生视图更改。任何组成员资格更改都会导致在同一逻辑时间点向所有成员传达独立的视图更改。

视图标识符唯一标识视图。每当视图发生更改时，都会生成该视图

在组通信层，视图更改及其关联的视图ID是成员加入前后交换的数据之间的边界。这个概念是通过一个新的二进制日志事件实现的：“查看更改日志事件”。因此，视图id也成为在组成员身份发生更改之前和之后传输的事务的标记。

视图标识符本身由两部分组成：（i）随机生成的一部分和（ii）单调递增的整数。第一个零件在创建组时生成，并且在组中至少有一个成员时保持不变。第二部分在每次视图更改时递增。

组成视图id的这对异构对的原因是，每当成员加入或离开时，以及当所有成员离开组且没有关于组所在视图的信息时，都需要明确地标记组更改。事实上，仅使用单调递增的标识符可能会导致在完全组关闭后重用相同的id，从而破坏恢复所依赖的二进制日志数据标记的唯一性。总而言之，第一部分标识组从一开始就启动的时间，增量部分标识组从该时间点开始更改的时间。

视图更改

本节介绍控制如何将视图更改标识符合并到二进制日志事件中并写入日志的过程，采取以下步骤：

开始：稳定组

所有服务器都处于联机状态，并处理来自该组的传入事务。有些服务器在复制事务方面可能有点落后，但最终会趋同。该组充当一个分布式和复制数据库。

集群视图稳定:

视图更改：成员加入

每当新成员加入组并因此执行视图更改时，每个联机服务器都会将视图更改日志事件排队等待执行。这是排队的，因为在视图更改之前，可以在要应用的服务器上将多个事务排队，因此，这些事务属于旧视图。将视图更改事件排在它们之后可以确保正确标记发生这种情况的时间。

同时，加入组的服务器通过视图抽象从成员服务声明的在线服务器列表中选择捐赠者。一个成员在视图4上加入，在线成员将视图更改事件写入二进制日志。

图 构件连接

国家转移：迎头赶上

一旦加入组的服务器选择了组中的哪台服务器作为施主，就会在这两台服务器之间建立新的异步复制连接，并开始状态传输（阶段1）。在加入组的applier线程的服务器处理与加入组的服务器进入组时触发的视图更改相对应的视图更改日志事件之前，与施主的交互将继续。换句话说，加入组的服务器从供体复制，直到它到达具有视图标识符的标记，该视图标识符与它已经在其中的视图标记相匹配。

图 状态转移：追赶

由于视图标识符在同一逻辑时间传输给组中的所有成员，因此加入组的服务器知道应该停止复制哪个视图标识符。这避免了复杂的GTID集计算，因为视图id清楚地标记了属于每个组视图的数据。

加入组的服务器在从施主进行复制的同时，也在缓存来自组的传入事务。最终，它会停止从施主进行复制，并切换到应用缓存的复制。

图17.13排队事务

完成：赶上

当加入组的服务器识别到具有预期视图标识符的视图更改日志事件时，与施主的连接将终止，并开始应用缓存的事务。需要了解的重要一点是最终恢复程序。尽管它在二进制日志中充当标记，分隔视图更改，但视图更改日志事件也起着另一个作用。当加入组的服务器进入组时，它传递所有服务器感知到的认证信息，换句话说，最后一次视图更改。如果没有它，加入组的服务器将不具备能够验证（检测冲突）后续事务的必要信息。

追赶的持续时间（阶段2）不是确定的，因为它取决于工作负载和向组传入事务的速率。此过程完全联机，加入组的服务器在追赶时不会阻止组中的任何其他服务器。因此，当加入组的服务器移动到第2阶段时，其落后的事务数可能会因此而变化，从而根据工作负载增加或减少。

当加入组的服务器达到零排队事务且其存储的数据等于其他成员时，其公共状态将更改为联机。

图17.14在线实例

分布式恢复的使用建议和限制

分布式恢复确实有一些局限性。它基于经典的异步复制，因此，如果加入组的服务器根本没有配置，或者配置了非常旧的备份映像，则速度可能会很慢。这意味着，如果要传输的数据在第1阶段太大，服务器可能需要很长时间才能恢复。因此，建议在向组中添加服务器之前，应为其提供组中已存在的服务器的最近快照。这将最小化阶段1的长度并减少对施主服务器的影响，因为它必须保存和传输更少的二进制日志。

警告

建议在将服务器添加到组之前，先对其进行设置。这样，就可以最大限度地减少在恢复步骤上花费的时间。

可观测性

组复制插件内置了许多自动化功能。尽管如此，您有时可能需要了解幕后发生的事情。这就是组复制和性能模式的检测变得重要的地方。系统的整个状态（包括视图、冲突统计和服务状态）可以通过performance_schema表查询。复制协议的分布式特性以及服务器实例在事务和元数据上一致并因此同步的事实使得检查组的状态变得更简单。例如，您可以连接到组中的单个服务器，并通过对组复制相关的性能架构表发出select语句来获取本地和全局信息。有关更多信息，请参阅“监控组复制”。