<div id="docs-body">
 <div class="section">
  <div class="titlepage">
   <div>
    <div>
     <h4 class="title">
      <a name="replication-asynchronous-connection-failover-source">
      </a>
      19.4.9.1 Asynchronous Connection Failover for Sources
     </h4>
    </div>
   </div>
  </div>
  <p>
   To activate asynchronous connection failover for a replication
        channel set
   <code class="literal">
    SOURCE_CONNECTION_AUTO_FAILOVER=1
   </code>
   in a
   <a class="link" href="change-replication-source-to.html" title="15.4.2.2 CHANGE REPLICATION SOURCE TO Statement">
    <code class="literal">
     CHANGE REPLICATION SOURCE TO
    </code>
   </a>
   statement for this channel. GTID auto-positioning must be in use
        for the channel (
   <code class="literal">
    SOURCE_AUTO_POSITION = 1
   </code>
   ).
  </p>
  <div class="important" style="margin-left: 0.5in; margin-right: 0.5in;">
   <div class="admon-title">
    Important
   </div>
   <p>
    When the existing connection to a source fails, the replica
          first retries the same connection the number of times
          specified by the
    <code class="literal">
     SOURCE_RETRY_COUNT
    </code>
    option
          of the
    <a class="link" href="change-replication-source-to.html" title="15.4.2.2 CHANGE REPLICATION SOURCE TO Statement">
     <code class="literal">
      CHANGE REPLICATION SOURCE
          TO
     </code>
    </a>
    . The interval between attempts is set by the
    <code class="literal">
     SOURCE_CONNECT_RETRY
    </code>
    option. When these
          attempts are exhausted, the asynchronous connection failover
          mechanism takes over. Note that the defaults for these
          options, which were designed for a connection to a single
          source, make the replica retry the same connection for 60
          days. To ensure that the asynchronous connection failover
          mechanism can be activated promptly, set
    <code class="literal">
     SOURCE_RETRY_COUNT
    </code>
    and
    <code class="literal">
     SOURCE_CONNECT_RETRY
    </code>
    to minimal numbers
          that just allow a few retry attempts with the same source, in
          case the connection failure is caused by a transient network
          outage. Suitable values are
    <code class="literal">
     SOURCE_RETRY_COUNT=3
    </code>
    and
    <code class="literal">
     SOURCE_CONNECT_RETRY=10
    </code>
    , which make the
          replica retry the connection 3 times with 10-second intervals
          between.
   </p>
  </div>
  <p>
   You also need to set the source list for the replication
        channel, to specify the sources that are available for failover.
        You set and manage source lists using the
   <a class="link" href="replication-functions-async-failover.html#function_asynchronous-connection-failover-add-source">
    <code class="literal">
     asynchronous_connection_failover_add_source
    </code>
   </a>
   and
   <a class="link" href="replication-functions-async-failover.html#function_asynchronous-connection-failover-delete-source">
    <code class="literal">
     asynchronous_connection_failover_delete_source
    </code>
   </a>
   functions to add and remove single replication source servers.
        To add and remove managed groups of servers, use the
   <a class="link" href="replication-functions-async-failover.html#function_asynchronous-connection-failover-add-managed">
    <code class="literal">
     asynchronous_connection_failover_add_managed
    </code>
   </a>
   and
   <a class="link" href="replication-functions-async-failover.html#function_asynchronous-connection-failover-delete-managed">
    <code class="literal">
     asynchronous_connection_failover_delete_managed
    </code>
   </a>
   functions instead.
  </p>
  <p>
   The functions name the relevant replication channel and specify
        the host name, port number, network namespace, and weighted
        priority (1-100, with 100 being the highest priority) of a MySQL
        instance to add to or delete from the channel's source list. For
        a managed group, you also specify the type of managed service
        (currently only Group Replication is available), and the
        identifier of the managed group (for Group Replication, this is
        the value of the
   <a class="link" href="group-replication-system-variables.html#sysvar_group_replication_group_name">
    <code class="literal">
     group_replication_group_name
    </code>
   </a>
   system variable). When you add a managed group, you only need to
        add one group member, and the replica automatically adds the
        rest from the current group membership. When you delete a
        managed group, you delete the entire group together.
  </p>
  <p>
   The asynchronous connection failover mechanism also fails over
        the connection if another available server on the source list
        has a higher priority (weight) setting. This feature ensures
        that the replica stays connected to the most suitable source
        server at all times, and it applies to both managed groups and
        single (non-managed) servers. For a managed group, a source’s
        weight is assigned depending on whether it is a primary or a
        secondary server. So assuming that you set up the managed group
        to give a higher weight to a primary and a lower weight to a
        secondary, when the primary changes, the higher weight is
        assigned to the new primary, so the replica changes over the
        connection to it. The asynchronous connection failover mechanism
        additionally changes connection if the currently connected
        managed source server leaves the managed group, or is no longer
        in the majority in the managed group.
  </p>
  <p>
   When failing over a connection, the source with the highest
        priority (weight) setting among the alternative sources listed
        in the source list for the channel is chosen for the first
        connection attempt.


        The replica checks first that it can connect to the source
        server, or in the case of a managed group, that the source
        server has
   <code class="literal">
    ONLINE
   </code>
   status in the group (not
   <code class="literal">
    RECOVERING
   </code>
   or unavailable). If the highest
        weighted source is not available, the replica tries with all the
        listed sources in descending order of weight, then starts again
        from the highest weighted source. If multiple sources have the
        same weight, the replica orders them randomly. If the replica
        needs to start working through the list again, it includes and
        retries the source to which the original connection failure
        occurred.
  </p>
  <p>
   The source lists are stored in the
   <code class="literal">
    mysql.replication_asynchronous_connection_failover
   </code>
   and
   <code class="literal">
    mysql.replication_asynchronous_connection_failover_managed
   </code>
   tables, and can be viewed in the Performance Schema
   <a class="link" href="performance-schema-replication-asynchronous-connection-failover-table.html" title="29.12.11.8 The replication_asynchronous_connection_failover Table">
    <code class="literal">
     replication_asynchronous_connection_failover
    </code>
   </a>
   and
   <a class="link" href="performance-schema-replication-asynchronous-connection-failover-managed-table.html" title="29.12.11.9 The replication_asynchronous_connection_failover_managed Table">
    <code class="literal">
     replication_asynchronous_connection_failover_managed
    </code>
   </a>
   tables. The replica uses a monitor thread to track the
        membership of managed groups and update the source list
        (
   <code class="literal">
    thread/sql/replica_monitor
   </code>
   ). The setting for
        the
   <a class="link" href="change-replication-source-to.html#crs-opt-source_connection_auto_failover">
    <code class="literal">
     SOURCE_CONNECTION_AUTO_FAILOVER
    </code>
   </a>
   option of the
   <a class="link" href="change-replication-source-to.html" title="15.4.2.2 CHANGE REPLICATION SOURCE TO Statement">
    <code class="literal">
     CHANGE REPLICATION SOURCE
        TO
    </code>
   </a>
   statement, and the source list, are transferred to
        a clone of the replica during a remote cloning operation.
  </p>
  <p>
  </p>
 </div>
 <br/>
</div>
