mysql 测试环境异常宕机
系统： Kylin 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