MySQL : mysqld got signal 6 ,数据库无法启动

本文涉及的产品
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
云数据库 RDS MySQL,集群系列 2核4GB
推荐场景:
搭建个人博客
云数据库 RDS MySQL,高可用系列 2核4GB
简介:

本文主要描述MySQL服务器断电,启动之后,数据库无法启动,使用innodb_force_recovery=6进行恢复的案例。


欢迎转载,请注明作者、出处。

作者:张正
blog:http://space.itpub.net/26355921 
QQ:176036317
如有疑问,欢迎联系。

MySQL服务器遇断电,重启之后,数据库无法打开。具体报错信息如下:

140918 13:56:02 mysqld_safe Number of processes running now: 0

140918 13:56:02 mysqld_safe mysqld restarted

140918 13:56:02 InnoDB: The InnoDB memory heap is disabled

140918 13:56:02 InnoDB: Mutexes and rw_locks use GCC atomic builtins

140918 13:56:02 InnoDB: Compressed tables use zlib 1.2.3

140918 13:56:02 InnoDB: Initializing buffer pool, size = 128.0M

140918 13:56:02 InnoDB: Completed initialization of buffer pool

140918 13:56:02 InnoDB: highest supported file format is Barracuda.

InnoDB: Log scan progressed past the checkpoint lsn 67376606

140918 13:56:02  InnoDB: Database was not shut down normally!

InnoDB: Starting crash recovery.

InnoDB: Reading tablespace information from the .ibd files...

InnoDB: Restoring possible half-written data pages from the doublewrite

InnoDB: buffer...

InnoDB: Doing recovery: scanned up to log sequence number 67712828

140918 13:56:02  InnoDB: Starting an apply batch of log records to the database...

InnoDB: Progress in percents: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 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

140918 13:56:03  InnoDB: Waiting for the background threads to start

140918 13:56:04 InnoDB: 1.1.8 started; log sequence number 67712828

140918 13:56:04 [Note] Recovering after a crash using /data/mysql/binlog/mysql-bin

140918 13:56:04 [Note] Starting crash recovery...

140918 13:56:04 [Note] Crash recovery finished.

140918 13:56:04  InnoDB: Assertion failure in thread 1245067584 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.

05:56:04 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=131072

max_used_connections=0

max_threads=151

thread_count=0

connection_count=0

It is possible that mysqld could use up to

key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 338489 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...

140918 13:56:04 [Note] Server hostname (bind-address): '0.0.0.0'; port: 3306

stack_bottom = 0 thread_stack 0x40000

/usr/local/mysql5.5/bin/mysqld(my_print_stacktrace+0x2e)[0x76ad1e]

140918 13:56:04 [Note]   - '0.0.0.0' resolves to '0.0.0.0';

140918 13:56:04 [Note] Server socket created on IP: '0.0.0.0'.

/usr/local/mysql5.5/bin/mysqld(handle_fatal_signal+0x386)[0x655ba6]

/lib64/libpthread.so.0[0x3519e0eb70]

/lib64/libc.so.6(gsignal+0x35)[0x3519230265]

/lib64/libc.so.6(abort+0x110)[0x3519231d10]

/usr/local/mysql5.5/bin/mysqld[0x7ab5d4]

/usr/local/mysql5.5/bin/mysqld[0x7ad219]

/usr/local/mysql5.5/bin/mysqld[0x86a3cf]

/usr/local/mysql5.5/bin/mysqld[0x8617ee]

/usr/local/mysql5.5/bin/mysqld[0x7aad55]

140918 13:56:04 [Warning] 'user' entry 'root@wordpress' ignored in --skip-name-resolve mode.

140918 13:56:04 [Warning] 'user' entry '@wordpress' ignored in --skip-name-resolve mode.

/usr/local/mysql5.5/bin/mysqld[0x79f070]

140918 13:56:04 [Warning] 'proxies_priv' entry '@ root@wordpress' ignored in --skip-name-resolve mode.

/usr/local/mysql5.5/bin/mysqld[0x7a2836]

/lib64/libpthread.so.0[0x3519e0673d]

/lib64/libc.so.6(clone+0x6d)[0x35192d44bd]

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.
看到这个报错,提示可能是由于表空间数据文件报错引起的无法进行前滚或回滚,从而数据库无法打开。
由于数据库整体文件不是太大,就几个G,因此尝试了将该数据文件拷贝到另一个地方,编辑好参数文件等一些列工作。(因为这份数据是拷贝,尝试这样做一下,做坏了耶不要紧。如果真实数据只有一份,可别上来就这么干,一定要分析清楚了问题所在,再动手。)
在参数文件中加入innodb_force_recovery=6 ,然后尝试启动mysqld,结果起来了。 这时候数据库只能进行查询,使用 mysqldump将数据导出,然后重新搭建一套新的环境。
至于断电后那部分的数据,可以尝试从binlog中解析一下,然后再对比数据库中,查看是否有丢失的数据,具体的 此处不再详述。

