简述mysql监控组复制

原文:https://dev.mysql.com/doc/refman/8.0/en/group-replication-monitoring.html
译者:kun
最近在翻译MySQL8.0官方文档 本文是第18.3“监控组复制”部分。

1.监控组复制

假设MySQL已经在启用了性能模式的情况下编译,使用Perfomance Schema表监控组复制。组复制添加以下表:

  • performance_schema.replication_group_member_stats
  • performance_schema.replication_group_members

这些现有的Perfomance Schema复制表也显示有关组复制的信息:

  • performance_schema.replication_connection_status 显示有关组复制的信息,例如,已从组接收并在应用程序队列中排队的事务(中继日志)。
  • performance_schema.replication_applier_status 显示与组复制相关的通道和线程的状态,如果有许多不同的工作线程应用事务,那么这个表也可用于监视每个工作线程正在执行的操作。

Group Replication插件创建的复制通道命名为:

  • group_replication_recovery - 此通道用于与分布式恢复阶段相关的复制更改。
  • group_replication_applier - 此通道用于来自组的传入更改。并且应用直接来自组的事务的通道。

以下部分描述了每个表中可用的信息。

2.组成员实例状态

组中的server实例可以处于多种状态。如果server都正常通信,则所有server都报告相同的状态。但是,如果存在网络分隔,或者组成员离开组,则可能报告不同的信息,这取决于查询了哪个server。要注意的是,如果某个组成员已经离开组,那么显然它不能报告关于其他server状态的最新信息。如果发生网络分隔,如果超出仲裁数量的server都断开了,那么server之间将不能相互协作。因此,他们无法得知不同server成员的状态。因此,他们会报告一些server不可访问,而不是猜测他们的状态。

Server State

Field 描述 组同步
ONLINE 该成员可以作为一个具有所有功能的组成员,这意味着客户端可以连接并开始执行事务。 yes
RECOVERING 该成员正在成为该组的有效成员,并且正处于恢复过程中,从数据源节点(数据源节点)接收状态信息。 no
OFFLINE 插件已加载,但成员不属于任何组。 no
ERROR 本地成员的状态。 只要恢复阶段或应用更改时出现错误,server就会进入此状态。 no
UNREACHABLE 每当本地故障检测器怀疑某个给定的server可能由于已经崩溃或被意外地断开而不可访问时,server的状态显示为“UNREACHABLE” no

Important
一旦实例进入ERROR状态后,该 super_read_only选项将设置为ON。要离开ERROR 状态,您必须手动配置实例super_read_only=OFF

需要注意的是,组复制不是同步复制,但最终是同步的。更确切地说,事务以相同的顺序传递给所有组成员,但是它们的执行不同步,这意味着在接受事务被提交之后,每个成员以其自己的速度提交。

3.replication_group_members表

performance_schema.replication_group_members 表用于监视作为组成员的不同server实例的状态。每当视图更改时,表replication_group_members就会更新,例如,当组的配置动态更改时。在此基础上,server成员之间交换他们的一些元数据以保持同步并继续协作。信息在组复制成员之间共享,因此可以从任何成员查询有关所有组成员的信息。此表可用于获取复制组状态的高级视图,例如通过发出:

SELECT * FROM performance_schema.replication_group_members;+---------------------------+--------------------------------------+--------------+-------------+--------------+-------------+----------------+| CHANNEL_NAME       | MEMBER_ID              | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION |+---------------------------+--------------------------------------+--------------+-------------+--------------+-------------+----------------+| group_replication_applier | 041f26d8-f3f3-11e8-adff-080027337932 | example1   |   3306  | ONLINE    | SECONDARY  | 8.0.13     || group_replication_applier | f60a3e10-f3f2-11e8-8258-080027337932 | example2   |   3306  | ONLINE    | PRIMARY   | 8.0.13     || group_replication_applier | fc890014-f3f2-11e8-a9fd-080027337932 | example3   |   3306  | ONLINE    | SECONDARY  | 8.0.13     |+---------------------------+--------------------------------------+--------------+-------------+--------------+-------------+----------------+

根据这个结果,我们可以看到该组由三个成员组成,每个成员的主机和端口号,客户端用来连接成员,以及成员的 server_uuid。该MEMBER_STATE列显示了 “组成员实例状态”之一,在该情况下,它显示该组中的所有三个成员都是 ONLINE,并且该MEMBER_ROLE 列显示有两个从节点和一个主节点。因此,该组必须是以单主模式运行的。MEMBER_VERSION当您升级组并且组合中正在运行不同MySQL版本的成员时,该列可能很有用。

