mysql 测试环境异常宕机

系统:\nKylin 3.3

mysql版本:5.6.15--yum安装,麒麟提供的yum源数据库版本

error日志

181218 09:38:52 mysqld_safe Starting mysqld daemon with databases from /home/data/mysqldata/3306/data
2018-12-18 09:42:56 12390 [Note] Plugin 'FEDERATED' is disabled.
2018-12-18 09:42:56 12390 [Note] InnoDB: The InnoDB memory heap is disabled
2018-12-18 09:42:56 12390 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2018-12-18 09:42:56 12390 [Note] InnoDB: Compressed tables use zlib 1.2.3
2018-12-18 09:42:56 12390 [Note] InnoDB: Using CPU crc32 instructions
2018-12-18 09:42:56 12390 [Note] InnoDB: Initializing buffer pool, size = 6.0G
2018-12-18 09:42:57 12390 [Note] InnoDB: Completed initialization of buffer pool
2018-12-18 09:42:57 12390 [Note] InnoDB: Highest supported file format is Barracuda.
2018-12-18 09:42:57 12390 [Note] InnoDB: Log scan progressed past the checkpoint lsn 9090973899
2018-12-18 09:42:57 12390 [Note] InnoDB: Database was not shutdown normally!
2018-12-18 09:42:57 12390 [Note] InnoDB: Starting crash recovery.
2018-12-18 09:42:57 12390 [Note] InnoDB: Reading tablespace information from the .ibd files...
2018-12-18 09:42:59 12390 [Note] InnoDB: Restoring possible half-written data pages
2018-12-18 09:42:59 12390 [Note] InnoDB: from the doublewrite buffer...
InnoDB: Doing recovery: scanned up to log sequence number 9096216576
InnoDB: Doing recovery: scanned up to log sequence number 9101459456
InnoDB: Doing recovery: scanned up to log sequence number 9106702336
InnoDB: Doing recovery: scanned up to log sequence number 9111945216
InnoDB: Doing recovery: scanned up to log sequence number 9112050393
2018-12-18 09:43:17 12390 [Note] InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percent: 0 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
InnoDB: Last MySQL binlog file position 0 466214313, file name mysql-bin.000012
InnoDB: Database page corruption on disk or a failed
InnoDB: file read of page 8.
InnoDB: You may have to recover from a backup.
2018-12-18 09:43:19 7fa75b768740 InnoDB: Page dump in ascii and hex (16384 bytes):
len 16384; hex 000000000000000000000000000000000

。。。。。一堆

InnoDB: End of page dump
2018-12-18 09:43:20 7fa75b768740 InnoDB: uncompressed page, stored checksum in field1 0, calculated checksums for field1: crc32 3919750611, innodb 563001162, none 3735928559, stored checksum in field2 3449489408, calculated checksums for field2: crc32 3919750611, innodb 1371122432, none 3735928559, page LSN 0 0, low 4 bytes of LSN at page end 0, page number (if stored to page already) 0, space id (if created with >= MySQL-4.1.1 and stored already) 0
InnoDB: Page may be a freshly allocated page
InnoDB: Database page corruption on disk or a failed
InnoDB: file read of page 8.
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.6/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
InnoDB: Ending processing because of a corrupt database page.
2018-12-18 09:43:20 7fa75b768740 InnoDB: Assertion failure in thread 140356770760512 in file buf0buf.cc line 4054
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.6/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
01:43:20 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=33554432
read_buffer_size=33554432
max_used_connections=0
max_threads=3000
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 = 294985830 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+0x3b)[0x8d6d1b]
/usr/sbin/mysqld(handle_fatal_signal+0x4a1)[0x66e031]
/lib64/libpthread.so.0(+0xf370)[0x7fa75b357370]
/lib64/libc.so.6(gsignal+0x37)[0x7fa75a15e1d7]
/lib64/libc.so.6(abort+0x148)[0x7fa75a15f8c8]
/usr/sbin/mysqld[0xa52c98]
/usr/sbin/mysqld[0xa665b8]
/usr/sbin/mysqld[0xa4d7c2]
/usr/sbin/mysqld[0xa34044]
/usr/sbin/mysqld[0xa85a58]
/usr/sbin/mysqld[0x9f323d]
/usr/sbin/mysqld[0x934218]
/usr/sbin/mysqld(_Z24ha_initialize_handlertonP13st_plugin_int+0x48)[0x5b1b88]
/usr/sbin/mysqld[0x6f37e0]
/usr/sbin/mysqld(_Z11plugin_initPiPPci+0x910)[0x6f9be0]
/usr/sbin/mysqld(_Z11mysqld_mainiPPc+0x8cd)[0x5ab7ad]
/lib64/libc.so.6(__libc_start_main+0xf5)[0x7fa75a14ab35]
/usr/sbin/mysqld[0x59f21d]
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.
181218 09:43:20 mysqld_safe mysqld from pid file /home/data/mysqldata/3306/data/mysqlhq.pid ended

