组复制监控 | 全方位认识 MySQL 8.0 Group Replication

柔情只为你懂 2022-11-30 05:48 180阅读 0赞

作者  罗小波 · 数据库技术专家

出品  沃趣科技

![format_png][]

## 假设已启用performance\_schema(performance\_schema=ON)，那么我们可以使用performance\_schema下的表来监控组复制的运行状态。    ##

##  ##

*  ## 监控组成员同步事务的状态以及组成员自身的状态表。 ##
    
    ## \*performance\_schema.replication\_group\_member\_stats：记录组成员各自同步数据的状态信息。 ##
    
    ## \*performance\_schema.replication\_group\_members：记录组成员本身的状态信息。 ##
 *  ## 监控由MGR插件创建的两个组复制专用通道group\_replication\_recovery和group\_replication\_applier相关的状态表（这些表在主从复制拓扑中也用于记录从库复制线程的状态信息）。 ##
    
    ## \*performance\_schema.replication\_connection\_status：记录从组中接受到的且在applier队列（中继日志）中排队的事务（单主模式下，对于主要节点，该表中只有一行组复制通道group\_replication\_applier的状态记录。对于辅助节点，即复制远端事务的组成员，此表中会多一行组复制通道group\_replication\_recovery的状态记录），可以理解为主从复制拓扑中，IO线程的位置信息。 ##
    
    ## \*performance\_schema.replication\_applier\_status：记录组复制的专用复制通道group\_replication\_recovery和group\_replication\_applier本身的状态信息（同样，单主模式下，对于主要节点，该表中只有一行组复制通道group\_replication\_applier的状态记录。对于辅助节点，即复制远端事务的组成员，此表中会多一行复制通道group\_replication\_recovery的状态记录），可以理解为主从复制拓扑中，IO线程的状态信息。 ##
 *  ## 监控关于两个组复制专用通道group\_replication\_recovery和group\_replication\_applier中接受的并正在进行分发与应用的事务状态表。 ##
    
    ## \*performance\_schema.replication\_applier\_status\_by\_coordinator：记录SQL协调器线程分发事务相关的状态（单主模式下，对于主要节点，该表中只有一行组复制通道group\_replication\_applier的状态记录。对于辅助节点，即复制远端事务的组成员，此表中会多一行组复制通道group\_replication\_recovery的状态记录）。 ##
    
    ## \*performance\_schema.replication\_applier\_status\_by\_worker：记录worker线程应用事务相关的状态（单主模式下，对于主要节点，该表中只有组复制通道group\_replication\_applier的记录，但具体的行数由系统变量slave\_parallel\_workers定义值决定。对于辅助节点，即复制远端事务的组成员，此表中会多记录组复制通道group\_replication\_recovery对应的记录，该通道记录的行数仍然由系统变量slave\_parallel\_workers定义值决定）。 ##
 *  ## PS：关于组复制专用通道： ##
    
    ## \*group\_replication\_recovery：此通道用于与分布式恢复阶段复制相关的变更数据 。 ##
    
    ## \*group\_replication\_applier：此通道用于组状态正常的情况下，复制（接收）来自组的变更数据。 ##

##  ##

##     ##

## ***3.1. 组复制成员状态*** ##

## 组复制的组成员存在多种有效预设状态值。如果所有组成员之间的通信正常，则所有组成员都能报告相同的状态。但是，如果存在网络分区，或者有成员脱离了组，则可能会报告不同的状态信息。具体来说，如果我们查看一个已经脱离组的Server，则由于它已经脱离了组，所以无法报告关于其他组成员状态的更新信息。如果存在分区，导致仲裁失效（活跃成员数量低于了总成员数量的半数），则组成员相互之间就不能够交换状态信息。此时组状态仍然不正常，不同的组成员上查看到的自身状态可能各不相同，但，如果只有少数成员发生故障，活跃成员占多数，则，除了脱离组的Server之外，其他剩余活跃成员中看到的所有组的成员都能够报告相同的状态。 ##

## 关于组成员的有效状态列表及其对应的含义如下表。 ##

