mysql datapage_mysql 异常宕机 ..InnoDB: Database page corruption on disk or a failed,,InnoDB: file read ...

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