mysql-mariadb启动报错恢复数据([ERROR] mysqld got signal 6)

本文主要是介绍mysql-mariadb启动报错恢复数据([ERROR] mysqld got signal 6),希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

一、启动mysql(mariadb)报错(注:后文中mysql==mariadb):

二、查看mysql日志:
vim /var/log/mariadb/mariadb.log
InnoDB: End of page dump
160226 11:00:21  InnoDB: Page checksum 913642282 (32bit_calc: 472052024), prior-to-4.0.14-form checksum 2048873750
InnoDB: stored checksum 913642282, prior-to-4.0.14-form stored checksum 1622372148
InnoDB: Page lsn 0 142354744, low 4 bytes of lsn at page end 142348560
InnoDB: Page number (if stored to page already) 589,
InnoDB: space id (if created with >= MySQL-4.1.1 and stored already) 0
InnoDB: Page may be an update undo log page
InnoDB: Database page corruption on disk or a failed
InnoDB: file read of page 589.
InnoDB: You may have to recover from a backup.
InnoDB: It is also possible that your operating
InnoDB: system has corrupted its own file cache
InnoDB: and rebooting your computer removes the
InnoDB: error.
InnoDB: If the corrupt page is an index page
InnoDB: you can also try to fix the corruption
InnoDB: by dumping, dropping, and reimporting
InnoDB: the corrupt table. You can use CHECK
InnoDB: TABLE to scan your table for corruption.
InnoDB: See also  http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
InnoDB: Ending processing because of a corrupt database page.
160226 11:00:21  InnoDB: Assertion failure in thread 139871429470272 in file buf0buf.c line 4032
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.
160226 11:00:21 [ERROR] 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.

To report this bug, see  http://kb.askmonty.org/en/reporting-bugs

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.

Server version: 5.5.44-MariaDB
key_buffer_size=134217728
read_buffer_size=131072
max_used_connections=0
max_threads=153
thread_count=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 466713 K  bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

Thread pointer: 0x0x0
Attempting backtrace. You can use the following information to find out
InnoDB: End of page dump
160226 11:00:30  InnoDB: Page checksum 913642282 (32bit_calc: 472052024), prior-to-4.0.14-form checksum 2048873750
InnoDB: stored checksum 913642282, prior-to-4.0.14-form stored checksum 1622372148
InnoDB: Page lsn 0 142354744, low 4 bytes of lsn at page end 142348560
InnoDB: Page number (if stored to page already) 589,
InnoDB: space id (if created with >= MySQL-4.1.1 and stored already) 0
InnoDB: Page may be an update undo log page
InnoDB: Database page corruption on disk or a failed
InnoDB: file read of page 589.
InnoDB: You may have to recover from a backup.
InnoDB: It is also possible that your operating
InnoDB: system has corrupted its own file cache
InnoDB: and rebooting your computer removes the
InnoDB: error.
InnoDB: End of page dump
160226 11:00:30  InnoDB: Page checksum 913642282 (32bit_calc: 472052024), prior-to-4.0.14-form checksum 2048873750
InnoDB: stored checksum 913642282, prior-to-4.0.14-form stored checksum 1622372148
InnoDB: Page lsn 0 142354744, low 4 bytes of lsn at page end 142348560
InnoDB: Page number (if stored to page already) 589,
InnoDB: space id (if created with >= MySQL-4.1.1 and stored already) 0
InnoDB: Page may be an update undo log page
InnoDB: Database page corruption on disk or a failed
InnoDB: file read of page 589.
InnoDB: You may have to recover from a backup.
InnoDB: It is also possible that your operating
InnoDB: system has corrupted its own file cache
InnoDB: and rebooting your computer removes the
InnoDB: error.
InnoDB: If the corrupt page is an index page
InnoDB: you can also try to fix the corruption
InnoDB: by dumping, dropping, and reimporting
InnoDB: the corrupt table. You can use CHECK
InnoDB: TABLE to scan your table for corruption.
InnoDB: See also  http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
InnoDB: Ending processing because of a corrupt database page.
160226 11:00:30  InnoDB: Assertion failure in thread 140329989404736 in file buf0buf.c line 4032
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.
160226 11:00:30 [ERROR] 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,
160226 11:00:28  InnoDB: Page dump in ascii and hex (16384 bytes):
max_threads=153
thread_count=0 
It is possible that mysqld could use up to 
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 466713 K  bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

