Rechercher dans le manuel MySQL
18.5.1.5 Configuring Member Actions
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
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 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
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.
Document created the 26/06/2006, last modified the 26/10/2018
Source of the printed document:https://www.gaudry.be/en/mysql-rf-group-replication-member-actions.html
The infobrol is a personal site whose content is my sole responsibility. The text is available under CreativeCommons license (BY-NC-SA). More info on the terms of use and the author.
References
These references and links indicate documents consulted during the writing of this page, or which may provide additional information, but the authors of these sources can not be held responsible for the content of this page.
The author This site is solely responsible for the way in which the various concepts, and the freedoms that are taken with the reference works, are presented here. Remember that you must cross multiple source information to reduce the risk of errors.
