Switching Sources with Asynchronous Connection Failover data. The list of potential source servers is stored on the replica, and in the event of a connection failure, a new source is selected from the list based on a weighted priority that you set. From MySQL 8.0.23, the asynchronous connection failover mechanism also supports Group Replication topologies, by automatically monitoring changes to group membership and distinguishing between primary and secondary servers. When you add a group member to the source list and define it as part of a managed group, the asynchronous connection failover mechanism updates the source list to keep it in line with membership changes, adding and removing group members automatically as they join or leave. Only online group members that are in the majority are used for connections and obtaining status. The last remaining member of a managed group is not removed automatically if it leaves the group, so that the configuration of the managed group is kept, but you can delete a managed group manually if it is no longer needed. To activate asynchronous connection failover for a replication channel set SOURCE_CONNECTION_AUTO_FAILOVER=1  on the  CHANGE REPLICATION SOURCE TO  statement (from MySQL 8.0.23) or  CHANGE MASTER TO  statement (before MySQL 8.0.23) for the channel. GTID auto- positioning must be in use for the channel ( SOURCE_AUTO_POSITION = 1  |  MASTER_AUTO_POSITION = 1 ). You can set this option while the replica is running. When the existing connection to a source fails, the replica first retries the same connection the number of times specified by the  SOURCE_RETRY_COUNT  | MASTER_RETRY_COUNT  option of the  CHANGE REPLICATION SOURCE TO  | CHANGE MASTER TO  statement. The interval between attempts is set by the SOURCE_CONNECT_RETRY  |  MASTER_CONNECT_RETRY  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  SOURCE_RETRY_COUNT  |  MASTER_RETRY_COUNT and  SOURCE_CONNECT_RETRY  |  MASTER_CONNECT_RETRY  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  SOURCE_RETRY_COUNT=3  |  MASTER_RETRY_COUNT=3  and SOURCE_CONNECT_RETRY=10  |  MASTER_CONNECT_RETRY=10 , which make the replica retry the connection 3 times with 10-second intervals between. Also set a source list on the replica for the replication channel. You set and manage source lists using the  asynchronous_connection_failover_add_source  and asynchronous_connection_failover_delete_source  functions to add and remove single replication source servers. To add and remove managed groups of servers, use the  asynchronous_connection_failover_add_managed  and asynchronous_connection_failover_delete_managed  functions instead. 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  group_replication_group_name  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. In MySQL 8.0.22, the asynchronous connection failover mechanism is activated following the failure of the replica’s connection to the source, and it issues a  START REPLICA | SLAVE  statement to attempt to 3644 Important