监控MySQL组复制

使用 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

注意，组复制是非同步的，但会达到最终的同步(译注：即最终一致性，强一致性)。更准确地说，事务按照相同的顺序投递到全部的成员上，可是它们每一个节点对事务的执行非同步的，意味着在容许事务的提交后，每一个成员按照它们本身的步调来执行事务。