未分類
12 12 月 2020

mysql 数据库磁盘巨量占用惊魂

mysql 数据库磁盘巨量占用惊魂

資深大佬 : kaka6 9

一、事由：主力 Mysql 数据突然巨量占满空间而停摆

空间占满 100G 后，再度占满 170G，冒了一阵冷汗，以为受攻击，如下图

mysql 数据库磁盘巨量占用惊魂

二、时间点回顾

  1. 15 点，发现数据库占满 100G 空间，查了实际数据库文件大小才 11G
  2. 虽觉意外，为恢复正常，还是先加空间（还好是 RDS 云数据库，硬盘扩展方便）
  3. 空间加到 170G，数据库恢复正常，然后就找日志表来清，想缩减下空间占用
  4. 删除了不少日志表(使用 truncate 清表)，也看到空间占用微微在下降
  5. 还有一张千成级的日志表，准备要清掉，结果开发说，要留下本月的数据，于是就用 delete+optimize 方式 : delete from ###_logs where id < ####, 结果十几分钟没有结果返回
  6. 最后跟开发协调，还是把这张表全清了，还是用 truncate 清表，瞬间清掉了
  7. 查看数据库的空间占用，好像没降多少空间
  8. 大概过了十几分钟，进入数据库面板，发现空间再度被占满，有点急了，第一反应是不是被攻击了
  9. 查数据库文件，还是 11G，那为什么会占满 170G
  10. 于是又再次增加空间，并关掉远程连接，把疑似问题账号关了
  11. 重启数据库
  12. 结果数据库空间占用回到 20G， 一切又正常了

三、事故排查

  1. 是否受攻击：仔细看了网络连接情况，正常，排除了攻击
  2. 慢查询监控：近期有不少慢查询记录，估计慢查询会产生 temp 临时文件
  3. 数据库实例两年多没有重启过，网上说 mysql5.7 默认情况，不重启的话，临时文件会一直累积
  4. 千万级表 delete 产生大量临时文件
  5. 重启 mysql 实例是最有效的清临时文件方式
大佬有話說 (14)

  • 資深大佬 : hbolive

    如果是偶尔的，估计是某个操作导致慢查询产生巨量临时文件。。

  • 資深大佬 : angeltop

    检查检查临时表大小

  • 資深大佬 : neocanable

    innodb 的话，把 innodb_file_per_table 打开了吧，这样的话 truncate 才会起作用

  • 主 資深大佬 : kaka6

    按目前来说，最有效的就是重启
    因为平常 left join , group by 或者 where 查询等，只要没有建索引(物理文件)，都会生成临时文件或临时空间
    而这个临时文件不会自动释放(我以前一直觉得会释放)
    运行久了，累积的临时文件就会占满空间
    所以目前觉得最有效的就是定期重启 mysql 实例
    当然代码、数据结构也得优化，该建索引建索引
    欢迎各位沟通关于 mysql 的其它运维技巧

  • 資深大佬 : opengps

    所有的表数据大小统计一下，看看实际数据占用大小
    如果数据大小占比很小，那可能真的是 mysql 日志或者索引等用途占用了，得查查索引之类的使用问题了

  • 主 資深大佬 : kaka6

    @opengps 所有表数据只占 11G, 结果因为其它空间，居然占满了 170G， 不可思义
    从昨天重启完到现在，总空间只有 20G，稳定不变了，接下来还是得好好多观察

  • 資深大佬 : han3sui

    看完感觉云数据库好方便

  • 資深大佬 : daytonight

    用 alter table t engine = innodb;重建下表试试。

  • 資深大佬 : weifan

    为什么你能发图片

  • 主 資深大佬 : kaka6

    @daytonight 全部表已经都是 innodb

  • 主 資深大佬 : kaka6

    @weifan 我也只是新用户，发不了图片，我是在外面发引用的

  • 資深大佬 : yfwl

    所以我想问除了重启还有没有不停止服务去清理的方法？

  • 資深大佬 : muskill

    @yfwl https://zhuanlan.zhihu.com/p/66336976

  • 資深大佬 : simonlu9

    千万不要在线上删大量数据，会产生很大 undo 和 redo 空间，执行超慢，还是分批删吧