使用 Perfomance Schema 中的表来监控组复制 , 假定你的MySQL编译时已经启动了 Performance Schema 表。组复制将添加如下两张 P_S 表：

performance_schema.replication_group_member_stats
performance_schema.replication_group_members

下面这些已存在的 P_S 复制表同样也显示一些组复制的信息。

performance_schema.replication_connection_status
performance_schema.replication_applier_status

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

group_replication_recovery - 该通道在分布式恢复阶段进行复制。
group_replication_applier - 该通道在组中有新写入操作时进行复制。该通道是组中有新事务流入时使用的通道。

下面一些小节中将描述这些表中可以获取到的信息。

1.成员状态

复制组中的每个成员都要验证并应用组提交的事务。关于验证者(certifier)和应用者(applier)相关的统计数据 , 有助于理解应用者队列(applier queue)是如何增长的、检测了多少次冲突、检测到多少个事务、哪些事务是到处提交的等等问题。

performance_schema.replication_group_member_stats表提供了以下认证相关信息：

字段	描述
`Channel_name`	组复制通道的名称。
`Member_id`	当前连接到的节点的`UUID`。组中每个节点的`UUID`值都必须唯一 , 也正因为如此 , 它也提供了一种`key`。
`Count_Transactions_in_queue`	冲突检测队列中事务的数量。一旦探测到冲突 , 且通过了检查 , 则它们也会排队后被应用和提交。
`Count_transactions_checked`	已检测到的冲突事务数量。
`Count_conflicts_detected`	未通过冲突检查的事务数量。
`Count_transactions_validating`	冲突检测数据库的大小(根据该数据库对每个事务进行确认)
`Transactions_committed_all_members`	显示在当前视图中所有成员都成功提交的事务。该字段会在固定的时间间隔内更新。
`Last_conflict_free_transaction`	显示最后检测到的无冲突事务的事务`ID`。

这些字段对于监控连接组中成员的性能很重要。例如 , 假设组中某成员有些延迟 , 它没有赶上组中其他成员的数据。这种情况下 , 你可能会看到队列中有大量事务。根据这些信息 , 你可以决定是将该成员踢出组还是延迟组中其他成员处理事务 , 以便减少队列中的事务数量。这些信息同样可以帮助你决定如何调整组复制插件的流程控制。

2.组成员

该表用于监控当前视图所跟踪的节点状态。或者换句话说 , 作为复制组的一部分 , 这些节点会被组成员服务跟踪。

字段	描述
`Channel_name`	组复制的通道名称。
`Member_id`	成员节点的 `UUID`。
`Member_host`	成员的地址。
`Member_port`	用于成员间通信的监听端口。
`Member_state`	成员的状态(可能的状态值`ONLINE`, `ERROR`, `RECOVERING`,`OFFLINE` 或 `UNREACHABLE`)

3.连接状态

当连接到组时 , 该表中的一些字段显示组复制相关的信息。例如 , 已从组中接收到并在应用者(applier)队列(relay log)中排队的事务。

字段	描述
`Channel_name`	组复制通道的名称。
`Group_name`	复制组的名称。通常它是一个有效的`UUID`值。
`Source_UUID`	组的标识符。它类似于组的名称 , 它用做组复制期间产生的所有事务的`UUID`。
`Service_state`	显示该成员是否是组的一部分。可能的值有 {`ON`,`OFF`和`CONNECTING`}。
`Received_transaction_set`	该成员已经接收到的`GTID`集。

4.applier状态

也可以通过普通的表 replication_applier_status 来获取组复制相关通道的状态和线程信息。如果有很多不同工作线程正在应用(执行)事务 , 该worker表同样可以用来监控每个工作线程正在做什么。

字段	描述
`Channel_name`	组复制通道的名称。
`Service_state`	显示应用(`applier`)服务的状态是`ON` 还是 `OFF`。
`Remaining_delay`	显示是否有`applier`被延迟。
`Count_transactions_retries`	应用事务的重试次数。
`Received_transaction_set`	该成员已经接收到的`GTID`集。

5.节点状态

在每次视图发生改变时 , replication_group_members 表会随之更新。例如 , 组配置被动态更改。此时 , 节点之间会交换它们的元数据信息并自我同步 , 然后协调达成一致。

组中节点可能有多种状态。如果节点之间能正常通信 , 则所有节点的报告信息都是相同的。但如果发生了网络分裂 , 或节点离开了组 , 则可能会报告不同的信息 , 这依赖于被查询的是哪一个节点。注意 , 如果节点已经离开了组 , 那么显然它不能报告其他节点相关的最新信息。如果发生了网络分裂 , 以至于丢失了法定票数 , 则各节点将无法进行协调。因此 , 它们无法猜测其他节点的状态是什么。因此 , 它们不会报告它们猜测出来的状态 , 而是会报告节点无法到达。

字段	描述	组同步状态
`ONLINE`	该节点已经准备好一切 , 可供客户端连接 , 并可以执行事务。	`Yes`
`RECOVERING`	该节点正在加入组 , 它当前正处于分布式恢复阶段 , 接收来自组的状态信息。	`No`
`OFFLINE`	插件已加载 , 但还不是任何组中的成员。	`No`
`ERROR`	无论是恢复阶段还是应用阶段发生错误 , 都会出现该状态。	`No`
`UNREACHABLE`	当本地故障探测器怀疑该节点不可到达时 , 将显示该状态。可能的原因是目标宕机、非自愿离开组。	`No`