MySQL 8.4 Reference Manual Including MySQL NDB Cluster 8.4
Group Replication has the ability to set actions for the members of a group to take in specified situations. Member actions can be enabled and disabled individually using functions. The member actions configuration for a server can also be reset to the default after it has left the group.
Administrators (with the
GROUP_REPLICATION_ADMIN
privilege) can configure a member action on the group’s
primary using the
group_replication_enable_member_action
or
group_replication_disable_member_action
function. The member actions configuration, consisting of all
the member actions and whether they are enabled or disabled, is
then propagated to other group members and joining members using
Group Replication’s group messages. All group members
therefore have the same member actions configuration. You can
also configure member actions on a server that is not part of a
group, as long as the Group Replication plugin is installed. In
that case, the member actions configuration is not propagated to
any other servers.
If the server where you use the functions to configure a member action is part of a group, it must be the current primary in a group in single-primary mode, and it must be part of the majority. The configuration change is tracked internally by Group Replication, but it is not given a GTID and is not written to the binary log, so it is not propagated to any servers outside the group, such as downstream replicas. Group Replication increments the version number for its member actions configuration each time a member action is enabled or disabled.
The member actions configuration is propagated to members as follows:
When starting a group, the member actions configuration of the server that bootstraps the group becomes the configuration for the group.
If a group’s lowest MySQL Server version supports member actions, joining members receive the group’s member actions configuration during the state exchange process that takes place when they join. In that case, the joining member replaces its own member actions configuration with the group’s.
If a joining member that supports member actions joins a group where the lowest MySQL Server version does not support member actions, it does not receive a member actions configuration when it joins. In that case, the joining member resets its own configuration to the default.
A member that does not support member actions cannot join a group that has a member actions configuration, because its MySQL Server version is lower than the lowest version that the existing group members are running.
The Performance Schema table
replication_group_member_actions
lists the member actions that are available in the
configuration, the events that trigger them, and whether or not
they are currently enabled. Member actions have a priority from
1 to 100, with lower values being actioned first. If an error
occurs when the member action is being carried out, the failure
of the member action can be logged but otherwise ignored. If the
failure of the member action is considered critical, it can be
handled according to the policy specified by the
group_replication_exit_state_action
system variable.
The
mysql.replication_group_configuration_version
table, which can be viewed using the Performance Schema table
replication_group_configuration_version
,
records the current version of the member actions configuration.
Whenever a member action is enabled or disabled using the
functions, the version number is incremented.
The
group_replication_reset_member_actions
function can only be used on a server that is not part of a
group. It resets the member actions configuration to the default
settings, and resets its version number to 1. The server must be
writeable (with the read_only
system variable set to OFF
) and have the
Group Replication plugin installed. You can use this function to
remove the member actions configuration that a server used when
it was part of a group, if you intend to use it as a standalone
server with no member actions or different member actions.
The member action
mysql_disable_super_read_only_if_primary
can
be set so that a group in single-primary mode stay in super
read-only mode when a new primary is elected; this means that
the group accepts replicated transactions only, and does not
accept any direct writes from clients. This setup means that
when a group's is intended to provide a secondary backup to
another group for disaster tolerance, you can ensure that the
secondary group remains synchronized with the first.
By default, super read-only mode is disabled on the primary when
it is elected, so that the primary becomes read/write, and
accepts updates from a replication source server and from
clients. This is the situation when the member action
mysql_disable_super_read_only_if_primary
is
enabled, which is its default setting. If you set the action to
disabled using the
group_replication_disable_member_action()
function, the primary remains in super read-only mode after
election. In this state, it does not accept updates from any
clients, even users who have the
CONNECTION_ADMIN
or
SUPER
privilege. It does continue
to accept updates performed by replication threads.