In MySQL 8.0.27 and later, asynchronous connection failover for
replicas is activated automatically for a replication channel on
a Group Replication primary when you set
SOURCE_CONNECTION_AUTO_FAILOVER=1
in the CHANGE REPLICATION SOURCE
TO
statement for the channel. The feature is designed
for a group of senders and a group of receivers to keep
synchronized with each other even when some members are
temporarily unavailable. When the feature is active and
correctly configured, if the primary that is replicating goes
offline or into an error state, the new primary starts
replication on the same channel when it is elected. The new
primary uses the source list for the channel to select the
source with the highest priority (weight) setting, which might
not be the same as the original source.
To configure this feature, the replication channel and the
replication user account and password for the channel must be
set up on all the member servers in the replication group, and
on any new joining members. Ensure that
SOURCE_RETRY_COUNT
and
SOURCE_CONNECT_RETRY
are set to
minimal numbers that just allow a few retry attempts, for
example 3 and 10. You can set up the replication channel using
CHANGE REPLICATION SOURCE TO
, or if the new
servers are provisioned using MySQL's clone functionality,
this all happens automatically. The
SOURCE_CONNECTION_AUTO_FAILOVER
setting for
the channel is broadcast to group members from the primary when
they join. If you later disable
SOURCE_CONNECTION_AUTO_FAILOVER
for the
channel on the primary, this is also broadcast to the secondary
servers, and they change the status of the channel to match.
A server participating in a group in single-primary mode must
be started with
--skip-replica-start=ON
.
Otherwise, the server cannot join the group as a secondary.
Asynchronous connection failover for replicas is activated and
deactivated using the Group Replication member action
mysql_start_failover_channels_if_primary
,
which is enabled by default. You can disable it for the whole
group by disabling that member action on the primary, using the
group_replication_disable_member_action
function, as in this example:
mysql> SELECT group_replication_disable_member_action("mysql_start_failover_channels_if_primary", "AFTER_PRIMARY_ELECTION");
The function can only be changed on a primary, and must be
enabled or disabled for the whole group, so you cannot have some
members providing failover and others not. When the
mysql_start_failover_channels_if_primary
member action is disabled, the channel does not need to be
configured on secondary members, but if the primary goes offline
or into an error state, replication stops for the channel. Note
that if there is more than one channel with
SOURCE_CONNECTION_AUTO_FAILOVER=1
, the
member action covers all the channels, so they cannot be
individually enabled and disabled by that method. Set
SOURCE_CONNECTION_AUTO_FAILOVER=0
on the
primary to disable an individual channel.
The source list for a channel with
SOURCE_CONNECTION_AUTO_FAILOVER=1
is
broadcast to all group members when they join, and also when it
changes. This is the case whether the sources are a managed
group for which the membership is updated automatically, or
whether they are added or changed manually using
asynchronous_connection_failover_add_source()
,
asynchronous_connection_failover_delete_source()
,
asynchronous_connection_failover_add_managed()
,
or
asynchronous_connection_failover_delete_managed()
.
All group members receive the current source list as recorded in
the
mysql.replication_asynchronous_connection_failover
and
mysql.replication_asynchronous_connection_failover_managed
tables. Because the sources do not have to be in a managed
group, you can set up the function to synchronize a group of
receivers with one or more alternative standalone senders, or
even a single sender. A standalone replica that is not part of a
replication group cannot use this feature.