利用硬链接和truncate降低drop table对线上环境的影响

作者简介

肖鹏

微博研发中心数据库技术负责人,主要负责微博数据库(MySQL/Reids/HBase/Memcached)相关的业务保障,性能优化,架构设计以及周边的自动化系统建设。10年互联网数据库架构和管理经验,专注于数据库的高性能和高可用技术保障方向。

众所周知drop table会严重的消耗服务器IO性能,如果被drop的table容量较大,甚至会影响到线上的正常。

首先,我们看一下为什么drop容量大的table会影响线上服务


直接执行drop table,mysql会将表定义和表数据全都删除,包括磁盘上的物理文件,也包括buffer pool中的内存数据。

这就分两步,第一步从buffer pool中删除,这会涉及到table_cache的lock,如果持有table_cache的lock,这将导致其他查询都无法执行。这种情况在没有innodb_per_table之前尤为严重。另外,mysql 5.5.23之后添加lazy drop table功能,这个功能用来解决mutex on the LRU list。其中心思想就是加锁,找到需要被删除的page,删除1024个page之后释放锁让其他thread工作,之后loop。

而percona的lazy drop处理起来更优雅一些,其会先加锁,然后找到需要被删除的page,标记,释放锁,后台慢慢删除。

之后就是第二步,这步在大容量表的时候更为消耗时间,那就是在os上删除物理文件。大家都知道在ext3上rm一个200G的文件会非常耗时,这是由于ext3存储数据的结构导致,如果一个很大的文件,ext3的i_block无法直接存放,需要多层嵌套才能完全存储下,在这种情况下由于映射的层次多,并且由于多层映射也不会是顺序存储的,就导致了很大的随机IO,这就导致了删除物理文件非常慢的现象。在这种情况下,建议升级到ext4,这是由于ext4比ext3使用extent分配存储空间,其最大的优势就是顺序存储。

ext3:

ext4:

知道了原因,我们来说说如何解决。具体步骤如下:


1、建立硬链接。

ln table.ibd table.idb.hdlk

2、mysql执行drop table操作。

drop table if exists tablename;

3、使用truncate删除物理文件。

truncate -s 1024*1024*4 filename

其实硬链接和drop table就不用多说了,在建立硬链接之后,mysql会认为rm了硬链接文件之后就算操作完毕,不会真正去删除物理文件从而提高了速度。但是对于服务器来说,实际的物理文件还在,如果手动rm,还是会产生很多的io影响,这时候就用到了truncate这个工具。这个工具会根据指定的size大小进行逐步删除,会将对IO造成的影响降到最低。

原文发布于微信公众号 - 数据和云(OraNews)

原文发表时间:2016-11-30

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏QQ音乐技术团队的专栏

如何设计一个可靠的消息系统

全民K歌的消息包含两种:一种是用户作品相关的消息汇聚,用户所有作品的评论、送礼等,按照时间线纵向给用户聚合起来。一种是横向用户与用户之间的交流信息,提供类似QQ...

24310
来自专栏何俊林

一种Android客户端架构设计分享

导读:今天是请aspook分享的Android客户端的架构设计,aspook的blog:http://blog.csdn.net/ahence/article...

2165
来自专栏Young Dreamer

好用的前端页面性能检测工具—sitespeed.io

引言 最近在做HTTP2技术相关调研,想确认一下HTTP2在什么情境下性能会比HTTP1.x有显著提升,当我把http2的本地环境(nginx+PHP)部署完成...

26010
来自专栏郭霖

Android冷启动白屏解析,带你一步步分析和解决问题

写在前面 记得在本月初,我发表了一篇文章叫《 Android Studio新功能解析,你真的了解Instant Run吗?》,里面详细讲解了Android St...

2055
来自专栏服务端技术杂谈

再谈微服务

传统方式 VS 微服务 ? 传统开发方式遇到的问题: 开发效率低:所有的开发在一个项目改代码,递交代码相互等待,代码冲突不断。 代码部署难:代码功能耦合在一起,...

3366
来自专栏hotqin888的专栏

MeritMS与Bentley Project Wise对比校审流程

版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/hotqin888/article/det...

1121
来自专栏ImportSource

消息队列可以有的样子

铺垫 无论是什么类型的消息队列,恐怕都离不开三个东东:读取端 、消息存储平台、写入端,无论你给这三者起了什么样子的名字。也就是写入、存储、读取。 写入端通常被叫...

3736
来自专栏性能与架构

分布式协调服务ZooKeeper工作原理

大数据处理框架Hadoop、Redis分布式服务Codis、淘宝的分布式消息中间件MetaMQ …… 他们都使用ZooKeeper做为基础部件,可以看出ZooK...

3638
来自专栏IT大咖说

MySQL高可用架构案例篇:UCloud最佳实践

1373
来自专栏CSDN技术头条

RebornDB:下一代分布式Key-Value数据库

现实世界有许多的Key-Value数据库,它们都被广泛应用于很多系统。比如,我们能够用Memcached数据库存储一个MySQL查询结果集给后续相同的查询使用,...

24410

扫码关注云+社区