Monitoring Group Replication
如果mysql编译了performance_schema，那么可以使用Perfomance 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 - 此通道用于来自组的传入更改。这是用于应用来自组的事务的通道。
以下部分描述了每个表中可用的信息。
Replication_group_member_stats
复制组中的每个成员都会验证并应用该组提交的事务。有关验证者和应用程序过程的统计信息对于了解应用程序队列如何增长，已找到多少冲突，检查了多少事务，到处提交了哪些事务等等非常有用。表performance_schema.replication_group_member_stats表提供与认证过程相关的以下信息(我发现实际上列名称和文档描述不一致)。|
Field |
Description |
|
Channel_name |
组复制通道名称 |
|
Member_id |
当前成员的uuid |
|
Count_Transactions_in_queue |
队列中等待冲突检测检查的事务数。一旦开始检查冲突，并且他们通过检查，他们排队等待应用。
|
|
Count_transactions_checked |
指示已参与过冲突检查的事务数。
|
|
Count_conflicts_detected |
指示未通过冲突检测检查的事务数。
|
|
Count_transactions_validating |
指示冲突检测数据库的当前大小
|
|
Transactions_committed_all_members |
指示已在当前视图的所有成员上成功提交的事务。这以固定的时间间隔更新。
|
|
Last_conflict_free_transaction |
显示最后一次无冲突的事务标识符。
|
这些字段对于监视组中连接的成员的性能很重要。例如，假设组的成员之一被延迟，并且不能与组的其他成员保持最新。在这种情况下，您可能会在队列中看到大量的事务。基于此信息，您可以决定从组中删除成员或延迟对组的其他成员的事务处理，从而减少排队的事务的数量。此信息还可以帮助您决定如何调整组复制插件的流控制。
Replication_group_members
|
Field |
Description |
|
Channel_name |
组复制通道名称 |
|
Member_id |
组成员的uuid |
|
Member_host |
组成员所在的主机 |
|
Member_port |
组成员的port |
|
Member_state |
组成员状态(包括 ONLINE, RECOVERING, OFFLINE or UNREACHABLE) |
Replication_connection_status
|
Field |
Description |
|
Channel_name |
组复制通道名称 |
|
Group_name |
组复制名称 |
|
Source_UUID |
显示组的标识符。它类似于组名称，并且用作组复制期间生成的所有事务的UUID。 |
|
Service_state |
显示成员是否是组的一部分。服务状态的可能值可以是{ON，OFF和CONNECTING}; |
|
Received_transaction_set |
已由该组的此成员接收gtid集合中的事务。 |
Replication_applier_status
|
Field |
Description |
|
Channel_name |
组通道名称 |
|
Service_state |
显示服务是关闭还是运行 |
|
Remaining_delay |
显示是否配置了一些应用程序延迟
|
|
Count_transactions_retries |
应用一个事务时执行的重试次数。
|
|
Received_transaction_set |
已由该组的此成员接收gtid集合中的事务。 |
Group Replication Server States
仅当view更改时，表replication_group_members才会更新，例如，当组的配置动态更改时。服务器实例可以处于多种状态。如果服务器正常通信，则所有服务器都报告相同的状态。但是，如果存在网络分区，或者服务器离开组，则可以报告不同的信息，这取决于查询哪个服务器。注意，如果服务器已经离开组，然而显然它不能报告关于其他服务器的状态的更新的信息。如果有一个分区，使得仲裁丢失，服务器不能在它们之间协调。因此，他们不能猜测不同服务器的状态。因此，不是猜测他们的状态，而是他们报告一些服务器不可达。
|
Field |
Description |
Group Synchronized |
|
ONLINE |
成员可以作为一个完全功能的组成员，这意味着客户端可以连接并开始执行事务。
|
Yes |
|
RECOVERING |
该成员正在成为该组的活跃成员，并且正在经历恢复过程，从同步源接收状态信息。
|
No |
|
OFFLINE |
插件已加载，但成员不属于任何组。
|
No |
|
ERROR |
本地节点的状态。只要恢复阶段或应用更改时出现错误，服务器就会进入此状态。
|
No |
|
UNREACHABLE |
每当本地故障检测器怀疑给定服务器不可达时，因为可能它已经崩溃或被不经意地断开，它显示服务器的状态为“不可达到”。
|
No |
请注意，组复制不是同步的，但最终是同步的。更确切地说，事务以相同的顺序传递给所有组成员，但是它们的执行不同步，这意味着在接受事务被提交之后，每个成员以其自己的速度提交。