4. Replication_group_member_stats

复制组中的每个成员都会验证并应用该组提交的事务。有关验证和应用程序的统计信息对于了解申请队列增长情况、触发了多少冲突、检查了多少事务、哪些事务已被所有成员提交等等非常有用。

performance_schema.replication_group_member_stats 表提供与认证过程相关的组级信息,以及由复制组的每个成员接收和发起的事务的统计信息。信息在组成员实例之间共享,因此可以从任何成员查询有关所有组成员的信息。请注意,刷新远程成员的统计信息由group_replication_flow_control_period 选项中指定的消息周期控制 ,因此这些信息可能与进行查询的成员的本地收集的统计信息略有不同。

表 replication_group_member_stats

field 描述
CHANNEL_NAME 组复制通道的名称。
VIEW_ID 此组的当前视图标识符。
Member_id 此值为我们当前连接到的server成员的UUID。组中的每个成员具有不同的值。因为它对每个成员是唯一的,所以它也成为了一个关键字。
Count_transactions_in_queue 队列中等待冲突检测检查的事务数。冲突检查通过后,他们排队等待应用。
Count_transactions_checked 表示已进行过冲突检查的事务数。
Count_conflicts_detected 表示未通过冲突检测检查的事务数。
Count_transactions_rows_validating 表示冲突检测数据库的当前大小(每个事务经过验证的数据库)。
Transactions_committed_all_members 表示已在当前视图的所有成员上成功提交的事务。 此值以固定的时间间隔更新。
Last_conflict_free_transaction 显示最后一个经检查无冲突的事务标识符。
Count_transactions_remote_in_applier_queue 此成员从复制组收到的等待应用的事务数。
Count_transactions_remote_applied 此成员从已应用的复制组收到的事务数。
Count_transactions_local_proposed 此成员发起并发送到复制组以进行协调的事务数。
Count_transactions_local_rollback 此成员发起的事务在发送到复制组后的回滚数。

这些字段对于监控组中的成员的性能很重要。例如,假设组的成员之一出现延迟,并且不能与该组的其他成员同步。在这种情况下,您可能会在队列中看到大量的事务。基于此信息,您可以决定从组中删除成员或延迟组中其他成员的事务处理,从而减少排队的事务的数量。此信息还可以帮助您决定如何调整组复制插件的流控制。

以上就是简述mysql监控组复制的详细内容,更多关于mysql监控组复制的资料请关注我们其它相关文章!

(0)