<table> 
 <thead> 
 <tr> 
 <th>状态值</th> 
 <th>状态描述</th> 
 <th>是否与组保持同步</th> 
 </tr> 
 </thead> 
 <tbody> 
 <tr> 
 <td>ONLINE</td> 
 <td>表示该成员已经准备好作为一个功能齐全的组成员（活跃成员），这意味着该成员可以正常接受客户端的访问（单主模式下，主要节点可接受读写访问，&nbsp; 辅助节点只可接受只读访问；多主模式下，所有成员都是主要节点，都可以接受读写访问）。</td> 
 <td>是</td> 
 </tr> 
 <tr> 
 <td>RECOVERING</td> 
 <td>表示该成员正在成为该组的活跃成员，目前正在恢复过程中，正在接受来自donor节点的状态转移数据。</td> 
 <td>否</td> 
 </tr> 
 <tr> 
 <td>OFFLINE</td> 
 <td>表示该Server已加载了MGR插件，但此时Server不属于任何组。</td> 
 <td>否</td> 
 </tr> 
 <tr> 
 <td>ERROR</td> 
 <td>表示该成员处于错误状态，不能作为任何组的成员正常工作。如果该Server曾经成功加入过组一次，后续发生任何故障，&nbsp; 则会根据系统变量group_replication_exit_state_action设置的在退出操作（默认值为READ_ONLY）时执行不同的调整，使得成员在执行退出之后所处的状态可能不同。&nbsp; 如果设置为READ_ONLY，则该成员退出时处于只读模式(super_read_only= on)，成员状态可能可能为OFFLINE；&nbsp; 如果设置为OFFLINE_MODE，则该成员退出时处于脱机模式(offline_mode= on, super_read_only= on )，此时成员状态为ERROR，而不是OFFLINE状态。&nbsp; 如果设置为ABORT_SERVER，则该成员在意外脱离组并耗尽了重新加入组的尝试次数之后，数据库的实例进程将被自动关闭，并从组的视图中删除该成员。</td> 
 <td>否</td> 
 </tr> 
 <tr> 
 <td>UNREACHABLE</td> 
 <td>当本地故障检测器怀疑某个给定的成员不可访问时(例如，由于非自愿与组断开了连接时)，将显示该成员的状态为UNREACHABLE。</td> 
 <td>否</td> 
 </tr> 
 </tbody> 
</table>

##     ##

## ***3.2. performance\_schema.replication\_group\_members表*** ##

##     ##

## performance\_schema.replication\_group\_members表用于监控组中的不同成员实例的状态。每当视图发生更改时，表中的信息就会更新，例如：当有新成员加入组动态更改组的配置时，组成员之间交换它们的一些元数据来同步协作结果并保持持续协作。这些信息在属于组中的所有成员之间共享，因此，可以从组中的任何活跃成员查询到一致性的关于所有组成员的信息。如下： ##

## 根据这个结果，我们可以看到这个组由三个成员组成、每个成员的主机和端口号(客户端用来连接到该成员的SQL访问端口，非组成员内部的通讯端口)、以及该成员的server\_uuid、MEMBER\_STATE列显示组中所有成员都为ONLINE状态、MEMBER\_ROLE列显示组中有两个辅助节点和一个主要节点（表示该组运行在单主模式下）、MEMBER\_VERSION列显示每个组成员运行的MySQL Server版本（这在对组复制拓扑做升级操作时非常有用）。 ##

## PS：有关Member\_host列值及其对分布式恢复过程的影响的更多信息，请参见上文中“2.1.3. 用户凭证”部分。 ##

#### ***3.3. performance\_schema.replication\_group\_member\_stats表*** ####

####     ####

#### 组复制中的每个成员都会各自对从组中接受的事务进行冲突认证检测，然后进行应用。该表中记录了有关从组中接受事务以及应用事务相关的统计信息，这些统计信息对于了解applier队列如何增长、发现了多少冲突事务、验证了多少事务、在什么地方提交了哪些事务等等都很有用。 ####

*  #### performance\_schema.replication\_group\_member\_stats表提供与认证过程相关的组级别统计信息，还提供组复制中每个成员接收和发起的事务的统计信息。这些信息在组中所有成员之间共享，因此可以从任何组成员查询到关于所有组成员的统计信息。注意，远程成员中的统计信息刷新频率由系统变量group\_replication\_flow\_control\_period指定，因此，这些统计信息可能与在发起事务（本地事务）的组成员中查询到的统计信息略有不同。此表中记录的组成员状态信息类似如下： ####

