Use the Perfomance Schema tables to monitor Group Replication, assuming that the Performance Schema is enabled. The following tables display information specific to Group Replication:
These Perfomance Schema replication tables also show information relating to 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 as follows:
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.