关于mysql:MySQL关于MGR中监控的两个重要指标简析

3次阅读

共计 5385 个字符，预计需要花费 14 分钟才能阅读完成。

欢送来到 GreatSQL 社区分享的 MySQL 技术文章，如有疑难或想学习的内容，能够在下方评论区留言，看到后会进行解答

转载申明：以下文章来源于 MySQL 学习，作者八怪（高鹏）

这两个指标就是 replication_group_member_status 视图中的

COUNT_TRANSACTIONS_IN_QUEUE：期待抵触验证的队列数量，实际上是进行 pipeline 解决的队列数量（外部示意 m_transactions_waiting_certification），单位为事务数量。
COUNT_TRANSACTIONS_REMOTE_IN_APPLIER_QUEUE：期待利用的队列数量（外部示意 m_transactions_waiting_apply），单位为事务数量。

这两个值，特地是第二个咱们通常用于在单主模式下，作为判断是否提早的规范。本文就是来解释一下这两个指标具体的含意。

实际上这两个信息实际上次要是供流控应用的，次要来自本地节点和远端节点 pipeline 的信息。那么远端的信息是如何获取到的呢？实际上在咱们的 MGR 线程中有一个叫做 Certifier_broadcast_thread::dispatcher 的线程，这个线程发送本地的 pipeline 信息给远端节点。这个线程次要实现的工作蕴含：

30 秒设置一次

设置 send_transaction_identifiers = true，这个值次要用于在构建 Pipeline_stats_member_message 类型音讯的时候是否蕴含 gtid 信息。这些 GTID 信息次要是蕴含 committed_transactions 和 last_conflict_free_transaction。这些信息同样会在 replication_group_member_status 中进行体现，也就是咱们看到的 TRANSACTIONS_COMMITTED_ALL_MEMBERS 和 LAST_CONFLICT_FREE_TRANSACTION。

每秒进行构建 Pipeline_stats_member_message 类型的音讯（type CT_PIPELINE_STATS_MEMBER_MESSAGE），并且发送给远端节点。其中蕴含了咱们上述的 2 个重要指标也就是 m_transactions_waiting_certification/m_transactions_waiting_apply.

COUNT_TRANSACTIONS_IN_QUEUE（m_transactions_waiting_certification）实际上这是 appler 线程进行 pipeline 解决的队列数量，来自于 applier_module->get_message_queue_size()，一旦解决实现就会写入到 relay log，相应的队列也会出队。理论它的入队是 xcom engine 线程进行的 push 操作。一旦写入 relay log 后就会进行 pop 解决，队列数量也会缩小。参考 Applier_module::applier_thread_handle 处 applier 线程解决的流程。因而并不是单主就不会有抵触验证队列，一样是有的，只是解决要快于多主，因为任何事务的 event 都须要进行 pipeline 解决，其中蕴含了抵触验证、GTID 生成、写入 relay log 等操作。
COUNT_TRANSACTIONS_REMOTE_IN_APPLIER_QUEUE（m_transactions_waiting_apply）来自于 m_transactions_waiting_apply.load()，这个值在 Applier_handler::handle_event 函数减少，当 pipeline 的 Applier_handler 解决实现，也就是写入了 relay log 后减少。这个值在 hook group_replication_trans_before_commit 处进行缩小，函数首先就会判断提交的事务是不是来自 applier 通道，如果是则进行缩小。当然如果是主库咱们事务提交是前台线程本人，而不是 applier 通道，所以不会影响这个值。

 简略的写入 relay log 的逻辑和指标减少逻辑：error = channel_interface.queue_packet((const char *)p->payload, p->len); // 写入 relay log 调用仍旧为 queue event

    if (event->get_event_type() == binary_log::GTID_LOG_EVENT &&
        local_member_info->get_recovery_status() ==
            Group_member_info::MEMBER_ONLINE) {applier_module->get_pipeline_stats_member_collector()
          ->increment_transactions_waiting_apply(); // 减少期待利用

当然本音讯中蕴含了所有 replication_group_member_status 的指标，这里简略列举如下：

m_transactions_certified.load()
       这个值在认证最初进行更新，用于统计以后认证了多少工作，当然这里只是通过了
       Certifier::certify 的事务的个数，因而单主也会有这个值。m_transactions_applied.load()
       曾经利用的事务，这个值在 hook group_replication_trans_before_commit 处进行减少
       首先就会判断提交的事务是不是来自 applier 通道，如果是则进行减少
m_transactions_local.load()
       本地事务的数量，这个值在 hook group_replication_trans_before_commit 处进行减少
       在 group_replication_trans_before_commit 中会判断提交的事务到底是 applier 通道过的
       sql 线程还是前台 session，如果是前台 session 则减少
(cert_interface != nullptr) ? cert_interface->get_negative_certified(): 0
       抵触认证操作失败的事务数量
(cert_interface != nullptr) ? cert_interface->get_certification_info_size(): 0
       抵触认证数据库的大小
send_transaction_identifiers
       30 秒一次设置为 true，是否发送了本地相干的 GTID 信息
committed_transactions
       全局提交的事务的 gtid 信息，这里这个信息 30 秒发送一次，次要来自于
       为 CT_CERTIFICATION_MESSAGE 音讯后处理的所有节点执行 GTID 事务的交加
last_conflict_free_transaction
        最初一次没有抵触的事务数量
m_transactions_local_rollback.load()
        因为抵触认证，本地须要回滚的事务数量
mode
        是否开启了流量管制

而后会依据是否开启流控进行综合各个节点的 pipeline 信息，进行流控指标的计算，如果一旦计算出须要进行流控解决，则事务须要在 group_replication_trans_before_commit 处进行流控期待。

每 60 秒进行

发送本节点的 GTID_EXECUTED 给远端节点，这个次要用于抵触验证数据库的清理和计算全局提交的 GTID 信息，发送类型为 Gtid_Executed_Message，type 为 CT_CERTIFICATION_MESSAGE 调用 gcs_module->send_message(gtid_executed_message, true); 发送音讯因而 replication_group_member_status 中的 GTID 信息并不是很及时，有至多 60 秒，最多 120 秒的提早，然而其余信息还是比拟及时的，然而也不是实时同步的。

实际上这个次要是当 xcom engine 线程发送音讯给 applier 线程后，apllier 线程会进行一些解决如下是远端节点收到事务信息后进行的 pipeline 解决：

这里的 event_cataloger–>certification_handler–>applier_handler 进行的解决就是所谓的 applier 通道的 pipeline。当然如果是本地事务，则不须要写入到 relay log，然而其余流程还是须要的。

这部分信息次要装载逻辑如下：

ha_perfschema::rnd_next
 ->table_replication_group_member_stats::rnd_next 
   读取数据
   ->table_replication_group_member_stats::make_row
 ->PFS_engine_table::read_row
   获取值，这里就是相应的对应关系
   ->table_replication_group_member_stats::read_row_values

其中 table_replication_group_member_stats::make_row 就是读取咱们下面说的这些信息，而 table_replication_group_member_stats::read_row_values 则是转换为咱们 DBA 可见的模式。这两个指标如下：

  case 3: /** transaction_in_queue */
          set_field_ulonglong(f, m_row.trx_in_queue);
          break;
...
        case 9:
          set_field_ulonglong(f, m_row.trx_remote_applier_queue);

其实也就是咱们下面说的 m_transactions_waiting_certification 和 m_transactions_waiting_apply。然而咱们须要留神的是这里获取的时候分为了本地节点和远端节点。在 get_group_member_stats 有如下逻辑：

 如果是本地 UUID 则
            -> applier_module->get_local_pipeline_stats()
 如果是远端 UUID 则
            -> applier_module->get_flow_control_module()->get_pipeline_stats
              (member_info->get_gcs_member_id().get_member_id()))

