组复制常规操作-分布式恢复 | 全方位认识 MySQL 8 _分布式事务

作者罗小波 · 数据库技术专家
出品沃趣科技

文章插图
每当一个新加入或重新加入一个复制组时，对于新加入的，它必须要追平组中的最新数据，对于重新加入的，它必须要追平它脱离组之后的最新数据。这个追平最新数据的过程称为分布式恢复。
申请加入组的首先检查其组复制通道plier对应的中继日志，查看它已经从组中接收到了但尚未应用的任何事务。如果是重新加入组的，那么它可能在脱离组时存在着未应用完成的事务，在这种情况下，它将第一步应用这些事务，如果是新加入组的则不存在这种情况，所以在这一步没有任何东西需要应用。之后，申请加组的会与组中的现有成员建立连接进行状态传输。申请加入组的会从组中现有成员中（提供状态传输的组成员称为donor节点，接收状态传输的称为节点）传输在其加入组之前或者在其脱离组之后组中的所有事务数据。然后，申请加入组的将应用在状态传输过程中组内新事务写入的数据。当这个过程完成时，就表示申请加入组的已经赶上了组中其余成员中的数据，此时，新加入组的就会转换为状态，并开始正常地参与组中的各项工作。在分布式恢复期间，组复制使用如下方法的组合进行状态传输：在节点上执行START 语句后，组复制将自动选择这些方法的最佳组合进行状态传输。
为此，组复制会检查组中哪些现有成员适合作为donor节点，节点需要从donor节点获取多少事务，以及节点所需的事务在组中的所有成员的二进制日志中是否存在。如果节点与donor节点之间的事务差距很大，或者节点所需的某些事务在组中的所有成员的二进制日志中都不存在，则组复制将通过远程克隆操作执行分布式恢复。如果节点与donor节点之间的事务差距不大，或者没有安装克隆插件，则组复制直接使用donor节点的二进制日志进行状态传输。当节点追赶上组中的最新数据时，它将声明已经处于状态，并可以作为正常成员参与组中的各项工作，至此，分布式恢复完成。PS：如果节点与donor节点之间的事务差距很大，或者节点所需的某些事务在组中的所有成员的二进制日志中都不存在时，如果也未配置克隆功能，则，节点将加入组失败。4.3.1. 克隆用于分布式恢复 MySQL 8.0.17版本中引入了克隆插件。如果希望在组复制中使用远程克隆的方式进行分布式恢复，则必须对组中的现有成员和节点进行预先设置。
如果不进行相应的设置，则组复制只能使用二进制日志进行状态传输。要使用克隆功能，必须对组中的至少一个现有成员和节点进行预先设置，以支持远程克隆操作。即，至少需要在donor节点和节点上安装克隆插件，创建一个具有权限的复制用户用于分布式恢复，并将系统变量设置为适当量级的数值（默认情况下为GTID序列允许的最大值，表示正常情况下，始终优先使用基于二进制日志的状态传输，除非节点所请求的事务在组中任意成员中都不存在，这个时候，如果设置好了克隆功能，则无论该系统变量的值设置为多少，都会触发通过克隆的方式进行分布式恢复，例如：全新初始化的申请加入组时。如果不希望使用克隆功能，则不要对其进行安装与配置）。为了确保donor节点的最大可用性，建议在组中所有的现有成员和节点中都设置好克隆功能，以便后续有加入组时能够使用远程克隆操作来快速追赶组中的最新数据。请注意，远程克隆操作在从donor节点执行传输数据之前会删除掉节点中用户创建的数据和表空间。
如果中途远程克隆操作意外终止，则该节点中的用户数据可能已经被清空或者只剩下残留数据，无法重新启动实例。这个时候，可以通过重试远程克隆操作来修复此问题（这里主要针对远程克隆时使用DATA 子选项指定了一个数据保存路径的情况，指定路径时，数据会保存在指定的目录下，即克隆之后的数据与操作克隆的实例没有关联，需要手动启动实例并指定到保存克隆数据的目录进行启动），当然，MGR插件可以自动执行远程克隆的重试操作（需要保证克隆操作不指定DATA 子选项，在这种情况下，远程克隆数据会覆盖掉操作远程克隆的数据，完成远程克隆操之后，操作远程克隆的会基于克隆数据自动重新启动）。另外，克隆插件虽然与组复制配合使用对组复制的管理维护来说更加自动化，但是，克隆插件不要求必须在组中运行（但MGR插件必须要安装）。4.3.1.1. 克隆的前提条件关于组复制中使用克隆功能，需要注意以下要点和区别：