MySQL 8.0 Reference Manual Including MySQL NDB Cluster 8.0
Use the Perfomance Schema tables to monitor Group Replication, assuming that the Performance Schema is enabled. Group Replication adds the following tables:
These Perfomance Schema replication tables also show information about Group Replication:
performance_schema.replication_connection_status
shows information regarding Group Replication, for example the
transactions that have been received from the group and queued
in the applier queue (the relay log).
performance_schema.replication_applier_status
shows the state of the Group Replication related channels and
threads If there are many different worker threads applying
transactions, then the worker tables can also be used to monitor
what each worker thread is doing.
The replication channels created by the Group Replication plugin are named:
group_replication_recovery - This channel is
used for the replication changes that are related to the
distributed recovery phase.
group_replication_applier - This channel is
used for the incoming changes from the group. This is the
channel used to apply transactions coming directly from the
group.
From MySQL 8.0.21, Group Replication lifecycle events that are
non-error situations are classified as system messages, and are
always logged to the server's error log on a replication group
member. You can use this information to review the history of the
server's membership in a replication group. In previous releases,
Group Replication lifecycle events that are non-error situations are
classified as information messages, which can be added to the error
log by specifying a
log_error_verbosity level of 3 for
the server.
Some lifecycle events that affect the whole group are logged on
every group member, such as a new member entering
ONLINE status in the group or a primary election.
Other events are logged only on the member where they take place,
such as super read only mode being enabled or disabled on the
member, or the member leaving the group. A number of lifecycle
events that can indicate an issue if they occur frequently are
logged as warning messages, including the member becoming
unreachable and reachable again, and the member starting distributed
recovery by state transfer from the binary log or by a remote
cloning operation.
The following sections describe how to interpret the monitoring information available for Group Replication.