Thread pointer: 0x0x0 
Attempting backtrace. You can use the following information to find out
160226 11:00:19  InnoDB: Page dump in ascii and hex (16384 bytes):
InnoDB: End of page dump
160226 11:00:21  InnoDB: Page checksum 913642282 (32bit_calc: 472052024), prior-to-4.0.14-form checksum 2048873750
InnoDB: stored checksum 913642282, prior-to-4.0.14-form stored checksum 1622372148
InnoDB: Page lsn 0 142354744, low 4 bytes of lsn at page end 142348560
InnoDB: Page number (if stored to page already) 589,
InnoDB: space id (if created with >= MySQL-4.1.1 and stored already) 0
InnoDB: Page may be an update undo log page
InnoDB: Database page corruption on disk or a failed
InnoDB: file read of page 589.
InnoDB: You may have to recover from a backup.
InnoDB: It is also possible that your operating
InnoDB: system has corrupted its own file cache
InnoDB: and rebooting your computer removes the
InnoDB: error.
InnoDB: If the corrupt page is an index page
InnoDB: you can also try to fix the corruption
InnoDB: by dumping, dropping, and reimporting
InnoDB: the corrupt table. You can use CHECK
InnoDB: TABLE to scan your table for corruption.
InnoDB: See also  http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
InnoDB: Ending processing because of a corrupt database page.
160226 11:00:21  InnoDB: Assertion failure in thread 139871429470272 in file buf0buf.c line 4032
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.
160226 11:00:21 [ERROR] 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.

To report this bug, see  http://kb.askmonty.org/en/reporting-bugs

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.

Server version: 5.5.44-MariaDB
key_buffer_size=134217728
read_buffer_size=131072
max_used_connections=0
max_threads=153
thread_count=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 466713 K  bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

Thread pointer: 0x0x0
Attempting backtrace. You can use the following information to find out
InnoDB: End of page dump
160226 11:00:30  InnoDB: Page checksum 913642282 (32bit_calc: 472052024), prior-to-4.0.14-form checksum 2048873750
InnoDB: stored checksum 913642282, prior-to-4.0.14-form stored checksum 1622372148
InnoDB: Page lsn 0 142354744, low 4 bytes of lsn at page end 142348560
InnoDB: Page number (if stored to page already) 589,
InnoDB: space id (if created with >= MySQL-4.1.1 and stored already) 0
InnoDB: Page may be an update undo log page
InnoDB: Database page corruption on disk or a failed
InnoDB: file read of page 589.
InnoDB: You may have to recover from a backup.
InnoDB: It is also possible that your operating
InnoDB: system has corrupted its own file cache
InnoDB: and rebooting your computer removes the
InnoDB: error.
InnoDB: If the corrupt page is an index page
InnoDB: you can also try to fix the corruption
InnoDB: by dumping, dropping, and reimporting
or misconfigured. This error can also be caused by malfunctioning hardware.

To report this bug, see  http://kb.askmonty.org/en/reporting-bugs

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.

Server version: 5.5.44-MariaDB
key_buffer_size=134217728
read_buffer_size=131072
max_used_connections=0
max_threads=153
thread_count=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 466713 K  bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

Thread pointer: 0x0x0
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 = 0x0 thread_stack 0x48000
/usr/libexec/mysqld(my_print_stacktrace+0x3d)[0x7fa11fb574ed]
/usr/libexec/mysqld(handle_fatal_signal+0x515)[0x7fa11f76d385]
/lib64/libpthread.so.0(+0xf100)[0x7fa11ee9d100]
/lib64/libc.so.6(gsignal+0x37)[0x7fa11d6515f7]
/lib64/libc.so.6(abort+0x148)[0x7fa11d652ce8]
/usr/libexec/mysqld(+0x6971a2)[0x7fa11f9651a2]
/usr/libexec/mysqld(+0x6a8b17)[0x7fa11f976b17]
/usr/libexec/mysqld(+0x6919ee)[0x7fa11f95f9ee]
/usr/libexec/mysqld(+0x66313a)[0x7fa11f93113a]
/usr/libexec/mysqld(+0x655f93)[0x7fa11f923f93]
/usr/libexec/mysqld(+0x656dfc)[0x7fa11f924dfc]
/usr/libexec/mysqld(+0x65954e)[0x7fa11f92754e]
/usr/libexec/mysqld(+0x64290e)[0x7fa11f91090e]
/usr/libexec/mysqld(+0x5fbb9c)[0x7fa11f8c9b9c]
/usr/libexec/mysqld(_Z24ha_initialize_handlertonP13st_plugin_int+0x48)[0x7fa11f76f408]
/usr/libexec/mysqld(+0x37bff5)[0x7fa11f649ff5]
/usr/libexec/mysqld(_Z11plugin_initPiPPci+0x551)[0x7fa11f64fa61]
/usr/libexec/mysqld(+0x2ee4ba)[0x7fa11f5bc4ba]
/usr/libexec/mysqld(_Z11mysqld_mainiPPc+0x546)[0x7fa11f5bf5d6]
/lib64/libc.so.6(__libc_start_main+0xf5)[0x7fa11d63db15]
/usr/libexec/mysqld(+0x2e869d)[0x7fa11f5b669d]
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.
160226 11:00:30 mysqld_safe mysqld from pid file /var/run/mariadb/mariadb.pid ended


三、接下来使用官方推荐的恢复数据方法:
1、设置恢复模式启动mysql(http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html)
vim /etc/my.cnf
添加配置项:
innodb_force_recovery = 1
其中后面的值设置为1、如果1不想再逐步增加为2/3/4等。直到能启动mysql为止!!!

2、使用恢复模式重启mysql

