服务实例可能处于多种状态。如果服务器正常通信，则所有服务均报告相​​同的状态。但是，如果存在网络分区，或者服务器离开了该组，可能会报告不同的信息，这个取决于要查询的服务器。如果服务已离开组，则它无法报告有关其他服务器状态信息。如果存在一个分区，导致仲裁丢失，则服务器将无法在它们之间进行协调。结果，他们无法知道不同服务的状态。而它们无法知道状态，会报告某些服务器不可达。

performance_schema.replication_group_members 表用于监视属于该组成员的不同服务器实例的状态。只要有视图更改，表中的信息就会更新，例如，当新成员加入时动态更改组的配置时。此时，服务器交换一些元数据以同步自己并继续合作。该信息在属于复制组的所有服务器实例之间共享，因此可以从任何成员查询有关所有组成员的信息。该表可用于获取复制组状态的高级视图，例如，通过如下命令：

SELECT * FROM performance_schema.replication_group_members;
+---------------------------+--------------------------------------+--------------+-------------+--------------+
| CHANNEL_NAME              | MEMBER_ID	                           | MEMBER_HOST  | MEMBER_PORT | MEMBER_STATE |
+---------------------------+--------------------------------------+--------------+-------------+--------------+
| group_replication_applier | 041f26d8-f3f3-11e8-adff-080027337932 | example1     |      3306   | ONLINE       |
| group_replication_applier | f60a3e10-f3f2-11e8-8258-080027337932 | example2     |      3306   | ONLINE       |
| group_replication_applier | fc890014-f3f2-11e8-a9fd-080027337932 | example3     |      3306   | ONLINE       |
+---------------------------+--------------------------------------+--------------+-------------+--------------+

根据此结果，我们可以看到该组由三个成员组成，每个成员的客户端用于连接到该成员的主机和端口号，以及 server_uuid及MEMBER_STATE，在这种情况下，它显示该组中的所有三个成员均为 ONLINE，并且该MEMBER_ROLE 列显示有两个辅助服务器和一个主服务器。因此，该组必须在单主式下运行。MEMBER_VERSION，当您升级组并合并运行不同MySQL版本的成员时，该列将非常有用。

复制组中的每个成员都认证并应用接收的事务。有关验证和应用过程的统计信息对于了解应用队列的增长，多少冲突被发现，多少事务被检查，什么事务被提交等很有用。

该 performance_schema.replication_group_member_stats 表提供了与认证过程相关的组级别信息，还提供了复制组的每个单独成员接收和发起的事务的统计信息。该信息在属于复制组的所有服务器实例之间共享，因此可以从任何成员查询有关所有组成员的信息。请注意，刷新远程成员的统计信息是由该group_replication_flow_control_period 选项中指定的消息周期控制的 ，因此，这些时间可能与进行查询的成员在本地收集的统计信息略有不同。要使用此表监视组复制成员，如下：

mysql> SELECT * FROM performance_schema.replication_group_member_stats\G

这些字段对于监视组中连接的成员的性能很重要。例如，假设与其他成员相比，该组的成员之一始终在其队列中报告大量事务。这意味着该成员被延迟，无法与该组的其他成员保持最新。根据此信息，可以决定从该组中删除该成员，或延迟对该组其他成员的事务处理，以减少排队的事务数。此信息还可以帮助您决定如何调整组复制插件的流控制。