使用prometheus统计MySQL自增主键的剩余可用百分比

最近生产环境一套数据库因为疯狂写日志数据，造成主键值溢出的情况出现，因此有必要将这个指标监控起来。

mysqld_exporter自带的这个功能，下面是我使用的启动参数：

nohup ./mysqld_exporter --config.my-cnf="./my.cnf" --web.listen-address=":9104" --collect.heartbeat --collect.auto_increment.columns --collect.binlog_size --collect.engine_innodb_status --collect.engine_tokudb_status --collect.slave_hosts --collect.slave_status --collect.info_schema.processlist --collect.info_schema.innodb_metrics > /dev/null 2>&1 &

红色高亮的参数，就是用来采集到自增id的使用情况的。

实际上执行的类似这个SQL：

SELECT
 table_schema,
 table_name,
 column_name,
 AUTO_INCREMENT,
 POW(2, CASE data_type
   WHEN 'tinyint'  THEN 7
   WHEN 'smallint' THEN 15
   WHEN 'mediumint' THEN 23
   WHEN 'int'    THEN 31
   WHEN 'bigint'  THEN 63
   END+(column_type LIKE '% unsigned'))-1 AS max_int
  FROM information_schema.tables t
   JOIN information_schema.columns c USING (table_schema,table_name)
  WHERE
   c.extra = 'auto_increment'
  AND
   t.TABLE_SCHEMA NOT IN ('information_schema','mysql', 'sys','test','performance_schema')
  AND
   t.auto_increment IS NOT NULL ;

在prometheus的web界面，我们可以测试编写如下的promql， 找出剩余自增id可以率少于40%的实例的库+表名

(mysql_info_schema_auto_increment_column_max{schema!~'test|mysql'} - mysql_info_schema_auto_increment_column{schema!~'test|mysql'})/mysql_info_schema_auto_increment_column_max{schema!~'test|mysql'}*100 < 40

取到数据后，我们可以在alertmanager里面配置相关的告警，或者再grafana上面绘制图，如下：

到此这篇关于使用prometheus统计MySQL自增主键的剩余可用百分比的文章就介绍到这了,更多相关prometheus统计MySQL自增主键内容请搜索我们以前的文章或继续浏览下面的相关文章希望大家以后多多支持我们！

赞 (0)