办法:

尝试修改参数innodb_force_recovery=1 ,仍然不能启动,数据库,报一样的错误

尝试修改为2~6,仍然不能启动数据

测试环境没有备份, 只能从binlog中恢复

mysqlbinlog -vv mysql-bin.000001 >/tmp/01binlog.sql

mv /home/data/mysqldata/3306/data /home/data/mysqldata/3306/data1

rm -rf /home/data/mysqldata/3306/data

/usr/bin/mysql_install_db --defaults-file=/home/data/mysqldata/3306/my.cnf --datadir=/home/data/mysqldata/3306/data --user=mysql
/usr/bin/mysqld_safe --defaults-file=/home/data/mysqldata/3306/my.cnf &
/usr/bin/mysql -S /data/mysqldata/3306/mysql.sock
(root@localhost:mysql.sock) [(none)]> source /tmp/1blog.txt

(root@not_connected:not_connected) [tmp]> source /tmp/1blog.txt
[mysql@mysqlhq 3306]$ /usr/bin/mysql -uroot -p -S /home/data/mysqldata/3306/mysql.sock
Enter password:
(root@localhost:mysql.sock) [(none)]> source /tmp/4blog.txt

参考其他的方法,修改参数innodb_force_recovery,别人的情况适用,但在这里不适用,也有说是5.6的bug,但是提供的bug号,没有找到

参考

http://blog.itpub.net/133735/viewspace-755805/

https://blog.csdn.net/u010719917/article/details/78271034

