使用性能模式（performance schema）表监控组复制，这里假设性能模式开启。复制组增加下列表：

1）performance_schema.replication_group_member_stats

2）performance_schema.replication_group_members

下列性能模式复制表也显示有关组复制的信息：

1）performance_schema.replication_connection_status

2）performance_schema.replication_applier_status

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

1）group_replication_recovery：该通道用于分布式恢复阶段相关的复制改变。

2）group_replication_applier ：该通道用于从组传入的更改。其为用于用于应用从组直接传入的事务。

下列部分描述这些表中每张表的可用信息。

一.Replication_group_member_stats

复制组内每个成员认证和应用组收到的事务。有关认证和应用过程的统计信息对理解应用队列如何增长、发生了多少冲突、检查了多少事务、每个地方提交的哪些事务等，都是有用的。

performance_schema.replication_group_member_stats表提供认证过程相关的信息。这些信息为复制组成员的所有服务器实例共享，因此，所有组成员的信息能在任何成员上查询。

表1-1 replication_group_member_stats

字段

描述

Channel_name

组复制通道的名字。

Member_id

成员服务器的UUID。每个组成员会有不同值。因为每个成员都是唯一的，因此，其也用作一个键。

Count_transactions_in_queue

未决冲突探测检查队列中的事务数。一旦事务进行冲突检查，且通过该检查，其将被放入应用队列。

Count_transactions_checked

已经进行冲突检查的事务数。

Count_conflicts_detected

未通过冲突探测检查的事务数。

Count_transactions_rows_validating

冲突探测数据库的大小（对每个事务进行认证）。

Transactions_committed_all_members

已在复制组所有成员成功提交的事务。其按照固定时间间隔更新。

Last_conflict_free_transaction

最后检查的无冲突事务的事务鉴定符。

这些字段对监控组内成员的性能是重要的。例如：假设一个组成员延后了，且不能追上组内其他成员。这种情况下，您也许会在队列中看到大量的事务。根据这些信息，您能决定从组内移去该成员，或者，为了减少队列中的事务数，延迟组内其他成员上事务的处理。这些信息有助于您决定如何调整组复制插件的流控。

 

二.Replication_group_members

该表用于监控目前视图中跟踪的不同服务器实例的状态，或换句话说，作为组的部分，因此，其通过成员服务进行跟踪。

表2-1 replication_group_members

字段

描述

Channel_name

复制组通道的名字。

Member_id

成员服务器的UUID。

Member_host

组成员的网络地址。

Member_port

组成员监听的mysql连接端口。

Member_state

组成员的目前状态（其能为ONLINE，ERROR，RECOVERING，OFFLIN或unreachable).

 

三.Replication_connection_status

当连接到一个组时，该表中的某些字段显示组复相关的信息。例如：已经从组收到和排队应用的事务（relay log）。

表3-1 replication_connection_status

字段

描述

Channel_name

组复制通道的名字。

Group_name

显示组名字。其总是有效的UUID。

Source_UUID

显示组标示符。其与组名字类似，且其用作组复制期间产生的所有事务的UUID。

Service_state

显示一个成员是否为组成员。服务状态可能的值为（ON， OFF 和CONNECTING）。

Received_transaction_set

已被该组成员接收的该GTID集中的事务。

 

四.Replication_applier_status

组复制相关通道和线程的状态也能通过该常规表replication_applier_status进行观察。如果有很多不同的工作线程（worker threads）正在应用事务，那么，该工作线程表也能用于监控每个工作线程正在做什么。

表4-1 replication_applier_status

字段

描述

Channel_name

组复制通道的名字。

Service_state

显示应用服务为ON或OFF。

Remaining_delay

显示是否配置了应用延迟。

Count_transactions_retries

应用事务时执行的重试次数。

Received_transaction_set

已被该组成员接收的该GTID集中的事务。

 

五.Group Replication Server States

无论何时视图更新，表replication_group_members都将会变更，例如：当组配置动态变更时。此时，服务器会交换其元数据以进行它们间的同步，并继续一起合作。

服务器实例可以处于几个状态。如果服务器正常通信，所有服务器都将报告同样状态。但是，如果发生网络分区，或服务器离开组，那么，可能会报告不同的信息，主要看查询哪个服务器。注意，如果服务器已经离开组，那么，很明显，其不能报告有关其他服务器状态的变更信息。如果发生网络分区，像失去法定票数，服务不能自己进行协调。结果，它们不能猜到不同服务器的状态。所以，不是猜服务器的状态，而是报告某些服务器不可到达。

表5-1 Server State

字段

描述

组

ONLINE

成员准备作为功能正常的组成员提供服务，意味着客户端能连接且开始执行事务。

Yes

RECOVERING

成员处于变为组活动成员的过程中，且目前正经历恢复过程，从捐赠成员接收状态信息。

No

OFFLINE

组件被加载，但该成员并不属于任何组。

No

ERROR

成员的状态。无论何时恢复阶段或应用变更时发生错误，服务器将进入该状态。

No

UNREACHABLE

无论何时本地失败探测器怀疑一个指定服务器不可到达，因为其也许发生了崩溃或非自愿断开了，其将显示服务器状态为’unreachable’。

No

 

--注：

1）一旦一个实例进入ERROR状态，super_read_only选项将被设置为ON。为了离开该ERROR，您必须手工配置该实例为super_read_only=OFF。

注意，组复制不是同步的，而是最终同步。更精确额的讲，事务按照同样的顺序传送给所有组成员，但它们的执行并非同步的，意味着事务被接收后，每个成员按照自己的步伐提交。