From MySQL 8.0.26, Group Replication has the capability 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
privilege) can configure a member action on the group’s
primary using the
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
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
table, which can be viewed using the Performance Schema table
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.
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
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
can be configured to make a group in single-primary mode stay
in super read-only mode when a new primary is elected, so that
the group only accepts replicated transactions and does not
accept any direct writes from clients. This setup means that
when a group’s purpose is 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
enabled, which is its default setting. If you set the action
to disabled using the
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
SUPER privilege. It does
continue to accept updates performed by replication threads.