The replication_group_member_stats Table themselves and continue to cooperate together. The information is shared between all the server instances that are members of the replication group, so information on all the group members can be queried from any member. This table can be used to get a high level view of the state of a replication group, for example by issuing: SELECT * FROM performance_schema.replication_group_members; | CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | | 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 Based on this result we can see that the group consists of three members, each member’s host and port number which clients use to connect to the member, and the  server_uuid  of the member. The MEMBER_STATE  column shows one of the Section 18.4.2, “Group Replication Server States” , in this case it shows that all three members in this group are  ONLINE , and the  MEMBER_ROLE  column shows that there are two secondaries, and a single primary. Therefore this group must be running in single-primary mode. The  MEMBER_VERSION  column can be useful when you are upgrading a group and are combining members running different MySQL versions. See Section 18.4.2, “Group Replication Server States”  for more information. For more information about the  Member_host  value and its impact on the distributed recovery process, see Section 18.2.1.3, “User Credentials For Distributed Recovery” . Each member in a replication group certifies and applies transactions received by the group. Statistics regarding the certifier and applier procedures are useful to understand how the applier queue is growing, how many conflicts have been found, how many transactions were checked, which transactions are committed everywhere, and so on. The  performance_schema.replication_group_member_stats  table provides group-level information related to the certification process, and also statistics for the transactions received and originated by each individual member of the replication group. The information is shared between all the server instances that are members of the replication group, so information on all the group members can be queried from any member. Note that refreshing of statistics for remote members is controlled by the message period specified in the  group_replication_flow_control_period  option, so these can differ slightly from the locally collected statistics for the member where the query is made. To use this table to monitor a Group Replication member, issue: These fields are important for monitoring the performance of the members connected in the group. For example, suppose that one of the group’s members always reports a large number of transactions in its queue compared to other members. This means that the member is delayed and is not able to keep up to date with the other members of the group. Based on this information, you could decide to either remove the member from the group, or delay the processing of transactions on the other members of the group in order to reduce the number of queued transactions. This information can also help you to decide how to adjust the flow control of the Group Replication plugin, see Section 18.7.2, “Flow Control” . This section explains common operations for managing groups. mysql>  SELECT * FROM performance_schema.replication_group_member_stats\G 18.4.4 The replication_group_member_stats Table 18.5 Group Replication Operations 18.5.1 Configuring an Online Group 3724