mysql 异常宕机 ..InnoDB: Database page corruption on disk or a failed,,InnoDB: file read of page 8.的更多相关文章

  1. mysql数据库崩溃:InnoDB: Database page corruption on disk or a failed

    修改mysql配置文件my.cnf,添加 innodb_force_recovery = 6 innodb_purge_thread = 0 重启mysql 这时只可以执行select,create, ...

  2. MySQL主从宕机的解决方法

    测试系统:centos6.5系统 测试环境IP地址划分: master: 192.168.80.130 slave:192.168.80.143 slave:192.168.80.146 首先模拟(M ...

  3. MySQL Bug导致异常宕机的分析流程

    原文链接:http://click.aliyun.com/m/42521/ 摘要: 本文主要通过一个bug来记录一下如何分析一个MySQL bug的崩溃信息. 版本:Percona 5.7.17-11 ...

  4. 记一次线上Mysql数据库 宕机

    从发现问题,到最后解决一共消耗两个半小时(7:30~10:00),报警电话16通,警察坐镇,未完待续 ......

  5. MySQL定时检查是否宕机并邮件通知

    我们有时候需要一些检查MySQL是否宕机,如果宕机了应自动重新启动应用并通知运维人员!此脚本用来简单的实现MySQL宕机后自动重启并邮件通知运维,此为SHELL脚本,当然也有一些朋友喜欢用Python ...

  6. (转)从史上八大MySQL宕机事故中学到的经验

    一.Percona网站宕机事件 震级:3 发生时长:2011年7月11日 持续时长:数日 地点:加州Pleasanton(幸福屯) 宕机原因:Percona网站主服务器上的3块硬盘损坏,同时因为人员变 ...

  7. Centos7.5调试/etc/sysctl.conf文件导致宕机

    今天安装greenplus数据库,需要调试一个核心文件/etc/sysctl.conf文件,结果导致系统异常宕机,出现的问题就是使用任何命令都不能输出正确的结果,只有这个显示: 不知道是什么原因,ls ...

  8. 服务应用突然宕机了?别怕,Dubbo 帮你自动搞定服务隔离!

    某日中午,午睡正香的时候,接到系统的报警电话,提示生产某物理机异常宕机了,目前该物理机已恢复,需要重启上面部署的应用. 这时瞬间没有了睡意,登上堡垒机,快速重启了应用,系统恢复正常.本想着继续午睡,但 ...

  9. 服务器宕机,mysql无法启动,job for mysql.service failed because the process exited with error code,数据库备份与恢复

    [问题现象] 服务器在运行过程中,因人为意外导致电源被拔,服务器宕机,mysql重启不成功,报错如下 根据提示,输入systemctl status mysql.service和journalctl ...

随机推荐

  1. python基础语法学习常见小问题

    说明:我是最近觉得python在完成很多工作中方便使用而且功能强大,想突击学习一下.用的是廖雪峰老师的教程,学习python3.X.这里是廖雪峰老师的网站链接: http://www.liaoxuef ...

  2. Linux查看文件编码格式及文件编码转换<转>

    如果你需要在Linux 中操作windows下的文件 ,那么你可能会经常遇到文件 编码 转换的问题.Windows中默认的文件 格式是GBK(gb2312),而Linux 一般都是UTF-8.下面介绍 ...

  3. oracle 启动数据库与监听器

    1.oracle 启动数据库与监听器 1)启动数据库 oracle用户进去 oracle/oracle sqlplus / as sysdba 然后startup 退出,然后启动监听进程 2)启动监听 ...

  4. mybatis 一对多和多对一

      在学习MyBatis3的过程中,文档上面一直在强调一个id的东西!在做这个实验的时候,也因为没有理解清楚id含义而导致一对多的“多”中也只有一条数据.id和result的唯一不同是id表示的结果将 ...

  5. 将本地jar包制作成maven依赖

    首先,需要配置maven环境,如果没配置,传送门:http://www.cnblogs.com/hyyq/p/6557683.html 然后,需要一个ben地的jar包,这里以阿里云支付宝sdk为例, ...

  6. static 关键字详解 static方法调用非static属性和方法

    静态的属性和方法在内存中的存放地址与非静态的是不同的,静态的是存放在static区,它意味着静态方法是没有this的,所以我们不可以从一个static方法内部发出对非static方法的调用.但是反之是 ...

  7. Codeforces Round #367 (Div. 2) D. Vasiliy's Multiset trie树

    D. Vasiliy's Multiset time limit per test 4 seconds memory limit per test 256 megabytes input standa ...

  8. Use default arguments instead of short circuiting or conditionals使用默认实参代替短路和条件

  9. 机器学习之K-近邻(KNN)算法

    一 . K-近邻算法(KNN)概述  最简单最初级的分类器是将全部的训练数据所对应的类别都记录下来,当测试对象的属性和某个训练对象的属性完全匹配时,便可以对其进行分类.但是怎么可能所有测试对象都会找到 ...

  10. Spring Cloud Ribbon实现客户端负载均衡

    1.构建microservice-consumer-movie-ribbon项目,在pom.xml中引入ribbon依赖 在引入Eureka依赖的时候,默认里面含有ribbon依赖 2.添加@Load ...