现有集群节点和加入节点必须已安装克隆插件并处于激活状态。
引导节点和加入节点必须在相同的操作系统上运行，并且必须具有相同的MySQL Server版本（必须为MySQL 8.0.17或更高版本才能支持克隆插件）。因此，克隆不适用于成员运行不同MySQL版本的集群。
引导节点和加入节点必须已安装并激活了“组复制”插件，引导节点上所有激活的其他插件（例如，密钥环插件）也必须在加入节点上处于激活状态。
如果将分布式恢复配置为使用SSL（groupreplicationrecoveryusessl= ON），则组复制会将此设置应用于远程克隆操作。组复制会自动配置克隆SSL选项（clonesslca，clonesslcert和clonesslkey）的设置，以匹配相应组复制分布式恢复选项（groupreplicationrecoverysslca，groupreplicationrecoverysslcert和groupreplicationrecoverysslkey）的设置。
不需要在加入节点上为加入集群而在clonevaliddonor_list系统变量中设置有效引导节点列表。MGR自动从现有的集群节点中选择引导节点后，组复制会自动配置此设置。注意，远程克隆操作使用server的SQL协议主机名和端口，而非集群成员之间内部通讯的地址和端口。
克隆插件具有许多系统变量，可管理远程克隆操作的网络负载和性能影响。组复制未配置这些设置，因此可以查看它们并根据需要进行设置，也可以将其设置为默认设置，当使用远程克隆操作进行分布式恢复时，克隆插件的cloneenablecompression设置将应用于该操作，而不会影响现有配置好的组复制压缩设置。
为了对加入节点调用远程克隆操作，组复制使用内部mysql.session用户，该用户已经具有CLONE_ADMIN特权，因此无需进行特别设置。
作为远程克隆操作的引导节点上的克隆用户，组复制使用为分布式恢复设置的复制用户。因此，必须在所有支持克隆的集群节点上将此复制用户赋予BACKUP_ADMIN特权。在为节点配置组复制时，如果有加入节点，还应向该节点上的复制用户授予此权限，因为加入节点加入集群后，他们可以充当其他加入节点的引导节点。同一复制用户用于每个集群节点上的分布式恢复。要将此权限授予现有节点上的复制用户，可以在禁用二进制日志记录的情况下在每个集群节点上单独执行此语句，或者在启用二进制日志记录的情况下在一个集群的primary节点上执行如下语句：
GRANT?BACKUP_ADMIN?ON?*.*?TO?*rpl_user*@'%';
如果在使用STARTGROUPREPLICATION以前在提供用户凭据的server上使用CHANGE MASTER TO指定复制用户凭据，请确保在进行任何远程克隆操作之前，从复制元数据存储库中删除该用户凭据。还要确保在加入成员上设置了groupreplicationstartonboot =OFF。如果未取消设置用户凭据，则在远程克隆操作期间会将它们转移到加入成员。然后，可能会在原始成员或从其克隆的成员上意外地使用存储的凭据启动groupreplicationrecovery通道。server启动时（包括在远程克隆操作之后）自动启动组复制将使用存储的用户凭据，并且如果未在START GROUPREPLICATION命令上指定分布式恢复凭据，也将使用它们。
3.2克隆的阈值
设置组成员支持克隆后，groupreplicationclonethreshold系统变量将指定一个阈值，表示为多少个事务，以便在分布式恢复中使用远程克隆操作。如果引导节点上的事务与加入节点上的事务之间的数量大于此数目，则在技术上可行时，将使用远程克隆操作将状态转移到加入节点。组复制基于现有组成员的gtidexecuted集来计算是否已超过阈值。在事务间隙较大的情况下使用远程克隆操作，可以将新成员添加到集群中，而无需事先将集群的数据手动传输到服务器，还可以使落后的节点更有效地进行数据追赶。
groupreplicationclone_threshold组复制系统变量的默认设置非常高（GTID中事务的最大允许序列号），因此，只要有可能从二进制日志转移状态，它都会有效地禁用克隆。要使组复制能够选择更适合状态传输的远程克隆操作，设置系统变量，以指定多少个事务作为要进行克隆的事务间隔。
PS：
不要在活跃的集群中为groupreplicationclone_threshold使用较低的设置。如果在进行远程克隆操作的同时集群中发生了超过阈值的事务，则加入成员在重新启动后会再次触发远程克隆操作，并且可以无限期地继续进行。为避免这种情况，确保将阈值设置为一个可靠的数字，该阈值应大于在远程克隆操作所花费的时间段内集群中预期发生的事务数。
当无法从引导节点的二进制日志进行状态转移时，组复制尝试执行远程克隆操作，而不管此时的阈值如何，例如，因为加入成员所需的事务在任何现有组成员的二进制日志中均不可用。组复制基于现有组成员的gtidpurged集对此进行标识。当所需的事务在任何成员的二进制日志文件中不可用时，不能使用groupreplicationclonethreshold系统变量来停用克隆，因为在这种情况下，克隆是手动将数据传输到加入节点的唯一选
3.3克隆操作
设置集群节点和加入节点进行克隆后，组复制将管理远程克隆操作。远程克隆操作需要一些时间才能完成，具体取决于数据的大小。
performanceschema.cloneprogress表中记录了整个克隆操作的每一个阶段及其对应的阶段信息，每一个阶段会生成一行记录（注意，该表中只记录一次克隆操作的过程信息，下一次执行克隆操作时，上一次的信息会被覆盖）
select?*?from?clone_progress; +------+-----------+-----------+----------------------------? +----------------------------+---------+------------+--------? ----+------------+------------+---------------+ |?ID?|?STAGE?|?STATE?|?BEGIN_TIME?|?END_TIME?|?THREADS?|? ESTIMATE?|?DATA?|?NETWORK?|?DATA_SPEED?|?NETWORK_SPEED?| +------+-----------+-----------+----------------------------? +----------------------------+---------+------------+-------? -----+------------+------------+---------------+ |?1?|?DROP?DATA?|?Completed?|?2019-10-08?16:46:58.757964?|? 2019-10-08?16:46:59.128436?|?1?|?0?|?0?|?0?|?0?|?0?| |?1?|?FILE?COPY?|?Completed?|?2019-10-08?16:46:59.128766?|? ?2019-10-08?16:47:16.857536?|?8?|?8429731840?|?8429731840?|? ?8430190882?|?0?|?0?| |?1?|?PAGE?COPY?|?Completed?|?2019-10-08?16:47:16.857737?|? ?2019-10-08?16:47:17.159531?|?8?|?0?|?0?|?785?|?0?|?0?| |?1?|?REDO?COPY?|?Completed?|?2019-10-08?16:47:17.159748?|? 2019-10-08?16:47:17.460516?|?8?|?2560?|?2560?|?3717?|?0?|?0? | |?1?|?FILE?SYNC?|?Completed?|?2019-10-08?16:47:17.460788?|? 2019-10-08?16:47:20.926184?|?8?|?0?|?0?|?0?|?0?|?0?| |?1?|?RESTART?|?Completed?|?2019-10-08?16:47:20.926184?|?
|?1?|?RESTART?|?Completed?|?2019-10-08?16:47:20.926184?|? 2019-10-08?16:47:28.623732?|?0?|?0?|?0?|?0?|?0?|?0?| |?1?|?RECOVERY?|?Completed?|?2019-10-08?16:47:28.623732?|? 2019-10-08?16:47:34.898453?|?0?|?0?|?0?|?0?|?0?|?0?| +------+-----------+-----------+----------------------------? +----------------------------+---------+------------+-------? -----+------------+------------+---------------+ 7?rows?in?set?(0.00?sec) select?*?from?clone_status\G ***************************?1.?row?*************************** ID:?1 PID:?0 STATE:?Completed BEGIN_TIME:?2019-10-08?16:46:58.758 END_TIME:?2019-10-08?16:47:34.898 SOURCE:?10.10.30.162:3306 DESTINATION:?LOCAL?INSTANCE ERROR_NO:?0 ERROR_MESSAGE: BINLOG_FILE:?mysql-bin.000022 BINLOG_POSITION:?222104704 GTID_EXECUTED:?320675e6-de7b-11e9-b3a9-5254002a54f2:1-4, aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:1-2771494 1?row?in?set?(0.01?sec)
PS：
状态转移完成后，组复制将重新启动加入节点以完成该过程。如果在加入节点上设置了groupreplicationstartonboot = OFF，例如，因为在START GROUPREPLICATION语句上指定了复制用户凭据，则在重新启动后必须再次手动发布START GROUPREPLICATION。如果在配置文件中或使用SET PERSIST语句设置了groupreplicationstartonboot = ON以及启动组复制所需的其他设置，则无需干预，该过程会自动继续使加入节点设置为online状态。
远程克隆操作会将引导节点的数据目录下的各种数据文件克隆到加入节点中（表中可能包含了一些配置信息及其用户数据等）。但保存在配置文件（如组复制本地地址配置等）中的组复制成员设置不会被克隆，也不会在加入节点上做任何更改。即，组复制相关的配置需要自行配置好，不能跟集群中的现有成员冲突，远程克隆操作只负责克隆数据文件，不会克隆配置信息（当然，如果某些配置信息保存在表里，对于克隆操作来说，也会被当做数据进行克隆）。
如果远程克隆过程花费很长时间，则在MySQL 8.0.22之前的发行版中，在该时间段内为该集群累积的一组认证信息可能会变得太大而无法传输给加入成员。在这种情况下，加入成员会记录一条错误消息，并且不会加入该集群。从MySQL 8.0.22开始，组复制以不同的方式管理应用事务的垃圾收集过程，以避免发生这种情况。在早期版本中，如果确实看到此错误，则在远程克隆操作完成之后，请等待两分钟，以允许进行一轮垃圾收集，以减小集群的认证信息的大小。然后在加入成员上发出以下声明，以使其停止尝试应用先前的认证信息集：
RESET?SLAVE?FORCHANNEL?group_replication_recovery; RESET?REPLICA?FOR?CHANNEL?group_replication_recovery;（从8.0.22开始）
引导节点中用于组复制专用通道groupreplicationrecovery的用户凭证（复制用户和密码），在克隆操作完成之后，会被新成员使用，所以，该用户和密码及其权限必须在新成员中也有效。因此，所有组成员才能够使用相同的复制用户和密码通过远程克隆操作接收状态传输进行分布式恢复。但是，组复制会保留与使用SSL相关的组复制通道设置，这些设置对单个成员来说可以是惟一的（即，每个组成员使用不同的复制用户和密码）。如果使用了PRIVILEGECHECKSUSER帐户来帮助保护复制应用线程（从MySQL8.0.18开始，可以创建一个具有特定权限的用户账号，然后将其指定为PRIVILEGECHECKSUSER帐户，这样可以防止将未经授权或意外将具有特权的账号用于组复制通道），则在克隆操作完成之后新加入成员不会使用该用户帐户作为组复制通道的用户。此时必须为组复制通道手工指定合适的复制用户。
如果引导节点用于groupreplicationrecovery复制通道的复制用户凭据已使用CHANGE MASTER TO语句存储在复制元数据存储库中，则在克隆后将它们转移到加入成员并由其使用，并且它们在此处必须有效。因此，使用存储的凭据，所有通过远程克隆操作接收状态转移的组成员都会自动接收复制用户和密码，进行分布式恢复。如果在START GROUPREPLICATION语句上指定了复制用户凭据，则这些凭据将用于启动远程克隆操作，但是在克隆后它们不会传输到加入节点并由其使用。如果不希望将凭据转移到新的server上并记录在那里，确保在进行远程克隆操作之前取消设置它们，并使用START GROUPREPLICATION代替提供它们。
ps:如果已使用PRIVILEGECHECKSUSER帐户来帮助保护复制应用程序，则从MySQL 8.0.19开始，会将PRIVILEGECHECKSUSER帐户以及来自引导节点的相关设置克隆出来。如果将加入节点设置为在启动时启动组复制，它将自动使用该帐户在相应的复制通道上进行权限检查。（在MySQL 8.0.18中，由于许多限制，建议不要将PRIVILEGECHECKSUSER帐户用于组复制通道。）
3.4克隆的其他用处
组复制启动并管理用于分布式恢复的克隆操作。设置为支持克隆的组成员也可以参与用户手动启动的克隆操作。例如，可能希望通过从组成员作为引导节点来进行克隆来创建新的MySQL实例，但是不希望新的服务器实例立即加入或可能永远不会加入该集群。
在所有支持克隆的发行版中，可以手动启动涉及停止了组复制的组成员的克隆操作。由于克隆要求引导节点和接收数据的节点上的克隆插件必须匹配，因此即使不希望该实例加入集群，也必须在另一个实例上安装并激活组复制插件。可以通过发出以下语句来安装插件：
INSTALL?PLUGIN?group_replication?SONAME'group_replication.so';
在MySQL 8.0.20之前的发行版中，如果操作涉及正在运行“组复制”的组成员，则无法手动启动克隆操作。从MySQL8.0.20开始，只要克隆操作不会删除和替换接收者上的数据，就可以执行此操作。因此，如果正在运行组复制，则用于启动克隆操作的语句必须包含DATA DIRECTORY子句。
到此这篇关于MySQL分布式恢复进阶的文章就介绍到这了,更多相关SQL分布式恢复内容请搜索
更多相关Mysql内容来自木庄网络博客
标签：Mysql
相关阅读 >>
更多相关阅读请进入《mysql》频道 >>
数据库系统概念 第6版
本书主要讲述了数据模型、基于对象的数据库和XML、数据存储和查询、事务管理、体系结构等方面的内容。
