UTC - mysqld got signal 6

昨天晚上mysql又碰到一个奇怪的问题。数据库异常终止。重启成功后过就马上崩溃,不能正常运行。

查看错误警告是

InnoDB: Doing recovery: scanned up to log sequence number 1924612226346
121103 21:29:24  InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percents: 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69
70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99
InnoDB: Apply batch completed
121103 21:29:42  InnoDB: Waiting for the background threads to start
121103 21:29:43 InnoDB: 1.1.8 started; log sequence number 1924612226346
121103 21:29:43 [Note] Event Scheduler: Loaded 0 events
121103 21:29:43 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.5.21-log'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  Source distribution
121103 21:29:44  InnoDB: Assertion failure in thread 140444553848592 in file trx0purge.c line 829
InnoDB: Failing assertion: purge_sys->purge_trx_no <= purge_sys->rseg->last_trx_no
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
13:29:44 UTC - mysqld got signal 6 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
We will try our best to scrape up some info that will hopefully help
diagnose the problem, but since we have already crashed,
something is definitely wrong and this may fail.


key_buffer_size=8388608
read_buffer_size=8388608
max_used_connections=10
max_threads=100
thread_count=10
connection_count=10
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 1238130 K  bytes of memory
Hope that's ok; if not, decrease some variables in the equation.


Thread pointer: 0x0
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
stack_bottom = 0 thread_stack 0x40000
/usr/sbin/mysqld(my_print_stacktrace+0x2e)[0x76d27e]


但是内存方面配置的没有错误啊!!!

根据错误日志是没有希望了,网上查询到一片文章:http://www.2cto.com/database/201204/125762.html,跟我的情况很相似。

1、在/etc/my.cnf中写入
[mysqld] innodb_force_recovery = 4
 
但是仍然无法启动。
改为:innodb_force_recovery = 6
数据库可以读出来,在6的情况下,是无法修改数据库的,也无法插入,只能导出。

2、导出数据 mysqldump -uusername -ppassword databasename tablename > /home/db/db_TQ_1103.log.

3、备份空间文件、重做日志文件。删除数据库TQ。

4、启动mysql,导入数据正常。source /home/db/db_TQ_1103.log.

5、程序和数据库运行正常。


