GRANT BACKUP_ADMIN ON *.* TO rpl_user@'%';
4.3.1.2. 克隆触发阈值 当组成员设置了支持克隆时，会通过系统变量指定的阈值（该阈值表示若干个事务）来判断在分布式恢复过程中是否需要使用远程克隆操作 。如果donor节点的事务与节点之间的事务差距大于此数字（组复制会根据组中的现有成员的系统变量中的GTID SET计算出它们之间的事务数量的差距是否超出了阈值），则在技术上可行的情况下，将使用远程克隆操作将donor节点的状态传输到节点，无需事先手动将组的数据传输到节点主机中，还可以让延迟非常大的组成员能够快速追赶上来 。系统变量的默认设置非常高（GTID中事务的最大允许序列号），因此只要可以从二进制日志传输状态，组复制就不会使用克隆功能传输状态 。要想让组复制在何时的时候使用远程克隆操作进行状态传输，可以根据具体情况对系统变量设置合适的值 。但是要注意，在组中有成员正在使用远程克隆操作进行状态传输的过程中，不要对系统变量设置过低的阈值 。
因为，如果在进行远程克隆操作时组中存在着大量超过阈值的新的事务请求，则节点在重新启动数据库进程后将再次触发远程克隆操作，并无限循环远程克隆操作 。要避免这种情况，需要将该阈值设置为高于组内的最高并发事务请求数 。当无法从donor节点的二进制日志进行状态传输时，组复制会尝试执行远程克隆操作 。此时会忽略系统变量的阈值设置，例如，节点所需的事务在任何现有组成员的二进制日志中都不可用（找不到） 。组复制基于现有组成员的系统变量的GTID SET来进行比对 。当任何现有组成员的二进制日志文件中都没有节点所需的事务时，组复制会尝试执行远程克隆操作进行状态传输，且这种情况下无法通过系统变量的阈值设置来停用克隆操作，因为在这种情况下，克隆是将组的状态传输到节点的一个可行的替代方法 。4.3.1.3. 克隆操作 当为组成员以及待加入组的成员都设置好了克隆功能时，组复制会接管远程克隆操作 。远程克隆操作过程可能需要一些时间才能完成，具体取决于数据的大小 。有关克隆操作过程的监控信息，详情可留意后续克隆插件系列文章 。
【组复制常规操作-分布式恢复 | 全方位认识 MySQL 8】# performance_schema.clone_progress表中记录了整个克隆操作的每一个阶段及其对应的阶段信息，每一个阶段会生成一行记录（注意，该表中只记录一次克隆操作的过程信息，下一次执行克隆操作时，上一次的信息会被覆盖）admin@localhost : performance_schema:37: > 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 | 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)# performance_schema.clone_status表中记录了克隆操作的一些元数据信息，例如，donor节点地址信息，对应数据的二进制日志位置信息和GTID信息（注意，该表中只记录一次克隆操作的信息，下一次执行克隆操作时，该表中的信息会被覆盖）admin@localhost : performance_schema:38: > select * from clone_status\G*************************** 1. row ***************************ID: 1PID: 0STATE: CompletedBEGIN_TIME: 2019-10-08 16:46:58.758END_TIME: 2019-10-08 16:47:34.898SOURCE: 10.10.30.162:3306DESTINATION: LOCAL INSTANCEERROR_NO: 0ERROR_MESSAGE:BINLOG_FILE: mysql-bin.000022BINLOG_POSITION: 222104704GTID_EXECUTED: 320675e6-de7b-11e9-b3a9-5254002a54f2:1-4,aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:1-27714941 row in set (0.01 sec)