This morning found personal site MySQL can not start, becoming unable to log, view the log found the following error:
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... 2019-11-15 08:47:24 7518 [Note] Plugin 'FEDERATED' is disabled. 2019-11-15 08:47:24 7518 [Note] InnoDB: Using atomics to ref count buffer pool pages 2019-11-15 08:47:24 7518 [Note] InnoDB: The InnoDB memory heap is disabled 2019-11-15 08:47:24 7518 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins 2019-11-15 08:47:24 7518 [Note] InnoDB: Memory barrier is not used 2019-11-15 08:47:24 7518 [Note] InnoDB: Compressed tables use zlib 1.2.11 2019-11-15 08:47:24 7518 [Note] InnoDB: Using Linux native AIO 2019-11-15 08:47:24 7518 [Note] InnoDB: Using CPU crc32 instructions 2019-11-15 08:47:24 7518 [Note] InnoDB: Initializing buffer pool, size = 256.0M 2019-11-15 08:47:24 7518 [Note] InnoDB: Completed initialization of buffer pool 2019-11-15 08:47:24 7518 [Note] InnoDB: Highest supported file format is Barracuda. 2019-11-15 08:47:24 7518 [Note] InnoDB: Log scan progressed past the checkpoint lsn 8081314994 2019-11-15 08:47:24 7518 [Note] InnoDB: Database was not shutdown normally! 2019-11-15 08:47:24 7518 [Note] InnoDB: Starting crash recovery. 2019-11-15 08:47:24 7518 [Note] InnoDB: Reading tablespace information from the .ibd files... 2019-11-15 08:47:24 7518 [Note] InnoDB: Restoring possible half-written data pages 2019-11-15 08:47:24 7518 [Note] InnoDB: from the doublewrite buffer... InnoDB: Doing recovery: scanned up to log sequence number 8081327808 2019-11-15 08:47:24 7518 [Note] InnoDB: Starting an apply batch of log records to the database... InnoDB: Progress in percent: 64 65 66 67 68 2019-11-15 08:47:24 2b3267ecb700 InnoDB: Error: page 78 log sequence number 8081835177 InnoDB: is in the future! Current system log sequence number 8081327808. InnoDB: Your database may be corrupt or you may have copied the InnoDB InnoDB: tablespace but not the InnoDB log files. See InnoDB: http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html InnoDB: for more information. 69 70 71 2019-11-15 08:47:24 2b3267cca70000:47:24 UTC - mysqld got signal 11 ; InnoDB: Error: page 3 log sequence number 8081837465 InnoDB: is in the future! Current system log sequence number 8081327808. InnoDB: Your database may be corrupt or you may have copied the InnoDB InnoDB: tablespace but not the InnoDB log files. See InnoDB: http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html InnoDB: for more information. 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=67108864 read_buffer_size=1048576 max_used_connections=0 max_threads=500 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 = 1095926 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... 72 73 stack_bottom = 0 thread_stack 0x40000 74 75 76 77 /www/server/mysql/bin/mysqld(my_print_stacktrace+0x2c)[0x903fac] 78 79 /www/server/mysql/bin/mysqld(handle_fatal_signal+0x357)[0x6747d7] /lib64/libpthread.so.0(+0xf5f0)[0x2b323e5ec5f0] 80 81 /www/server/mysql/bin/mysqld[0x98c904] 2019-11-15 08:47:24 2b3267cca700 InnoDB: Error: page 18 log sequence number 8081565946 InnoDB: is in the future! Current system log sequence number 8081327808. InnoDB: Your database may be corrupt or you may have copied the InnoDB InnoDB: tablespace but not the InnoDB log files. See InnoDB: http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html InnoDB: for more information. 82 /www/server/mysql/bin/mysqld[0x98e58c] 83 84 /www/server/mysql/bin/mysqld[0x97666c] 85 86 87 /www/server/mysql/bin/mysqld[0x978107] 88 2019-11-15 08:47:24 2b3267cca700 InnoDB: Error: page 10 log sequence number 8081837122 InnoDB: is in the future! Current system log sequence number 8081327808. InnoDB: Your database may be corrupt or you may have copied the InnoDB InnoDB: tablespace but not the InnoDB log files. See InnoDB: http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html InnoDB: for more information. /www/server/mysql/bin/mysqld[0xa4c068] 89 90 91 /www/server/mysql/bin/mysqld[0xa90a76] 92 93 /www/server/mysql/bin/mysqld[0x9eeb78] /lib64/libpthread.so.0(+0x7e65)[0x2b323e5e4e65] /lib64/libc.so.6(clone+0x6d)[0x2b323f75388d] 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.
As can be seen from the log innodb engine is out of the question. Prompted to log in to view the forced recovery method http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html.
Innodb enter recovery mode:
If the panel is pagoda in the software store -MySQL, open configuration changes, in the sixth line mysqld adding the following:
innodb_force_recovery = 6
Other self-compiled MySQL, please join in the following my.conf inside mysqld:
innodb_force_recovery = 6
If innodb_force_recovery = 6 does not take effect, you can try 2--6 few numbers.
Literacy:
innodb_force_recovery affect the recovery of the entire InnoDB storage engine. The default is 0, which means perform all recovery operations when needed recovery (ie parity data page / purge undo / insert buffer merge / rolling back & forward), when it is not effective recovery operations, mysql may not start, and error log;
innodb_force_recovery 1-6 may be provided, comprising a large number of impact in front of all numbers. When the parameter value is greater than 0, you can select, create, drop operations on the table, but the insert, update or delete such operations are not allowed.
1 (SRV_FORCE_IGNORE_CORRUPT): check to ignore the corrupt page. 2 (SRV_FORCE_NO_BACKGROUND): stop the main thread running, such as the main thread needs to perform full purge operation, will lead to crash. 3 (SRV_FORCE_NO_TRX_UNDO): transaction rollback operation is not executed. 4 (SRV_FORCE_NO_IBUF_MERGE): insert buffer merge operation is not performed. 5 (SRV_FORCE_NO_UNDO_LOG_SCAN): View not redo log, the transaction InnoDB storage engine will be deemed to have been submitted uncommitted. 6 (SRV_FORCE_NO_LOG_REDO): pre-roll operation is not performed.
Then restart the MySQL service:
systemctl restart mysqld.service
After normal startup MySQL, the database backup, you can refer to this article: Use mysqldump Linux under the database backup and recovery
After the backup, we delete the three files in the data directory:
rm -f ib_logfile0 ib_logfile1 ibdata1
Note: data path is pagoda: / www / server / data
Exit innodb recovery mode:
When you delete a file, we return to the first step.
If the panel is pagoda in the software store -MySQL, open configuration changes, comment the following line:
innodb_force_recovery = 6
Or change it to:
innodb_force_recovery = 0
Other versions of the same operating MySQL, annotate to modify my.conf.
After the operation is complete, we import the database, you can refer to this article: Use mysqldump database backup and recovery for Linux
The import process will encounter the following error:
Tablespace for table `tablexx` exists. Please DISCARD the tablespace before IMPORT.
This is because our previous database exists in the file, making it impossible to import.
Solution:
1. Before you delete the database, and then add. 2. Prior to empty the database directory, and then import
Note: pagoda panel database directory: / www / server / data to the database files in its directory folder can be emptied.
So far, the database is restored.
postscript:
Search found that users experiencing this problem, and many, but most explanations for MySQL version BUG, through an upgraded version to fix, but because MySQL development environment is part of the production version 5.x, can not be upgraded, only repair, hope this problem does not occur again, tears ran ~
>> reprint please indicate the source: Assassin's blog
>> VPS Recommended: Hostdare pay $ 16 in Los Angeles GIA Crea room
>> If the article fails or installation fails, please leave a message for feedback