相关推荐

  • mysql索引使用率监控技巧(值得收藏!)

    概述 在关系数据库中,索引是一种单独的.物理的对数据库表中一列或多列的值进行排序的一种存储结构,它是某个表中一列或若干列值的集合和相应的指向表中物理标识这些值的数据页的逻辑指针清单. mysql中支持hash和btree索引.innodb和myisam只支持btree索引,而memory和heap存储引擎可以支持hash和btree索引 1.查看当前索引使用情况 我们可以通过下面语句查询当前索引使用情况: Handler_read_first 代表读取索引头的次数,如果这个值很高,说明全索引扫描

  • 详解MySQL 表中非主键列溢出情况监控

    今天,又掉坑了. 之前踩到过MySQL主键溢出的情况,通过prometheus监控起来了,具体见这篇MySQL主键溢出复盘 这次遇到的坑,更加的隐蔽. 是一个log表里面的一个int signed类型的列写满了.快速的解决方法当然还是只能切新表来救急了,然后搬迁老表的部分历史数据到热表. 亡羊补牢,处理完故障后,赶紧写脚本把生产的其他表都捋一遍. 下面是我暂时用的一个检测脚本,还不太完善,凑合用 分2个文件(1个sql文件,1个shell脚本) check.sql 内容如下: SELECT ca

  • 详解MySQL监控工具 mysql-monitor

    1.概述 mysql-monitor MYSQL 监控工具,优化工具,各种工具为一体的java spring boot 项目 git地址:https://github.com/lccbiluox2/mysql-monitor.git 2. 代码架构 3. 后端服务 后端服务的主类是com.neo.MySQLMointorApplication 3.1 后端服务的数据库 spring.datasource.driverClassName = com.mysql.jdbc.Driver spring

  • 关于对mysql语句进行监控的方法详解

    快速阅读 为什么要监控sql语句,以及如何监控,都有哪几种方式可以监控. 我们知道sql server 中有个工具叫sql profile ,可以实时监控sql server中 执行的sql 语句,以方便调试bug 或者确认最终生成的sql语句 为什么要监控sql语句? 因为程序大了以后,sql语句有可能被多个地方调用 .你不能确认当前时间是不是只执行了你需要的那条语句 . 有的持久层框架采用linq的语法来写sql , 程序中不方便输出sq语句 线上运行的程序,没有办法更改程序.但需要确认问题

  • MySQL数据库监控软件lepus使用问题以及解决办法

    在使用lepus3.7监控MySQL数据库的时候,碰到了以下几个问题,本博客给出了这些问题产生的原因,以及相应的解决办法. 1. 问题1:php页面无法连接数据库 直接使用php程序执行php文件,可以连接mysql,但是在httpd中同样的php页面无法连接mysql. lepus的web程序(PHP代码)无法连接数据库时,web界面上什么操作也无法继续. 为此编写了最简单的PDO连接测试代码: php代码如下: [x@coe2coe lepus]$ cat mysql.php <?php t

  • MySQL实时监控工具orztop的使用介绍

    前言 orztop是一款实时show full processlist的工具,我们可以实时看到数据库有哪些线程,执行哪些语句等.工具使用方便简单.解决了我们需要手动刷新show full processlist的痛苦. 该工具为朱旭开发的一款可以查看mysql数据库实时运行的sql状况的工具,以前苦于通过show processlist/show full processlist抓取sql的同志们现在只要盯一盯屏幕就可以了,使用方法也很简单,如下: orztop结果图 此处我正在对我的mysql

  • zabbix监控MySQL主从状态的方法详解

    搭建MySQL主从后,很多时候不知道从的状态是否ok,有时候出现异常不能及时知道,这里通过shell脚本结合zabbix实现监控并告警 一般情况下,在MySQL的从上查看从的运行状态是通过Slave_IO_Running线程和Slave_SQL_Running线程是否ok,通过命令"show slave status\G;"即可查看.所以这里根据这两个值进行判断. agent端脚本编写及配置 说明:所有zabbix相关的脚本我都放在了/etc/zabbix/script/ 目录里面,下

  • 实战模拟监控MySQL服务shell脚本小结

    1)端口判断法==>仅适合数据库本地使用 法1:if条件判断方法 [root@oldboy scripts]# cat check_db01.sh #!/bin/sh #created by oldboy #mail:oldboy521@gmail.com PortNum=`netstat -lnt|grep 3306|wc -l` if [ $PortNum -eq 1 ] then echo "mysqld is running." else echo "mysql

  • 安装配置Zabbix来监控MySQL的基本教程

    Zabbix的简单安装配置说明 1.在已有的LAMP或者LNMP的基础上安装zabbix,安装一些依赖包: yum -y install mysql-devel libcurl-devel net-snmp-devel 2.添加用户: groupadd zabbix useradd zabbix -g zabbix 3.创建数据库,添加授权账号 create database zabbix character set utf8; grant all privileges on zabbix.*

  • zabbix监控Nginx/Tomcat/MySQL的详细教程

    zabbix监控Nginx A机器:zabbix服务端(192.168.234.128) B机器:zabbix客户端(192.168.234.125) 在B机器(zabbix客户端)操作: 编辑nginx虚拟主机配置文件: [root@centos ~]# vi /etc/nginx/conf.d/default.conf 在server{}中添加以下内容: location /nginx_status { stub_status on; access_log off; allow 127.0.

  • 使用Grafana+Prometheus监控mysql服务性能

    Prometheus(也叫普罗米修斯)官网:https://prometheus.io/docs/introduction/overview/ Grafana官网:https://grafana.com/enterprise 特征 普罗米修斯的主要特点是: 具有由度量名称和键/值对标识的时间序列数据的多维数据模型 一个灵活的查询语言 来利用这一维度 不依赖分布式存储; 单个服务器节点是自治的 时间序列集合通过HTTP上的拉模型发生 推送时间序列通过中间网关支持 通过服务发现或静态配置发现目标 多

  • 利用Prometheus与Grafana对Mysql服务器的性能监控详解

    概述 Prometheus是一个开源的服务监控系统,它通过HTTP协议从远程的机器收集数据并存储在本地的时序数据库上.它提供了一个简单的网页界面.一个功能强大的查询语言以及HTTP接口等等.Prometheus通过安装在远程机器上的exporter来收集监控数据,这里用到了以下两个exporter: node_exporter – 用于机器系统数据 mysqld_exporter – 用于Mysql服务器数据 Grafana是一个开源的功能丰富的数据可视化平台,通常用于时序数据的可视化.它内置了

随机推荐