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.