注册 登录  
 加关注
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

Oracle、MySQL资料及经验

.

 
 
 

日志

 
 

mysqldump的三种锁级别参数  

2017-05-18 16:24:46|  分类: MySQL |  标签: |举报 |字号 订阅

  下载LOFTER 我的照片书  |
 mysqldump 的三种锁级别参数:
--lock-tables, -l  默认,可读不可写 导出时,锁住的一个库的写。
--single-transaction,可读可写
--lock-all-tables, -x, 不可读不可写,全库高一致性。

如果用的是mysqldump -x,并且执行前有慢sql在执行,会一直等待慢sql执行完毕,同时阻塞新来的读写操作,也就是整个库hang住了,读操作的阻塞如下图所示:
mysqldump?的三种锁级别参数 - 熊猫兔 - Oracle、MySQL资料及经验
此时,要么等慢sql执行完毕自行恢复,如果等待自行恢复,则每次mysqldump的时间长短不一,如下图:
mysqldump?的三种锁级别参数 - 熊猫兔 - Oracle、MySQL资料及经验
要么杀掉慢sql,也能解决库hang住的问题。
查找慢sql的sql如下:
select * from information_schema.processlist where command !='SLeep' and user not in ('system user','event_scheduler') order by time desc limit 10;
找具体慢sql后,kill id;
 
杀慢sql也不是长久之计,不能因为一个备份就把业务给停了,长久之计是改mysqldump的参数:
即:备份脚本中mysqldump 的-x,改成-l或--single-transaction就行了,最好改成--single-transaction

这个事例也说明了,如果有select sql在运行,执行FLUSH TABLES;会非常危险(mysqldump -x就是执行的这个语句),有可能库会立即hang住,什么时候库自行恢复,取决于慢sql什么时候执行完毕。

  评论这张
 
阅读(44)| 评论(0)
推荐 转载

历史上的今天

在LOFTER的更多文章

评论

<#--最新日志,群博日志--> <#--推荐日志--> <#--引用记录--> <#--博主推荐--> <#--随机阅读--> <#--首页推荐--> <#--历史上的今天--> <#--被推荐日志--> <#--上一篇,下一篇--> <#-- 热度 --> <#-- 网易新闻广告 --> <#--右边模块结构--> <#--评论模块结构--> <#--引用模块结构--> <#--博主发起的投票-->
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2017