root@localhost : (none):07: > SELECT * FROM performance_schema.replication_group_member_stats\G
    *************************** 1. row ***************************
                              CHANNEL_NAME: group_replication_applier
                                   VIEW_ID: 15692965051216743:7
                                 MEMBER_ID: 2d283e92-de7b-11e9-a14d-525400c33752
               COUNT_TRANSACTIONS_IN_QUEUE: 0
                COUNT_TRANSACTIONS_CHECKED: 342710
                  COUNT_CONFLICTS_DETECTED: 0
        COUNT_TRANSACTIONS_ROWS_VALIDATING: 0
        TRANSACTIONS_COMMITTED_ALL_MEMBERS: 320675e6-de7b-11e9-b3a9-5254002a54f2:1-4,
    aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:1-342718
            LAST_CONFLICT_FREE_TRANSACTION: aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:342718
    COUNT_TRANSACTIONS_REMOTE_IN_APPLIER_QUEUE: 0
         COUNT_TRANSACTIONS_REMOTE_APPLIED: 342711
         COUNT_TRANSACTIONS_LOCAL_PROPOSED: 0
         COUNT_TRANSACTIONS_LOCAL_ROLLBACK: 0
    *************************** 2. row ***************************
                              CHANNEL_NAME: group_replication_applier
                                   VIEW_ID: 15692965051216743:7
                                 MEMBER_ID: 2e33b2a7-de7b-11e9-9a21-525400bdd1f2
               COUNT_TRANSACTIONS_IN_QUEUE: 0
                COUNT_TRANSACTIONS_CHECKED: 342710
                  COUNT_CONFLICTS_DETECTED: 0
        COUNT_TRANSACTIONS_ROWS_VALIDATING: 0
        TRANSACTIONS_COMMITTED_ALL_MEMBERS: 320675e6-de7b-11e9-b3a9-5254002a54f2:1-4,
    aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:1-342718
            LAST_CONFLICT_FREE_TRANSACTION: aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:342718
    COUNT_TRANSACTIONS_REMOTE_IN_APPLIER_QUEUE: 0
         COUNT_TRANSACTIONS_REMOTE_APPLIED: 342710
         COUNT_TRANSACTIONS_LOCAL_PROPOSED: 0
         COUNT_TRANSACTIONS_LOCAL_ROLLBACK: 0
    *************************** 3. row ***************************
                              CHANNEL_NAME: group_replication_applier
                                   VIEW_ID: 15692965051216743:7
                                 MEMBER_ID: 320675e6-de7b-11e9-b3a9-5254002a54f2
               COUNT_TRANSACTIONS_IN_QUEUE: 0
                COUNT_TRANSACTIONS_CHECKED: 342713
                  COUNT_CONFLICTS_DETECTED: 0
        COUNT_TRANSACTIONS_ROWS_VALIDATING: 0
        TRANSACTIONS_COMMITTED_ALL_MEMBERS: 320675e6-de7b-11e9-b3a9-5254002a54f2:1-4,
    aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:1-342718
            LAST_CONFLICT_FREE_TRANSACTION: aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:342718
    COUNT_TRANSACTIONS_REMOTE_IN_APPLIER_QUEUE: 0
         COUNT_TRANSACTIONS_REMOTE_APPLIED: 4
         COUNT_TRANSACTIONS_LOCAL_PROPOSED: 342713
         COUNT_TRANSACTIONS_LOCAL_ROLLBACK: 0
    3 rows in set (0.01 sec)

#### 上述查询到的组成员状态信息对于监控组中活跃成员（已建立组通讯连接的成员）的性能非常重要。例如：假设与其他成员相比，组中的某个成员的状态中总是发现队列中存在大量事务。这意味着该成员可能存在大量事务延迟，无法与组中的其他成员保持数据同步。根据这些信息，可以决定是否需要从组中删除该成员，或者延迟处理组中其他成员的事务，以减少队列中的事务数量。这些信息还可以帮助确定如何调整MGR插件的流控阈值，更详细的信息请参见"6.2. 流量控制"。 ####

**| 作者简介**

### **罗小波·数据库技术专家** ###

《千金良方——MySQL性能优化金字塔法则》作者之一。熟悉MySQL体系结构，擅长数据库的整体调优，喜好专研开源技术，并热衷于开源技术的推广，在线上线下做过多次公开的数据库专题分享，发表过近100篇数据库相关的研究文章。

**延伸阅读**

*  [组复制安装部署 | 全方位认识 MySQL 8.0 Group Replication][_ _ MySQL 8.0 Group Replication]  
    
 *  [组复制背景 | 全方位认识 MySQL 8.0 Group Replication][_ _ MySQL 8.0 Group Replication 1]

全文完。

Enjoy MySQL 8.0 :)

--------------------

叶老师的「MySQL核心优化」大课已升级到MySQL 8.0，扫码开启MySQL 8.0修行之旅吧

![format_png 1][]

[format_png]: /images/20221124/a5e30aee7ca44d57a5e74a4339b57b22.png
[_ _ MySQL 8.0 Group Replication]: http://mp.weixin.qq.com/s?__biz=MjM5NzAzMTY4NQ%3D%3D&chksm=bd3b48ab8a4cc1bdacaa1129312843efdf7f827ac0ec91a3dabd4df61f0bbd01665f8ee4d010&idx=1&mid=2653934273&scene=21&sn=1350a045c71b0f1c45b624854b5b43f0#wechat_redirect
[_ _ MySQL 8.0 Group Replication 1]: http://mp.weixin.qq.com/s?__biz=MjM5NzAzMTY4NQ%3D%3D&chksm=bd3b48c48a4cc1d293c93e6a0ff69ecba1cf684c59ce91643360083f4fc0ecd783292adbd514&idx=1&mid=2653934254&scene=21&sn=47ce9952fdf8e5a21325d9384a18d4a4#wechat_redirect
[format_png 1]: /images/20221124/77a546d219824faf9b541e2cbeed7809.png