<div id="docs-body">
 <div class="section">
  <div class="titlepage">
   <div>
    <div>
     <h4 class="title">
      <a name="group-replication-distributed-recovery-connections">
      </a>
      20.5.4.1 Connections for Distributed Recovery
     </h4>
    </div>
   </div>
  </div>
  <p>
   When a joining member connects to an online existing member for
        state transfer during distributed recovery, the joining member
        acts as a client on the connection and the existing member acts
        as a server. When state transfer from the donor's binary log is
        in progress over this connection (using the asynchronous
        replication channel
   <code class="literal">
    group_replication_recovery
   </code>
   ), the joining
        member acts as the replica and the existing member acts as the
        source. When a remote cloning operation is in progress over this
        connection, the joining member acts as a recipient and the
        existing member acts as a donor. Configuration settings that
        apply to those roles outside the Group Replication context can
        apply for Group Replication also, unless they are overridden by
        a Group Replication-specific configuration setting or behavior.
  </p>
  <p>
   The connection that an existing member offers to a joining
        member for distributed recovery is not the same connection that
        is used by Group Replication for communication between online
        members of the group.
  </p>
  <div class="itemizedlist">
   <ul class="itemizedlist" style="list-style-type: disc; ">
    <li class="listitem">
     <p>
      The connection used by the group communication engine for
            Group Replication (XCom, a Paxos variant) for TCP
            communication between remote XCom instances is specified by
            the
      <a class="link" href="group-replication-system-variables.html#sysvar_group_replication_local_address">
       <code class="literal">
        group_replication_local_address
       </code>
      </a>
      system variable. This connection is used for TCP/IP messages
            between online members. Communication with the local
            instance is over an input channel using shared memory.
     </p>
    </li>
    <li class="listitem">
     <p>
      For distributed recovery, by default, group members offer
            their standard SQL client connection to joining members, as
            specified by
      <a class="link" href="server-system-variables.html#sysvar_hostname">
       <code class="literal">
        hostname
       </code>
      </a>
      and
      <a class="link" href="server-system-variables.html#sysvar_port">
       <code class="literal">
        port
       </code>
      </a>
      . If an alternative
            port number is specified by
      <a class="link" href="replication-options-replica.html#sysvar_report_port">
       <code class="literal">
        report_port
       </code>
      </a>
      , that one is
            used instead.
     </p>
    </li>
    <li class="listitem">
     <p>
      Group members may instead advertise an alternative list of
            distributed recovery endpoints as dedicated client
            connections for joining members, allowing you to control
            distributed recovery traffic separately from connections by
            regular client users of the member. A member transmits the
            list of distributed recovery endpoints specified by
      <a class="link" href="group-replication-system-variables.html#sysvar_group_replication_advertise_recovery_endpoints">
       <code class="literal">
        group_replication_advertise_recovery_endpoints
       </code>
      </a>
      to the group when it joins. By default, the member continues
            to offer the standard SQL client connection as in earlier
            releases.
     </p>
    </li>
   </ul>
  </div>
  <div class="important" style="margin-left: 0.5in; margin-right: 0.5in;">
   <div class="admon-title">
    Important
   </div>
   <p>
    Distributed recovery can fail if a joining member cannot
          correctly identify the other members using the host name as
          defined by MySQL Server's
    <a class="link" href="server-system-variables.html#sysvar_hostname">
     <code class="literal">
      hostname
     </code>
    </a>
    system variable. It
          is recommended that operating systems running MySQL have a
          properly configured unique host name, either using DNS or
          local settings. The host name that the server is using for SQL
          client connections can be verified in the
    <code class="literal">
     Member_host
    </code>
    column of the Performance
          Schema table
    <a class="link" href="performance-schema-replication-group-members-table.html" title="29.12.11.16 The replication_group_members Table">
     <code class="literal">
      replication_group_members
     </code>
    </a>
    . If
          multiple group members externalize a default host name set by
          the operating system, there is a chance of the joining member
          not resolving it to the correct member address and not being
          able to connect for distributed recovery. In this situation
          you can use MySQL Server's
    <a class="link" href="replication-options-replica.html#sysvar_report_host">
     <code class="literal">
      report_host
     </code>
    </a>
    system variable
          to configure a unique host name to be externalized by each of
          the servers.
   </p>
  </div>
  <p>
   The steps for a joining member to establish a connection for
        distributed recovery are as follows:
  </p>
  <div class="orderedlist">
   <ol class="orderedlist" type="1">
    <li class="listitem">
     <p>
      When the member joins the group, it connects with one of the
            seed members included in the list in its
      <a class="link" href="group-replication-system-variables.html#sysvar_group_replication_group_seeds">
       <code class="literal">
        group_replication_group_seeds
       </code>
      </a>
      system variable, initially using the
      <a class="link" href="group-replication-system-variables.html#sysvar_group_replication_local_address">
       <code class="literal">
        group_replication_local_address
       </code>
      </a>
      connection as specified in that list. The seed members might
            be a subset of the group.
     </p>
    </li>
    <li class="listitem">
     <p>
      Over this connection, the seed member uses Group
            Replication's membership service to provide the joining
            member with a list of all the members that are online in the
            group, in the form of a view. The membership information
            includes the details of the distributed recovery endpoints
            or standard SQL client connection offered by each member for
            distributed recovery.
     </p>
    </li>
    <li class="listitem">
     <p>
      The joining member selects a suitable group member from this
            list to be its donor for distributed recovery, following the
            behaviors described in
      <a class="xref" href="group-replication-distributed-recovery-fault.html" title="20.5.4.4 Fault Tolerance for Distributed Recovery">
       Section 20.5.4.4, “Fault Tolerance for Distributed Recovery”
      </a>
      .
     </p>
    </li>
    <li class="listitem">
     <p>
      The joining member then attempts to connect to the donor
            using the donor's advertised distributed recovery endpoints,
            trying each in turn in the order they are specified in the
            list. If the donor provides no endpoints, the joining member
            attempts to connect using the donor's standard SQL client
            connection. The SSL requirements for the connection are as
            specified by the
      <code class="literal">
       group_replication_recovery_ssl_*
      </code>
      options
            described in
      <a class="xref" href="group-replication-distributed-recovery-connections.html#group-replication-distributed-recovery-connections-ssl" title="20.5.4.1.4 SSL and Authentication for Distributed Recovery">
       Section 20.5.4.1.4, “SSL and Authentication for Distributed Recovery”
      </a>
      .
     </p>
    </li>
    <li class="listitem">
     <p>
      If the joining member is not able to connect to the selected
            donor, it retries with other suitable donors, following the
            behaviors described in
      <a class="xref" href="group-replication-distributed-recovery-fault.html" title="20.5.4.4 Fault Tolerance for Distributed Recovery">
       Section 20.5.4.4, “Fault Tolerance for Distributed Recovery”
      </a>
      .
            Note that if the joining member exhausts the list of
            advertised endpoints without making a connection, it does
            not fall back to the donor's standard SQL client connection,
            but switches to another donor.
     </p>
    </li>
    <li class="listitem">
     <p>
      When the joining member establishes a distributed recovery
            connection with a donor, it uses that connection for state
            transfer as described in
      <a class="xref" href="group-replication-distributed-recovery.html" title="20.5.4 Distributed Recovery">
       Section 20.5.4, “Distributed Recovery”
      </a>
      .
            The host and port for the connection that is used are shown
            in the joining member's log. Note that if a remote cloning
            operation is used, when the joining member has restarted at
            the end of the operation, it establishes a connection with a
            new donor for state transfer from the binary log. This might
            be a connection to a different member from the original
            donor used for the remote cloning operation, or it might be
            a different connection to the original donor. In any case,
            the distributed recovery process continues in the same way
            as it would have with the original donor.
     </p>
    </li>
   </ol>
  </div>
  <div class="section">
   <div class="titlepage">
    <div>
     <div>
      <h5 class="title">
       <a name="group-replication-distributed-recovery-connections-endpoints">
       </a>
       20.5.4.1.1 Selecting addresses for distributed recovery endpoints
      </h5>
     </div>
    </div>
   </div>
   <p>
    IP addresses supplied by the
    <a class="link" href="group-replication-system-variables.html#sysvar_group_replication_advertise_recovery_endpoints">
     <code class="literal">
      group_replication_advertise_recovery_endpoints
     </code>
    </a>
    system variable as distributed recovery endpoints do not have
          to be configured for MySQL Server (that is, they do not have
          to be specified by the
    <a class="link" href="server-system-variables.html#sysvar_admin_address">
     <code class="literal">
      admin_address
     </code>
    </a>
    system variable
          or in the list for the
    <a class="link" href="server-system-variables.html#sysvar_bind_address">
     <code class="literal">
      bind_address
     </code>
    </a>
    system
          variable). They do have to be assigned to the server. Any host
          names used must resolve to a local IP address. IPv4 and IPv6
          addresses can be used.
   </p>
   <p>
    The ports supplied for the distributed recovery endpoints do
          have to be configured for MySQL Server, so they must be
          specified by the
    <a class="link" href="server-system-variables.html#sysvar_port">
     <code class="literal">
      port
     </code>
    </a>
    ,
    <a class="link" href="replication-options-replica.html#sysvar_report_port">
     <code class="literal">
      report_port
     </code>
    </a>
    , or
    <a class="link" href="server-system-variables.html#sysvar_admin_port">
     <code class="literal">
      admin_port
     </code>
    </a>
    system variable.
          The server must listen for TCP/IP connections on these ports.
          If you specify the
    <a class="link" href="server-system-variables.html#sysvar_admin_port">
     <code class="literal">
      admin_port
     </code>
    </a>
    , the replication
          user for distributed recovery needs the
    <a class="link" href="privileges-provided.html#priv_service-connection-admin">
     <code class="literal">
      SERVICE_CONNECTION_ADMIN
     </code>
    </a>
    privilege to connect. Selecting the
    <a class="link" href="server-system-variables.html#sysvar_admin_port">
     <code class="literal">
      admin_port
     </code>
    </a>
    keeps distributed
          recovery connections separate from regular MySQL client
          connections.
   </p>
   <p>
    Joining members try each of the endpoints in turn in the order
          they are specified on the list. If
    <a class="link" href="group-replication-system-variables.html#sysvar_group_replication_advertise_recovery_endpoints">
     <code class="literal">
      group_replication_advertise_recovery_endpoints
     </code>
    </a>
    is set to
    <code class="literal">
     DEFAULT
    </code>
    rather than a list of
          endpoints, the standard SQL client connection is offered. Note
          that the standard SQL client connection is not automatically
          included on a list of distributed recovery endpoints, and is
          not offered as a fallback if the donor's list of endpoints is
          exhausted without a connection. If you want to offer the
          standard SQL client connection as one of a number of
          distributed recovery endpoints, you must include it explicitly
          in the list specified by
    <a class="link" href="group-replication-system-variables.html#sysvar_group_replication_advertise_recovery_endpoints">
     <code class="literal">
      group_replication_advertise_recovery_endpoints
     </code>
    </a>
    .
          You can put it in the last place so that it acts as a last
          resort for connection.
   </p>
   <p>
    A group member's distributed recovery endpoints (or standard
          SQL client connection if endpoints are not provided) do not
          need to be added to the Group Replication allowlist specified
          by the
    <a class="link" href="group-replication-system-variables.html#sysvar_group_replication_ip_allowlist">
     <code class="literal">
      group_replication_ip_allowlist
     </code>
    </a>
    system variable. The allowlist is only for the address
          specified by
    <a class="link" href="group-replication-system-variables.html#sysvar_group_replication_local_address">
     <code class="literal">
      group_replication_local_address
     </code>
    </a>
    for each member. A joining member must have its initial
          connection to the group permitted by the allowlist in order to
          retrieve the address or addresses for distributed recovery.
   </p>
   <p>
    The distributed recovery endpoints that you list are validated
          when the system variable is set and when a
    <a class="link" href="start-group-replication.html" title="15.4.3.1 START GROUP_REPLICATION Statement">
     <code class="literal">
      START GROUP_REPLICATION
     </code>
    </a>
    statement has been issued. If the list cannot be parsed
          correctly, or if any of the endpoints cannot be accessed on
          the host because the server is not listening on them, Group
          Replication logs an error and does not start.
   </p>
  </div>
  <div class="section">
   <div class="titlepage">
    <div>
     <div>
      <h5 class="title">
       <a name="group-replication-recovery-compression">
       </a>
       20.5.4.1.2 Compression for Distributed Recovery
      </h5>
     </div>
    </div>
   </div>
   <p>
    You can optionally configure compression for distributed
          recovery by the method of state transfer from a donor's
          binary log. Compression can benefit distributed recovery where
          network bandwidth is limited and the donor has to transfer
          many transactions to the joining member. The
    <a class="link" href="group-replication-system-variables.html#sysvar_group_replication_recovery_compression_algorithms">
     <code class="literal">
      group_replication_recovery_compression_algorithms
     </code>
    </a>
    and
    <a class="link" href="group-replication-system-variables.html#sysvar_group_replication_recovery_zstd_compression_level">
     <code class="literal">
      group_replication_recovery_zstd_compression_level
     </code>
    </a>
    system variables determine permitted compression algorithms,
          and the
    <code class="literal">
     zstd
    </code>
    compression level used when
          carrying out state transfer from a donor's binary log.
          For more information, see
    <a class="xref" href="connection-compression-control.html" title="6.2.8 Connection Compression Control">
     Section 6.2.8, “Connection Compression Control”
    </a>
    .
   </p>
   <p>
    These compression settings do not apply to remote cloning
          operations. When a remote cloning operation is used for
          distributed recovery, the clone plugin's setting for
    <a class="link" href="clone-plugin-options-variables.html#sysvar_clone_enable_compression">
     <code class="literal">
      clone_enable_compression
     </code>
    </a>
    applies.
   </p>
  </div>
  <div class="section">
   <div class="titlepage">
    <div>
     <div>
      <h5 class="title">
       <a name="group-replication-distributed-recovery-connections-user">
       </a>
       20.5.4.1.3 Replication User for Distributed Recovery
      </h5>
     </div>
    </div>
   </div>
   <p>
    Distributed recovery requires a replication user that has the
          correct permissions so that Group Replication can establish
          direct member-to-member replication channels. The replication
          user must also have the correct permissions to act as the
          clone user on the donor for a remote cloning operation. The
          same replication user must be used for distributed recovery on
          every group member. For instructions to set up this
          replication user, see
    <a class="xref" href="group-replication-user-credentials.html" title="20.2.1.3 User Credentials For Distributed Recovery">
     Section 20.2.1.3, “User Credentials For Distributed Recovery”
    </a>
    . For
          instructions to secure the replication user credentials, see
    <a class="xref" href="group-replication-secure-user.html" title="20.6.3.1 Secure User Credentials for Distributed Recovery">
     Section 20.6.3.1, “Secure User Credentials for Distributed Recovery”
    </a>
    .
   </p>
  </div>
  <div class="section">
   <div class="titlepage">
    <div>
     <div>
      <h5 class="title">
       <a name="group-replication-distributed-recovery-connections-ssl">
       </a>
       20.5.4.1.4 SSL and Authentication for Distributed Recovery
      </h5>
     </div>
    </div>
   </div>
   <p>
    SSL for distributed recovery is configured separately from SSL
          for normal group communications, which is determined by the
          server's SSL settings and the
    <a class="link" href="group-replication-system-variables.html#sysvar_group_replication_ssl_mode">
     <code class="literal">
      group_replication_ssl_mode
     </code>
    </a>
    system variable. For distributed recovery connections,
          dedicated Group Replication distributed recovery SSL system
          variables are available to configure the use of certificates
          and ciphers specifically for distributed recovery.
   </p>
   <p>
    By default, SSL is not used for distributed recovery
          connections. To activate it, set
    <a class="link" href="group-replication-system-variables.html#sysvar_group_replication_recovery_use_ssl">
     <code class="literal">
      group_replication_recovery_use_ssl=ON
     </code>
    </a>
    ,
          and configure the Group Replication distributed recovery SSL
          system variables as described in
    <a class="xref" href="group-replication-distributed-recovery-securing.html" title="20.6.3 Securing Distributed Recovery Connections">
     Section 20.6.3, “Securing Distributed Recovery Connections”
    </a>
    .
          You need a replication user that is set up to use SSL.
   </p>
   <p>
    When distributed recovery is configured to use SSL, Group
          Replication applies this setting for remote cloning
          operations, as well as for state transfer from a donor's
          binary log. Group Replication automatically configures the
          settings for the clone SSL options
          (
    <a class="link" href="clone-plugin-options-variables.html#sysvar_clone_ssl_ca">
     <code class="literal">
      clone_ssl_ca
     </code>
    </a>
    ,
    <a class="link" href="clone-plugin-options-variables.html#sysvar_clone_ssl_cert">
     <code class="literal">
      clone_ssl_cert
     </code>
    </a>
    , and
    <a class="link" href="clone-plugin-options-variables.html#sysvar_clone_ssl_key">
     <code class="literal">
      clone_ssl_key
     </code>
    </a>
    ) to match your
          settings for the corresponding Group Replication distributed
          recovery options
          (
    <a class="link" href="group-replication-system-variables.html#sysvar_group_replication_recovery_ssl_ca">
     <code class="literal">
      group_replication_recovery_ssl_ca
     </code>
    </a>
    ,
    <a class="link" href="group-replication-system-variables.html#sysvar_group_replication_recovery_ssl_cert">
     <code class="literal">
      group_replication_recovery_ssl_cert
     </code>
    </a>
    ,
          and
    <a class="link" href="group-replication-system-variables.html#sysvar_group_replication_recovery_ssl_key">
     <code class="literal">
      group_replication_recovery_ssl_key
     </code>
    </a>
    ).
   </p>
   <p>
    If you are not using SSL for distributed recovery (so
    <a class="link" href="group-replication-system-variables.html#sysvar_group_replication_recovery_use_ssl">
     <code class="literal">
      group_replication_recovery_use_ssl
     </code>
    </a>
    is set to
    <code class="literal">
     OFF
    </code>
    ), and the replication user
          account for Group Replication authenticates with the
    <code class="literal">
     caching_sha2_password
    </code>
    plugin (the default)
          or the
    <code class="literal">
     sha256_password
    </code>
    plugin (deprecated),
          RSA key pairs are used for password exchange. In this case,
          either use the
    <a class="link" href="group-replication-system-variables.html#sysvar_group_replication_recovery_public_key_path">
     <code class="literal">
      group_replication_recovery_public_key_path
     </code>
    </a>
    system variable to specify the RSA public key file, or use the
    <a class="link" href="group-replication-system-variables.html#sysvar_group_replication_recovery_get_public_key">
     <code class="literal">
      group_replication_recovery_get_public_key
     </code>
    </a>
    system variable to request the public key from the source, as
          described in
    <a class="xref" href="group-replication-secure-user.html#group-replication-caching-sha2-user-credentials" title="20.6.3.1.1 Replication User With The Caching SHA-2 Authentication Plugin">
     Section 20.6.3.1.1, “Replication User With The Caching SHA-2 Authentication Plugin”
    </a>
    .
   </p>
  </div>
 </div>
 <br/>
</div>