相关推荐

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

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

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

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

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

  • 使用prometheus统计MySQL自增主键的剩余可用百分比

    最近生产环境一套数据库因为疯狂写日志数据,造成主键值溢出的情况出现,因此有必要将这个指标监控起来. mysqld_exporter自带的这个功能,下面是我使用的启动参数: nohup ./mysqld_exporter --config.my-cnf="./my.cnf" --web.listen-address=":9104" --collect.heartbeat --collect.auto_increment.columns --collect.binlog

  • Mysql自增主键id不是以此逐级递增的处理

    Mysql自增主键id不是以此逐级递增的处理

    Mysql自增主键id不是以此逐级递增 一.介绍 在mysql数据库添加数据时使用ON DUPLICATE KEY UPDATE进行数据更新时可能会出现id不是逐级以此递增的,而是间断递增. 如id从10下次添加可能就是15或者其他的数字,两个数字之间间隔是ON DUPLICATE KEY UPDATE执行的次数,也就是说ON DUPLICATE KEY UPDATE在执行更新的时候把该表主键进行自增加一. 如图所示 二.问题介绍 在对于同一个表进行新增和修改时我用了两个mapper接口方法,也

  • 详解MySQL自增主键的实现

    详解MySQL自增主键的实现

    目录 一.自增值保存在哪儿? 二.自增值修改机制 三.自增值的修改时机 四.自增锁的优化 五.自增主键用完了 一.自增值保存在哪儿? 不同的引擎对于自增值的保存策略不同 1.MyISAM引擎的自增值保存在数据文件中 2.InnoDB引擎的自增值,在MySQL5.7及之前的版本,自增值保存在内存里,并没有持久化.每次重启后,第一次打开表的时候,都会去找自增值的最大值max(id),然后将max(id)+步长作为这个表当前的自增值 select max(ai_col) from table_name

  • 为什么mysql自增主键不是连续的

    为什么mysql自增主键不是连续的

    目录 一 前言 二 自增值存储说明 三 自增值修改机制 四 自增值修改时机 五 导致自增值不连续的原因 5.1 唯一键冲突 5.2 事务回滚 5.3 批量写库操作 六 参考文档 一 前言 提出这个问题,是因为在工作中发现 mysql 中的 user 表的 id 默认是自增的,但是数据库存储的结果却不是连续的. user 表结构: CREATE TABLE `user` ( `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT COMMENT '递增id

  • 面试官问订单ID是如何生成的?难道不是MySQL自增主键

    一个美女面试官坐到我的对面,发光logo的MacBook也挡不住她那圆润可爱的脸庞. 程序媛本就稀有,美女面试官更是难寻. 这么温柔可爱的面试官,应该不会为难我吧.嗯,应该是的,毕竟我这么帅气,面试可能就是走个过场.美女面试官是不是单身?毕竟程序员都不善交流,因为我也是单身,难道我的姻缘就在此注定.孩子的名字我都想好了.一冰!好名字. 面试官: 小伙子,你低着头笑什么呐.开始面试了,你知道订单ID是怎么生成的吗? 啥?订单ID怎么生成?美女怎么不按套路出牌!HashMap实现原理,我已经倒背如流

  • 浅谈MySQL中的自增主键用完了怎么办

    在面试中,大家应该经历过如下场景 面试官:"用过mysql吧,你们是用自增主键还是UUID?" 你:"用的是自增主键" 面试官:"为什么是自增主键?" 你:"因为采用自增主键,数据在物理结构上是顺序存储,性能最好,blabla-" 面试官:"那自增主键达到最大值了,用完了怎么办?" 你:"what,没复习啊!!"    (然后,你就可以回去等通知了!) 这个问题是一个粉丝给我提的,我觉得

  • 深入谈谈MySQL中的自增主键

    深入谈谈MySQL中的自增主键

    MySQL的主键可以是自增的,那么如果在断电重启后新增的值还会延续断电前的自增值吗?自增值默认为1,那么可不可以改变呢?下面就说一下 MySQL的自增值. 特点 保存策略 1.如果存储引擎是 MyISAM,那么这个自增值是存储在数据文件中的: 2.如果是 InnoDB引擎,1)在 5.6之前是存储在内存中,没有持久化,在重启后会去找最大的键值,举个例子,如果一个表当前数据行里最大 id是10,AUTO_INCREMENT=11.这时候,我们删除 id=10 的行,AUTO_INCREMENT 还

  • MySQL8自增主键变化图文详解

    MySQL8自增主键变化图文详解

    目录 一.简述 二.MySQL自增主键 为什么MySQL8新特性会修改自增主键属性? 如何解决自增主键冲突问题? 三.自增主键测试 1.MySQL5.7自增主键 2.MySQL8自增主键 总结 一.简述 MySQL版本从5直接大跃进到8,相信MySQL8一定会有很多令人意想不到的改进,如果不想只会CRUD可以看看. 比如系统表引擎的变化-全部换成事务型的InnoDB. MySQL5.7系统部引擎 MySQL8系统引擎 上图可以看到,MySQL5.7的系统表引擎有MEMORY.InnnoDB和My

  • Mysql主键UUID和自增主键的区别及优劣分析

    Mysql主键UUID和自增主键的区别及优劣分析

    引言 之前有段时间用postgresql 数据库,在上云之后,从自增主键变为uuid,感觉uuid全球唯一,很方便. 最近用mysql,发现mysql主键都是选择自增主键,仔细比较一下,为什么mysql选择自增主键,有什么不同. 在mysql5.0之前,如果是多个master复制的环境,无法用自增主键,因为可能重复.在5.0以及之后的版本通过配置自增偏移量解决了整个问题. 什么情况下我们希望用uuid 1. 避免重复,便于scale,这就是我们做cloud service的时候选择uuid的主要

  • Mysql更新自增主键id遇到的问题

    Mysql更新自增主键id遇到的问题

    目录 为什么要更新自增id 问题 如何解决 本是一个自己知道的问题,还是差点踩坑(差点忘了,还好上线前整理上线点时想起来了),特此记录下来 为什么要更新自增id 我是因为历史业务上的坑,导致必须更新一批id,且为了避免冲突需要将id扩大多少倍进行更新,因为我这个表的数据数量不高,属于高读低写的情况,所以就简单的扩大了1000 问题 MySQL中如果我们把自增主键更新为更大的值(例如现在自增id最大值是1000,你更新id=49这个记录到id=1049),MySQL并不会把表的自增值修改为更新后的

随机推荐