微信公众号搜"智元新知"关注
微信扫一扫可直接关注哦!

mysql – ALTER TABLE … ROW_FORMAT =压缩超时

我正在尝试使用以下命令更改表:

ALTER TABLE ... ROW_FORMAT=Compressed

15分钟后失败,日志说:

InnoDB: Error: semaphore wait has lasted > 600 seconds
InnoDB: We intentionally crash the server, because it appears to be hung.

我留下了一张大临时桌子:

-rw-rw---- 1 MysqL MysqL 37G Jun  1 10:53 #sql-ib788-3264739711.ibd
-rw-rw---- 1 MysqL MysqL 15K Jun  1 10:37 #sql-13e5_95.frm

而表只有100MB.我在SLES 12上使用MariaDB 10.0.16.

我实际上备份了这个表并在运行openSUSE 13.2 / MariaDB 10.0.13的测试VM上恢复它,并且ALTER TABLE需要60秒.不幸的是,我需要在实际的服务器上执行此过程.

该表大约有100,000行.如果我将其减少到1,000行,则语句可以正常工作(确切的行数取决于我是从表的开头还是结尾删除).

日志报告InnoDB状态,我注意到了这一点:

---TRANSACTION 8665481870, not started
MysqL thread id 4, OS thread handle 0x7f8bf01b3700, query id 709 localhost user1 altering table
ALTER TABLE mdl_user ROW_FORMAT=Compressed
---TRANSACTION 8665481869, ACTIVE 253 sec
MysqL tables in use 1, locked 1
MysqL thread id 4, OS thread handle 0x7f8bf01b3700, query id 709 localhost user1 altering table
ALTER TABLE mdl_user ROW_FORMAT=Compressed
Trx read view will not see trx with id >= 8665481871, sees < 8665481870

在我看来,它试图使用两个陷入僵局的线程虽然我可能误解了这告诉我的内容.

出了什么问题?

解决方法:

请注意,我不是MysqL开发人员,我使用的是MS sql Server.但是你帖子中的行为表明如下:

它看起来不像是一个死锁,尤其是错误消息:

InnoDB: Error: semaphore wait has lasted > 600 seconds
InnoDB: We intentionally crash the server, because it appears to be hung.

死锁通常会快速确定要回滚的连接,而不是在崩溃服务器之前处理最多600秒.

可能发生的事情是,在使用该表的其他事务时,表元数据更改(ALTER TABLE)不会发生.

http://dev.mysql.com/doc/refman/5.6/en/metadata-locking.html

链接部分地说:“为确保事务可序列化,服务器不得允许一个会话在另一个会话中未完成的显式或隐式启动的事务中使用的表上执行数据定义语言(DDL)语句.”

编辑:抱歉有关死锁的误解.

根据这篇文章,https://stackoverflow.com/questions/24860111/warning-a-long-semaphore-wait

确保:Innodb_adaptive_hash_index = 0

版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 [email protected] 举报,一经查实,本站将立刻删除。

相关推荐