systemctl restart mariadb

重启成功!!!!
测试数据库连接:mysql -uroot -p123456;
正常!!!

3、备份全部数据库表:
mysqldump -uroot -p123456 --all-databases  > all_mysql_backup.sql


4、清除mysql数据(清除之前务必先stop mysql服务):
systemctl stop mariadb
cp -r  /var/lib/mysql/ /var/lib/mysql.bak
rm -rf /var/lib/mysql/*

重启mysql服务:

正常模式在启动mysql:
vim /etc/my.cnf
注释配置项:
#innodb_force_recovery = 1
再重启:
systemctl restart mariadb


5、数据库恢复为以前密码123456:
mysqladmin -u root password 123456

6、使用之间备份的sql文件恢复数据:
mysql -uroot -p123456 -e "source /root/all_mysql_backup.sql"

查看恢复好的数据:

实验完成!!!


这篇关于mysql-mariadb启动报错恢复数据([ERROR] mysqld got signal 6)的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/815132

相关文章

如何使用 Python 读取 Excel 数据

《如何使用Python读取Excel数据》:本文主要介绍使用Python读取Excel数据的详细教程,通过pandas和openpyxl,你可以轻松读取Excel文件,并进行各种数据处理操... 目录使用 python 读取 Excel 数据的详细教程1. 安装必要的依赖2. 读取 Excel 文件3. 读

SpringBoot项目中报错The field screenShot exceeds its maximum permitted size of 1048576 bytes.的问题及解决

《SpringBoot项目中报错ThefieldscreenShotexceedsitsmaximumpermittedsizeof1048576bytes.的问题及解决》这篇文章... 目录项目场景问题描述原因分析解决方案总结项目场景javascript提示:项目相关背景:项目场景:基于Spring

Windows 上如果忘记了 MySQL 密码 重置密码的两种方法

《Windows上如果忘记了MySQL密码重置密码的两种方法》:本文主要介绍Windows上如果忘记了MySQL密码重置密码的两种方法,本文通过两种方法结合实例代码给大家介绍的非常详细,感... 目录方法 1:以跳过权限验证模式启动 mysql 并重置密码方法 2:使用 my.ini 文件的临时配置在 Wi

MySQL重复数据处理的七种高效方法

《MySQL重复数据处理的七种高效方法》你是不是也曾遇到过这样的烦恼:明明系统测试时一切正常,上线后却频频出现重复数据,大批量导数据时,总有那么几条不听话的记录导致整个事务莫名回滚,今天,我就跟大家分... 目录1. 重复数据插入问题分析1.1 问题本质1.2 常见场景图2. 基础解决方案:使用异常捕获3.

Spring 请求之传递 JSON 数据的操作方法

《Spring请求之传递JSON数据的操作方法》JSON就是一种数据格式,有自己的格式和语法,使用文本表示一个对象或数组的信息,因此JSON本质是字符串,主要负责在不同的语言中数据传递和交换,这... 目录jsON 概念JSON 语法JSON 的语法JSON 的两种结构JSON 字符串和 Java 对象互转

SQL中redo log 刷⼊磁盘的常见方法

《SQL中redolog刷⼊磁盘的常见方法》本文主要介绍了SQL中redolog刷⼊磁盘的常见方法,将redolog刷入磁盘的方法确保了数据的持久性和一致性,下面就来具体介绍一下,感兴趣的可以了解... 目录Redo Log 刷入磁盘的方法Redo Log 刷入磁盘的过程代码示例(伪代码)在数据库系统中,r

mysql中的group by高级用法

《mysql中的groupby高级用法》MySQL中的GROUPBY是数据聚合分析的核心功能,主要用于将结果集按指定列分组,并结合聚合函数进行统计计算,下面给大家介绍mysql中的groupby用法... 目录一、基本语法与核心功能二、基础用法示例1. 单列分组统计2. 多列组合分组3. 与WHERE结合使

C++如何通过Qt反射机制实现数据类序列化

《C++如何通过Qt反射机制实现数据类序列化》在C++工程中经常需要使用数据类,并对数据类进行存储、打印、调试等操作,所以本文就来聊聊C++如何通过Qt反射机制实现数据类序列化吧... 目录设计预期设计思路代码实现使用方法在 C++ 工程中经常需要使用数据类,并对数据类进行存储、打印、调试等操作。由于数据类

Mysql用户授权(GRANT)语法及示例解读

《Mysql用户授权(GRANT)语法及示例解读》:本文主要介绍Mysql用户授权(GRANT)语法及示例,具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的地方,望不吝赐教... 目录mysql用户授权(GRANT)语法授予用户权限语法GRANT语句中的<权限类型>的使用WITH GRANT

Mysql如何解决死锁问题

《Mysql如何解决死锁问题》:本文主要介绍Mysql如何解决死锁问题,具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的地方,望不吝赐教... 目录【一】mysql中锁分类和加锁情况【1】按锁的粒度分类全局锁表级锁行级锁【2】按锁的模式分类【二】加锁方式的影响因素【三】Mysql的死锁情况【1