MySQL社区

 找回密码
 注册

QQ登录

只需一步,快速开始

扫一扫,访问微社区

搜索
查看: 3413|回复: 3

[事务及锁] SELECT下的事务隔离级别

[复制链接]
发表于 2015-8-27 10:19:12 | 显示全部楼层 |阅读模式
诸位好,最近遇到了一个问题,不得其解,向各位请教一下:

有一套主从数据库,版本为:percona mysql 5.6.22
每隔一段时间,从库的同步就会停止,报错如下:
Last_Errno: 1205
Last_Error: Slave SQL thread retried transaction 10 time(s) in vain, giving up. Consider raising the value of the slave_transaction_retries variable.


可以通过stop slave/start slave暂时解决该问题,但是过一段时间还会发生,通过error.log和slow.log定位到,每次同步停止时,都在对某张表执行一个sql,sql执行事件达到了20分钟左右,通过日志的信息,定位到该操作是某位同事执行的从数据库中抽取数据到Hbase集群,该抽取过程执行的sql类似下面:
select count(*) from a; 首先确认表a的行数,量级在6百万行左右。
select col1,col2,col3,col4 from a limit 3000000 offset 0;
select col1,col2,col3,col4 from a limit 3000000 offset 3000000;

比较疑惑的是select怎么会造成锁表,查了一下数据库的隔离级别确实为:REPEATABLE-READ

等同事再次执行该抽取的时候,查看了一下执行sql的事务隔离级别,居然变成SERIALIZABLE
(定位的方法参考了http://www.th7.cn/db/mysql/201403/45021.shtml,该文章中遇到的问题和我一致,但没给出解决方案)

那么我的疑问就是,什么情况下select事务的隔离级别会变为SERIALIZABLE,抽取工作之后可能还会执行,又该怎么解决该问题?


目前临时的解决办法是放大了slave_transaction_retries,但是感觉治标不治本,还望各位赐教。
发表于 2015-8-27 15:19:44 | 显示全部楼层
首先,你这个sql运行了20分钟,就是一个很匪夷所思的问题,确定sql已经最优化了?
当大数据进行select 抽取数据也是要有资源的。建议到/proc/${mysqlpid}/io看一下io,也许是select获取资源太多,导致其他事物在等资源;
再次,你可以自己找一个单机去测试一下看看还会不会变
发表于 2015-8-27 15:50:49 | 显示全部楼层
我看了下你说的那个帖子,select这个事务开启的时候,并没有改变事务的隔离级别。并没有改变事务的隔离级别。并没有改变事务的隔离级别。(重要的事情要说三遍,恩~~~)
而是主从同步的running级别本来就是SERIALIZABLE,说明running的进程事务隔离级别是串行化的,导致读上锁,进而阻塞复制无法进行下去。
解决建议,还是如上我说的那些
 楼主| 发表于 2015-8-27 21:58:22 | 显示全部楼层
Julychun 发表于 2015-8-27 15:19
首先,你这个sql运行了20分钟,就是一个很匪夷所思的问题,确定sql已经最优化了?
当大数据进行select 抽 ...

SQL本身很简单,就是如我主楼里面写的那样简单的全表select,不存在什么优化的空间,我测试将表导出(这个过程很快),然后在导入虚拟机测试库,执行一模一样的sql,速度也很快,所以为啥这个sql执行20分钟,我也感觉莫名其妙。

select操作是否占用了太多资源是个思路,我明天去看看,但是我认为如果是等待资源,不应该出现锁等待的报错吧?

另外,“而是主从同步的running级别本来就是SERIALIZABLE,说明running的进程事务隔离级别是串行化的,导致读上锁,进而阻塞复制无法进行下去。”我没太理解,我理解的问题在于,从库上slave_sql_thread应用binlog之外,其他客户端连接上来执行的sql,这次是一条select语句,对应事务的隔离级别为SERIALIZABLE,导致对主从同步要执行的sql无法获得lock,导致报错,不知我理解是否有误?

您需要登录后才可以回帖 登录 | 注册

本版积分规则

QQ|申请友链|小黑屋|Archiver|手机版|MySQL社区 ( 京ICP备07012489号   
联系人:周生; 联系电话:13911732319

GMT+8, 2024-3-29 19:38 , Processed in 0.072194 second(s), 28 queries , Gzip On.

Powered by Discuz! X3.2

© 2001-2013 Comsenz Inc.

快速回复 返回顶部 返回列表