而远端节点的信息正是来自于各个节点 broadcast 线程的发送。对于单主模式的主节点来讲：

m_transactions_waiting_apply：失常状况下应该维持为 0，因为本地事务不会写到 relay log。非凡状况除外。
m_transactions_waiting_certification：每个节点都能够不为 0，因为过抵触验证和 GTID 生成是不能防止的。

具体逻辑在 Certification_handler::handle_transaction_id 中对本地事务和远端事务处理的分支上。

Enjoy GreatSQL :)

GreatSQL MGR FAQ
https://mp.weixin.qq.com/s/J6…

万答 #12，MGR 整个集群挂掉后，如何能力主动选主，不必手动干涉
https://mp.weixin.qq.com/s/07…

『2021 数据技术嘉年华·ON LINE』：《MySQL 高可用架构演进及实际》
https://mp.weixin.qq.com/s/u7…

一条 sql 语句慢在哪之抓包剖析
https://mp.weixin.qq.com/s/AY…

万答 #15，都有哪些状况可能导致 MGR 服务无奈启动
https://mp.weixin.qq.com/s/in…

技术分享 | 为什么 MGR 一致性模式不举荐 AFTER
https://mp.weixin.qq.com/s/rN…

GreatSQL 是由万里数据库保护的 MySQL 分支，专一于晋升 MGR 可靠性及性能，反对 InnoDB 并行查问个性，是实用于金融级利用的 MySQL 分支版本。

Gitee:
https://gitee.com/GreatSQL/Gr…

GitHub:
https://github.com/GreatSQL/G…

Bilibili：
https://space.bilibili.com/13…

微信 &QQ 群：
可搜寻增加 GreatSQL 社区助手微信好友，发送验证信息“加群”退出 GreatSQL/MGR 交换微信群

QQ 群：533341697
微信小助手：wanlidbc

本文由博客一文多发平台 OpenWrite 公布！

正文完

mysql

发表至： mysql

2021-12-27

0

关于mysql:MySQL中的事务

关于mysql:MySQL连接数管理

关于mysql:MySQL索引下推原来这么简单

关于mysql:万答20索引下推如何进行数据过滤

关于nginx:使用-Nginx-构建前端日志统计服务

关于mysql:MySQL关于MGR中监控的两个重要指标简析

一、两个重要的指标

二、相干起源和 broadcast 线程

三、applier 通道的 pipeline

四、对于 replication_group_member_status 信息的装载

文章举荐：

对于 GreatSQL

站内搜索