Chinaunix首页 | 黑桃棋牌官方网下载 | 博客
  • 博客访问: 342230
  • 博文数量: 35
  • 博客积分: 0
  • 博客等级: 民兵
  • 技术积分: 1734
  • 用 户 组: 普通用户
  • 注册时间: 2013-08-20 16:13
  • 个人简介

    中国科学院大学计算机硕士,曾在新浪爱彩数据库组带DBA团队,现居新加坡。wx: lihui_dba

    文章分类

    全部博文(35)

  • Python学习(1)
  • NOSQL(1)
  • Linux(5)
  • mysql高可用(1)
  • MySQL(17)
  • mysql调优(4)
  • 新技术(2)
  • 自动化运维(1)
  • 读书笔记(1)
  • mysql监控(1)
  • 未分配的博文(1)
  • 文章存档

    2020年(1)

    2019年(3)

    2017年(7)

    2016年(1)

    2015年(7)

    2014年(11)

    2013年(5)

    分类: Mysql/postgreSQL

    2020-02-05 11:48:33

    问题现象:

    早上收到zabbix的信息磁盘空间超过90%,登录到监控系统发现从1天前开始磁盘空间使用率急剧增长,直到触发zabbix的预警。
    在排查过程中发现master上的一张表(后续统一简称A表)的物理表空间超过了200多G,然而在slave上A表的物理表空间只有13G。

    问题排查:

    1.首先检查是不是最近两天有大量数据写入,检查binlog后发现和平时的增长量一致,并无异常。
    2.再检查此表是否存在大量的表碎片,检查结果发现没有。但是master和slave上的数据量有差异。
    show table status的结果显示master上A表大概有8亿多行数据,而slave上只有3kw。
    3.运行select count(*)检查A表的真实数据量,master和slave都是3kw行。说明master的table status结果不准确。
    4.检查slave上是否存在有replicate的filter,检查结果无。
    那为什么master和slave的数据量差异这么大,还无碎片?
    5.怀疑是大量并发的delete导致,于是运行pt-osc整理表空间。
    6.运行pt-osc时无法Creating triggers,到数据库中检查processlist发现一运行pt-osc就会产生MDL(metadata lock)锁。
    7.检查information_schema.innodb_trx发现有一个事务已经运行了2天。
    至此真相大白,找到相关的thread_id并kill,问题解决。
    在排查过程中还运行show processlist检查过正在运行的线程,看不到A表上有任何操作,这也是本次问题排查的难点。

    问题原因:

    由于事务没有完成,A表上的锁不会释放,获取不到metadata的独占锁,因此运行create trigger时出现Waiting for table metadata lock。

    注:因为是生产环境所以无法截图

    参考链接:
    https://www.cnblogs.com/digdeep/p/4892953.html
    阅读(6011) | 评论(0) | 转发(0) |
    给主人留下些什么吧!~~
    评论热议
    请登录后评论。

    登录 注册