20.5.1.5 Configuring Member Actions

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.