本文转自ITPUB博客84223932的博客,原文链接:MySQL : mysqld got signal 6 ,数据库无法启动,如需转载请自行联系原博主。

相关实践学习
如何快速连接云数据库RDS MySQL
本场景介绍如何通过阿里云数据管理服务DMS快速连接云数据库RDS MySQL,然后进行数据表的CRUD操作。
全面了解阿里云能为你做什么
阿里云在全球各地部署高效节能的绿色数据中心,利用清洁计算为万物互联的新世界提供源源不断的能源动力,目前开服的区域包括中国(华北、华东、华南、香港)、新加坡、美国(美东、美西)、欧洲、中东、澳大利亚、日本。目前阿里云的产品涵盖弹性计算、数据库、存储与CDN、分析与搜索、云通信、网络、管理与监控、应用服务、互联网中间件、移动服务、视频服务等。通过本课程,来了解阿里云能够为你的业务带来哪些帮助 &nbsp; &nbsp; 相关的阿里云产品:云服务器ECS 云服务器 ECS(Elastic Compute Service)是一种弹性可伸缩的计算服务,助您降低 IT 成本,提升运维效率,使您更专注于核心业务创新。产品详情: https://www.aliyun.com/product/ecs
目录
打赏
0
0
0
0
5351
分享
相关文章
【YashanDB知识库】原生mysql驱动配置连接崖山数据库
【YashanDB知识库】原生mysql驱动配置连接崖山数据库
【YashanDB知识库】原生mysql驱动配置连接崖山数据库
docker拉取MySQL后数据库连接失败解决方案
通过以上方法,可以解决Docker中拉取MySQL镜像后数据库连接失败的常见问题。关键步骤包括确保容器正确启动、配置正确的环境变量、合理设置网络和权限,以及检查主机防火墙设置等。通过逐步排查,可以快速定位并解决连接问题,确保MySQL服务的正常使用。
235 82
缓存与数据库的一致性方案,Redis与Mysql一致性方案,大厂P8的终极方案(图解+秒懂+史上最全)
缓存与数据库的一致性方案,Redis与Mysql一致性方案,大厂P8的终极方案(图解+秒懂+史上最全)
MySQL生产环境迁移至YashanDB数据库深度体验
这篇文章是作者将 MySQL 生产环境迁移至 YashanDB 数据库的深度体验。介绍了 YashanDB 迁移平台 YMP 的产品相关信息、安装步骤、迁移中遇到的各种兼容问题及解决方案,最后总结了迁移体验,包括工具部署和操作特点,也指出功能有优化空间及暂不支持的部分,期待其不断优化。
从 MySQL 到时序数据库 TDengine:Zendure 如何实现高效储能数据管理?
TDengine 助力广州疆海科技有限公司高效完成储能业务的数据分析任务,轻松应对海量功率、电能及输入输出数据的实时统计与分析,并以接近 1 : 20 的数据文件压缩率大幅降低存储成本。此外,taosX 强大的 transform 功能帮助用户完成原始数据的清洗和结构优化,而其零代码迁移能力更实现了历史数据从 TDengine OSS 与 MySQL 到 TDengine 企业版的平滑迁移,全面提升了企业的数据管理效率。本文将详细解读这一实践案例。
41 0
Docker Compose V2 安装常用数据库MySQL+Mongo
以上内容涵盖了使用 Docker Compose 安装和管理 MySQL 和 MongoDB 的详细步骤,希望对您有所帮助。
241 42
如何排查和解决PHP连接数据库MYSQL失败写锁的问题
通过本文的介绍,您可以系统地了解如何排查和解决PHP连接MySQL数据库失败及写锁问题。通过检查配置、确保服务启动、调整防火墙设置和用户权限,以及识别和解决长时间运行的事务和死锁问题,可以有效地保障应用的稳定运行。
174 25
云数据库:从零到一,构建高可用MySQL集群
在互联网时代,数据成为企业核心资产,传统单机数据库难以满足高并发、高可用需求。云数据库通过弹性扩展、分布式架构等优势解决了这些问题,但也面临数据安全和性能优化挑战。本文介绍了如何从零开始构建高可用MySQL集群,涵盖选择云服务提供商、创建实例、配置高可用架构、数据备份恢复及性能优化等内容,并通过电商平台案例展示了具体应用。
数据库数据恢复——MySQL简介和数据恢复案例
MySQL数据库数据恢复环境&故障: 本地服务器,安装的windows server操作系统。 操作系统上部署MySQL单实例,引擎类型为innodb,表空间类型为独立表空间。该MySQL数据库没有备份,未开启binlog。 人为误操作,在用Delete命令删除数据时未添加where子句进行筛选导致全表数据被删除,删除后未对该表进行任何操作。