Distributed Recovery automatically configures the settings for the clone SSL options ( clone_ssl_ca ,  clone_ssl_cert , and clone_ssl_key ) to match your settings for the corresponding Group Replication distributed recovery options ( group_replication_recovery_ssl_ca ,  group_replication_recovery_ssl_cert , and  group_replication_recovery_ssl_key ). If you are not using SSL for distributed recovery (so  group_replication_recovery_use_ssl is set to  OFF ), and the replication user account for Group Replication authenticates with the caching_sha2_password  plugin (which is the default in MySQL 8.0) or the  sha256_password plugin, RSA key-pairs are used for password exchange. In this case, either use the group_replication_recovery_public_key_path  system variable to specify the RSA public key file, or use the  group_replication_recovery_get_public_key  system variable to request the public key from the source, as described in Replication User With The Caching SHA-2 Authentication Plugin. MySQL Server’s clone plugin is available from MySQL 8.0.17. If you want to use remote cloning operations for distributed recovery in a group, you must set up existing members and joining members beforehand to support this function. If you do not want to use this function in a group, do not set it up, in which case Group Replication only uses state transfer from the binary log. To use cloning, at least one existing group member and the joining member must be set up beforehand to support remote cloning operations. As a minimum, you must install the clone plugin on the donor and joining member, grant the  BACKUP_ADMIN  permission to the replication user for distributed recovery, and set the  group_replication_clone_threshold  system variable to an appropriate level. To ensure the maximum availability of donors, it is advisable to set up all current and future group members to support remote cloning operations. Be aware that a remote cloning operation removes user-created tablespaces and data from the joining member before transferring the data from the donor. If the operation is stopped while in progress, the joining member might be left with partial data or no data. This can be repaired by retrying the remote cloning operation, which Group Replication does automatically. For full instructions to set up and configure the clone plugin, see Section 5.6.7, “The Clone Plugin”  . Detailed prerequisites for a remote cloning operation are covered in Section 5.6.7.3, “Cloning Remote Data”  . For Group Replication, note the following key points and differences: 3740 •If distributed recovery is configured to use SSL ( group_replication_recovery_use_ssl=ON ), Group Replication applies this setting for remote cloning operations. Group Replication automatically configures the settings for the clone SSL options ( clone_ssl_ca ,  clone_ssl_cert , and clone_ssl_key ) to match your settings for the corresponding Group Replication distributed recovery options ( group_replication_recovery_ssl_ca ,  group_replication_recovery_ssl_cert , and  group_replication_recovery_ssl_key ). •The donor and the recipient must have the Group Replication plugin installed and active, and any other plugins that are active on the donor (such as a keyring plugin) must also be active on the recipient. •The donor and the recipient must run on the same operating system, and must have the same MySQL Server version (which must be MySQL 8.0.17 or above to support the clone plugin). Cloning is therefore not suitable for groups where members run different MySQL Server versions. •The donor (an existing group member) and the recipient (the joining member) must have the clone plugin installed and active. For instructions to do this, see Section 5.6.7.1, “Installing the Clone Plugin”  . Prerequisites for Cloning 18.5.3.2 Cloning for Distributed Recovery