MGR监控
根据官方文档内容的整理
参考网址： https://dev.mysql.com/doc/refman/8.0/en/group-replication-monitoring.html
假设已启用performance_schema，请使用性能架构表来监视组复制 。组复制将添加下表:
performance_schema.replication_group_member_stats 显示有关组复制的信息，例如，已从组接收并在申请者队列（中继日志）中排队的事务。
performance_schema.replication_group_members 显示与组复制相关的通道和线程的状态。如果有许多不同的工作线程在应用事务，那么工作表也可以用来监视每个工作线程在做什么。
由组复制插件创建的replication channel被命名为：
- group_replication_recovery -此通道用于与分布式恢复阶段相关的复制更改。
- 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.
从MySQL 8.0.21开始，属于非错误情况的组复制生命周期事件被归类为系统消息，并且始终记录在复制组成员的服务器错误日志中。您可以使用此信息来查看复制组中服务器成员身份的历史记录。在以前的版本中，属于非错误情况的组复制生命周期事件被归类为信息消息，可以通过 log_error_verbosity 为服务器指定级别3来将其添加到错误日志中 。
一些影响整个组的生命周期事件会记录在每个组成员上，例如新成员ONLINE在组中进入 状态或主要选举。其他事件仅记录在发生它们的成员上，例如在成员上启用或禁用超级只读模式，或者成员离开组。许多可能指示问题（如果它们频繁发生）的生命周期事件被记录为警告消息，包括成员变得不可访问和再次可访问，以及该成员通过从二进制日志进行状态转移或通过远程克隆操作开始分布式恢复。
组复制服务器状态
The replication_group_members Table
performance_schema.replication_group_members表用于监视属于该组成员的不同服务器实例的状态。
::只要有视图更改，表中的信息就会更新::。
SELECT * FROM performance_schema.replication_group_members;
+---------------------------+--------------------------------------+--------------+-------------+--------------+-------------+----------------+
| CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION |
+---------------------------+--------------------------------------+--------------+-------------+--------------+-------------+----------------+
| group_replication_applier | 041f26d8-f3f3-11e8-adff-080027337932 | example1 | 3306 | ONLINE | SECONDARY | 8.0.13 |
| group_replication_applier | f60a3e10-f3f2-11e8-8258-080027337932 | example2 | 3306 | ONLINE | PRIMARY | 8.0.13 |
| group_replication_applier | fc890014-f3f2-11e8-a9fd-080027337932 | example3 | 3306 | ONLINE | SECONDARY | 8.0.13 |
+---------------------------+--------------------------------------+--------------+-------------+--------------+-------------+----------------+
根据此结果，我们可以看到该组由三个成员组成，每个成员的客户端用于连接到该成员的主机和端口号，以及 server_uuid 该成员的。该 MEMBER_STATE列显示 第18.3.1节“组Replication Server状态”之一 ，在这种情况下，它显示该组中的所有三个成员均为 ONLINE。并且该MEMBER_ROLE 列显示有两个辅助服务器和一个主服务器。因此，该组必须在单主要模式下运行。MEMBER_VERSION当您升级组并合并运行不同MySQL版本的成员时，该 列将非常有用。请参见 第18.3.1节“组Replication Server状态” 了解更多信息。
有关该Member_host 值及其对分布式恢复过程的影响的更多信息，请参见 第18.2.1.3节“分布式恢复的用户凭据” 。
The replication_group_member_stats Table
复制组中的每个成员都认证并应用该组接收的事务。::有关证明者和申请者过程的统计信息对于了解申请者队列的增长方式，发现了多少冲突，检查了多少交易，在任何地方提交了哪些交易等很有用。::
performance_schema.replication_group_member_stats表提供了与认证过程相关的组级别信息，还提供了复制组的每个单独成员接收和发起的事务的统计信息。::该信息在属于复制组的所有服务器实例之间共享，因此可以从任何成员查询有关所有组成员的信息。::请注意，刷新远程成员的统计信息是由该 group_replication_flow_control_period 选项中指定的消息周期控制的 ，因此，::这些时间可能与进行查询的成员在本地收集的统计信息略有不同。::要使用此表监视组复制成员，请发出：
mysql> SELECT * FROM performance_schema.replication_group_member_stats\G
这些字段对于监视组中连接的成员的性能很重要。例如，假设与其他成员相比，该组的成员之一始终在其队列中报告大量事务。这意味着该成员被延迟，无法与该组的其他成员保持最新。根据此信息，您可以决定从该组中删除该成员，或延迟对该组其他成员的事务处理，以减少排队的事务数。此信息还可以帮助您决定如何调整Group Replication插件的流控制，请参见 第18.6.2节“流控制” 。