严重怀疑5.5.21版本有bug,我已经碰到两次了,一次wait IO高(http://blog.youkuaiyun.com/thomas0yang/article/details/8099515),这次又不能正常启动。

请问谁有类似经历,或者帮我解惑呢?

不行降低版本了。。。


http://dba.stackexchange.com/questions/14259/innodb-table-select-returns-error-2006-hy000-mysql-server-has-gone-away-after

The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains information that should help you find out what is causing the crash. 2025-03-09 13:57:47+08:00 [Note] [Entrypoint]: Entrypoint script for MySQL Server 9.2.0-1.el9 started. 2025-03-09 13:57:48+08:00 [Note] [Entrypoint]: Switching to dedicated user 'mysql' 2025-03-09 13:57:48+08:00 [Note] [Entrypoint]: Entrypoint script for MySQL Server 9.2.0-1.el9 started. '/var/lib/mysql/mysql.sock' -> '/var/run/mysqld/mysqld.sock' 2025-03-09T05:57:48.531353Z 0 [System] [MY-015015] [Server] MySQL Server - start. 2025-03-09T05:57:48.796751Z 0 [System] [MY-010116] [Server] /usr/sbin/mysqld (mysqld 9.2.0) starting as process 1 2025-03-09T05:57:48.830566Z 1 [System] [MY-013576] [InnoDB] InnoDB initialization has started. 2025-03-09T05:57:50.751653Z 1 [System] [MY-013577] [InnoDB] InnoDB initialization has ended. 2025-03-09T05:57:51.358634Z 1 [ERROR] [MY-010520] [Server] Invalid (old?) table or database name 'hm-item' 2025-03-09T05:57:51Z UTC - mysqld got signal 11 ; Signal SIGSEGV (Address not mapped to object) at address 0x0 Most likely, you have hit a bug, but this error can also be caused by malfunctioning hardware. BuildID[sha1]=6e45d3c3fff42426a19918d101b1be25b8ec7297 Thread pointer: 0x7b6d2b0 Attempting backtrace. You can use the following information to find out where mysqld died. If you see no messages after this, something went terribly wrong... stack_bottom = 7f73c1411b10 thread_stack 0x100000 #0 0xc84d30 <unknown> #1 0x7f73ce20f72f <unknown> #2 0x1950243 <unknown> #3 0x19a4793 <unknown> #4 0x16fd7bb <unknown> #5 0x153a34a <unknown> #6 0x154e9ca <unknown> #7 0xd2cc07 <unknown> #8 0x1cf6501 <unknown> #9 0x7f73ce25ad31 <unknown> #10 0x7f73ce2df0b3 <unknown> #11 0xffffffffffffffff <unknown> Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0): Connection ID (thread ID): 1 Status: NOT_KILLED The manual page at http://dev.mysql.com/doc/mysql/en/cras
03-10
### 关于 MySQL 中 Signal 11 的原因分析 Signal 11 是指 `SIGSEGV`(Segmentation Fault),通常表示程序尝试访问未分配给它的内存区域。对于 MySQL 而言,这种情况可能是由多种因素引起的。 #### 可能的原因 1. **硬件问题** 如果服务器存在硬件故障(如 RAM 或硬盘损坏),可能会导致 MySQL 进程崩溃并触发 Segmentation Fault[^3]。 2. **MySQL 配置错误** 不当的配置参数可能导致资源耗尽或不兼容的行为。例如,过高的缓冲区大小设置可能超出系统的实际能力[^4]。 3. **存储空间不足** 当磁盘空间不足时,MySQL 数据文件无法正常写入,从而引发异常终止。此情况已在提供的信息中提到:“Crash Errcode: 28 - No space left on device”[^1]。 4. **插件或第三方模块冲突** 使用某些不稳定或版本不匹配的插件也可能引起此类问题。如果启用了特定功能(如复制、审计日志等),应确认其稳定性[^5]。 5. **数据损坏** 表结构或索引受损会迫使查询操作失败,并最终造成服务中断。定期验证数据库完整性有助于预防这一风险[^6]。 6. **Bug 或软件缺陷** 特定条件下暴露出来的代码漏洞也是常见原因之一。建议查看官方发布的补丁说明以及升级指南来规避已知隐患[^7]。 #### 解决方案 针对上述每种可能性提供相应的处理措施: - **检查物理设备状态** 执行诊断工具扫描整个系统组件是否有潜在损害迹象;必要时更换有问题部件。 - **优化 my.cnf 文件设定值** 根据实际情况调整诸如 innodb_buffer_pool_size, max_connections 等关键选项至合理范围之内。 - **监控剩余容量变化趋势** 设置告警阈值以便及时发现接近临界点的情况;清理不必要的临时文件释放更多可用空间。 - **禁用可疑扩展加载项** 将怀疑对象逐一排除直至定位到真正元凶后再决定是否继续保留它们。 - **修复受损记录单元** 利用 CHECK TABLE 和 REPAIR TABLE 命令或者导出再重新导入的方式恢复受影响部分的数据一致性。 - **应用最新版修正包** 下载安装对应分支系列里的安全更新确保消除所有公开报告过的严重问题。 以下是用于检测表健康状况的一个简单脚本示例: ```sql SELECT CONCAT('CHECK TABLE ', table_schema, '.', table_name, ';') AS check_command FROM information_schema.tables WHERE table_type='BASE TABLE' AND table_schema NOT IN ('mysql', 'information_schema', 'performance_schema'); ``` 最后提醒,在做出任何更改之前务必做好完整的备份工作以防万一出现问题可以迅速回滚至上一稳定时刻。
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值