锁定老帖子 主题:word引起mysql数据库崩溃?
精华帖 (0) :: 良好帖 (1) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
---|---|
作者 | 正文 |
发表时间:2009-05-31
最后修改:2009-05-31
但是在运行过程中,系统莫名的崩溃了几次。 第一次: gentoo linux +mysql 5.0+innodb 引擎 ,崩溃症状:mysql的错误日志增加非常迅猛,一会把硬盘空间就沾满了(320G),同时整个mysql服务器访问很慢或拒绝访问。后来经过分析,发现是公告表出问题和笔记表出了问题,这两个表的数据库量不大,但是都一个功能特点,有一个content(text 字段)。使用的fckeditor富文本编辑框,用户经常通过拷贝word文档。后来把这连个表改为myisam引擎再也没有出现问题。 第二次: gentoo linux +mysql 5.0+innodb 引擎 ,崩溃症状和第一次一样,一查问题,是一个新功能引擎的,而这个新功能涉及的一个表字段中,也是用到的富文本编辑框。后来把这连个表改为myisam引擎再也没有出现问题。 分析问题原因: 1) 基本可以确认 是 linux + msyql5 innodb引擎 + word通过fckeditor富文本编辑框引起的 2) 以前在 window2003+mysql5.0中,从来没有出现这个问题? 3) 改成myisam就不会出现这个问题了,但是就是不能使用事务了。 4) 基本可以排除是数据量大的问题。我们有两个单表,记录都在1800万行以上,innodb引擎,占用OS空间达到5G,也从来没有崩溃过。 5) 问题本地很难重现。自己通过word粘贴拷贝,保持到数据库text字段,怎么测试都没有问题。 不值得大家出现过这个问题没有? 问题是:真的是word中的不可见字符引擎mysql崩溃的吗? 声明:ITeye文章版权属于作者,受法律保护。没有作者书面许可不得转载。
推荐链接
|
|
返回顶楼 | |
发表时间:2009-05-31
这个和innodb的表空间有关系
当表空间不足时,会增长(配置的),然后当你把记录删除以后,实际上表空间是不会减少的。。 也就是说有增无减。。。。 当表过度的修改,会导致碎片太多,不足存储新纪录,那只能申请空间了。。 |
|
返回顶楼 | |
发表时间:2009-06-01
但是按理说不应该引擎数据库崩溃吧。
现在怀疑是 双缓存问题。 服务器物理内存是8G 服务器现在top如下: Mem: 8171048k total, 7537784k used, 633264k free, 140844k buffers Swap: 4008208k total, 259612k used, 3748596k free, 1975508k cached 在下午16点服务器压力大的情况下,swap一般会用到2G左右。 |
|
返回顶楼 | |
发表时间:2009-06-01
willko 写道 这个和innodb的表空间有关系
当表空间不足时,会增长(配置的),然后当你把记录删除以后,实际上表空间是不会减少的。。 也就是说有增无减。。。。 wk。。这个也太弱了吧。。。 |
|
返回顶楼 | |
发表时间:2009-06-01
dreamlakyxy 写道 但是按理说不应该引擎数据库崩溃吧。
现在怀疑是 双缓存问题。 服务器物理内存是8G 服务器现在top如下: Mem: 8171048k total, 7537784k used, 633264k free, 140844k buffers Swap: 4008208k total, 259612k used, 3748596k free, 1975508k cached 在下午16点服务器压力大的情况下,swap一般会用到2G左右。 哦,,你是因为日志导致硬盘爆满? 那错误日志里都是些什么啊?? |
|
返回顶楼 | |
发表时间:2009-06-05
最后修改:2009-06-05
错误和 http://bugs.mysql.com/bug.php?id=38901 描述的类似。
080815 12:05:52 InnoDB: Error: trying to access tablespace 120729648 page no. 942485559, InnoDB: but the tablespace does not exist or is just being dropped. 080815 12:05:52 InnoDB: Error: trying to access tablespace 120729648 page no. 942485559, InnoDB: but the tablespace does not exist or is just being dropped. google了一下,网上也有很多人有这个错误,但是没有好的解决办法 |
|
返回顶楼 | |
发表时间:2009-06-05
最后修改:2009-06-05
昨天早上,服务器又崩溃了一次。经检查崩溃的表也是含有一个text类型的字段。但是这个字段是不允许富文本编辑框的。所以基本排除word问题。
现在怀疑问题存在的原因就是text类型字段问题,不值得是不是又有db要做大量的select,update操作,导致磁盘碎片过多,在保存text字段时,瞬间内存不足,要使用交换分区引起的错误。 因为我们的平台内存8G,交换分区每次都能用到2G,感觉交换分区用的特别多。但是磁盘的io占用并不高! |
|
返回顶楼 | |
发表时间:2009-06-05
最后修改:2009-06-05
刚才又查了一下,
“此 MySQL 服务器已经运行了 0 天 16 小时,17 分 17 秒,启动时间为 2009 年 06 月 05 日 00:44。” “查询统计:自从启动后,服务器共收到了 11,625,480 次查询。” 动态查询在16个小时之内竟然达到了1100万了......... |
|
返回顶楼 | |
发表时间:2009-06-05
r b swpd free buff cache si so bi bo in cs us sy id wa
0 0 170320 1779856 16624 797548 0 0 65 253 3 4 4 1 94 0 0 0 170320 1779972 16792 797424 0 0 148 36 3445 1279 3 1 96 0 0 0 170320 1780220 16832 797576 0 0 4 116 4125 2382 0 1 99 0 0 0 170320 1780344 16832 797600 0 0 64 0 4132 2397 5 1 93 0 0 0 170320 1780200 16848 797588 0 0 128 40 3970 2368 2 1 97 0 0 0 170320 1780936 16880 797592 0 0 64 124 4197 2134 3 1 97 0 0 0 170320 1781476 16904 797592 0 0 192 88 4766 2520 5 1 93 0 1 0 170320 1781744 16904 797612 0 0 0 0 4507 2166 4 1 96 0 0 0 170320 1781476 16928 797596 0 0 0 72 4334 1460 2 0 98 0 1 0 170320 1781704 16928 797616 0 0 0 0 3546 992 0 0 99 0 0 0 170320 1781364 16984 797572 0 0 4 24692 4395 2597 4 1 94 1 0 0 170320 1781000 16984 797620 0 0 0 0 3592 1165 0 1 100 0 |
|
返回顶楼 | |
发表时间:2009-06-05
估计是mysql的事 mysql没事 老崩~~
|
|
返回顶楼 | |