Chinaunix首页 | 论坛 | 博客
  • 博客访问: 81841
  • 博文数量: 25
  • 博客积分: 302
  • 博客等级: 二等列兵
  • 技术积分: 230
  • 用 户 组: 普通用户
  • 注册时间: 2011-12-08 00:44
文章分类

全部博文(25)

文章存档

2012年(16)

2011年(9)

我的朋友

分类:

2012-02-06 22:51:50

注意InnoDB的记录长度,控制Blob字段的数量

由于熊熊内测希望换64MySQL DB。有点担心稳定问题,研究了半天kavin当年给的innodb db bug 记录。我们用的MySQL都是5.0

090609 22:09:41InnoDB: Assertion failure in thread 696346 in file btr0cur.c line 3781

InnoDB: Failing assertion: copied_len == local_len + extern_len

InnoDB: We intentionally generate a memory trap.

后面又仔细看了robinfujackai的总结帖。 发现可能是由于InnoDB,Got error 139 from storage engine错误导致的。

 

又看了半天MySQLinnodb 的手册,发现对于Got error 139 from storage engine 错误,innodb有比较详细的解释。

http://dev.mysql.com/doc/refman/5.0/en/innodb-restrictions.html

http://dev.mysql.com/doc/refman/5.0/en/innodb-file-space.html

简单说就是一个记录()的长度不要超过的1半(默认大约8K),行的长度一般情况下就是字段数据长度综合,但数据字段中如果有BLOBTEXT)。

BLOBTEXT)的长度如果大于768字节,就会在这个页面上放一部分(768个字节)的数据,其他数据放到其他页面上,所以当BLOB字段的总数大约10

且每个字段都大于768个字节时,总长度就会大于8000(准确可能是8192),就会出现Got error 139 from storage engine 错误,(注意这个错误只是修改失败,不会Crash

但注意这个是充分条件。不是必要条件。充分必要条件就是数据记录长度大于8000,你要考虑你还有其他字段也要占用空间。

 

解决这个问题的最简单的方法就是减少blob的字段,同时老老实实的估计自己的行长度。(熊熊现在的BLOB字段5个。)

对于这个错误的最简单的规避方法还可以调整innodb_page_size(默认长度是16K)的长度。这样你可以容纳更多的BLOB字段了。但扩大可能会引发脏空间的问题。

当然你还可以不用innodb,但是innodb现在已经是用的最广泛的MYSQL引擎了,靠的是实力。

随便说一句,我看一个修改记录MYSQL3.23的某个版本就说过Innodb解决了一行8000的限制问题,怎么改着改着又改回去了。

 

但这个问题是否会引发innodb crash,我的观点和jackai类似,出现这个错误后的确出现了Crash,但是未必是这个错误导致的。从crash的断言附近的代码看,应该是出现了数据异常。我google半天发现一个比较类似的问题报告。(断言发发生的地方一样)

但是没有结论,MySQL的开发者认为可能是磁盘或者硬件异常导致的,或者说是出现故障后错误的修复导致的。由于无法了解当时场景和是否操作(有点怀疑我收到的错误信息是否正确),所以我也无从判断是否有这类可能。

另外的可能是在错误处理上没有回滚好。导致了某些数据的异常,但我无法重现。据说公司出现过多起这类事故。但MYSQL的开发者信誓旦旦No bug has ever been found in InnoDB that could explain the file corruption cases that have been reported from Linux in the past 5 years. 2006年)

看过新的版本5.0.85的版本感觉在这个代码附近也没有什么修正。

 

谢谢robinfujackai的总结。

 

BTW,看了一下最近的MySQL的发展,惊讶的发现google居然帮助了MySQL进行了很多修补。MySQL5.4版本和Innodb新的plugin都是和Google帮助有关。

Google的境界和实力不服不行。

阅读(1551) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~