参考官方文档：

https://dev.mysql.com/doc/refman/5.7/en/group-replication-monitoring.html

假设已启用性能方案，请使用性能方案表来监视组复制。 组复制添加以下表：

• performance_schema.replication_group_member_stats
• performance_schema.replication_group_members

这些Perfomance Schema复制表还显示有关组复制的信息：

• performance_schema.replication_connection_status
• performance_schema.replication_applier_status

组复制插件创建的复制通道命名为：

• group_replication_recovery - 此通道用于与分布式恢复阶段相关的复制更改。
• group_replication_applier - 此通道用于组中的传入变更。 这是用于应用直接来自组的事务的通道。

17.3.1 Replication_group_member_stats

复制组中的每个成员都会验证并应用该组收到的事务。 有关验证者和应用程序过程的统计信息有助于了解应用程序队列的增长情况，被找到的冲突数，被检查的事务数，已提交的事务数等等。

performance_schema.replication_group_member_stats表提供与认证过程相关的信息。 信息在作为复制组成员的所有服务器实例之间共享，因此可以从任何成员查询有关所有组成员的信息。

例如，假设该组的一个成员被延迟，并且无法与该组的其他成员保持同步。 在这种情况下，您可能会在队列中看到大量事务。 根据此信息，您可以决定从组中删除该成员，或者对该组其他成员延迟事务处理，以减少排队事务的数量。

17.3.2 Replication_group_members

此表用于监视在当前视图中跟踪的不同服务器实例的状态，或者换句话说，它们是组的一部分，因此由关系成员服务跟踪。

17.3.3 Replication_connection_status

连接到组时，此表中的某些字段显示有关组复制的信息。 例如，已从组接收并在应用程序队列（中继日志）中排队的事务。

17.3.4 Replication_applier_status

还可以使用常规replication_applier_status表来观察与Group Replication相关的通道和线程的状态。 如果有许多不同的workers应用事务，那么worker表也可用于监视每个工作线程正在做什么。

17.3.5 组复制服务器状态

只要视图发生更改，就会更新表replication_group_members，例如，当组的配置动态更改时。 此时，服务器交换一些元数据以使自己同步并继续一起合作。

服务器实例可以处于各种状态。如果服务器正常通信，则所有服务器都报告相同的状态。 但是，如果存在网络分区，或者服务器离开该组，则可能会报告不同的信息，具体取决于查询的服务器。 请注意，如果服务器已离开该组，那么显然它无法报告有关其他服务器状态的更新信息。 如果存在分区，使得仲裁丢失，则服务器无法在它们之间进行协调。 结果，他们无法猜出不同服务器的状态。 因此，他们报告某些服务器无法访问，而不是猜测他们的状态。

注意：

实例进入ERROR状态后，super_read_only选项设置为ON。 要退出ERROR状态，必须使用super_read_only = OFF手动配置实例。

请注意，组复制不是同步的，但终是同步的。 更确切地说，事务以相同的顺序传递给所有组成员，但是它们的执行不同步，这意味着在接受提交事务之后，每个成员按照自己的进度提交。