Mysql innodb exception repair process example

This article mainly introduces the experience sharing of mysql innodb exception repair. Friends who need it can refer to

A set of mysql libraries for testing. The version of mysql 5.1.71 in the centos6 default source used before . Later, I wanted to try Percona server 5.7, because there is no important data in this library. Therefore, no backup was performed before the operation. After configuring the source, the installation was carried out directly. The data files are also stored in the default location. After the installation is completed, I start mysql directly and find that the startup fails and that it cannot be started normally.

1. Roll back and reinstall mysql

In order to avoid the trouble of importing this data from other places, first make a backup of the database file of the current library (/ var/lib/mysql/location). Next, I uninstalled the Percona server 5.7 package, reinstalled the original 5.1.71 package, and started the mysql service. It prompted Unknown/unsupported table type: innodb and could not start normally.

110509 12:04:27 InnoDB: Initializing buffer pool, size = 384.0M
110509 12:04:27 InnoDB: Completed initialization of buffer pool
InnoDB: Error: log file ./ib_logfile0 is of different size 0 5242880 bytes
InnoDB: than specified in the .cnf file 0 157286400 bytes!
110509 12:04:27 [ERROR] Plugin 'InnoDB' init function returned error.
110509 12:04:27 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
110509 12:04:27 [ERROR] Unknown/unsupported table type: innodb
110509 12:04:27 [ERROR] Aborting
110509 12:04:27 [Note] /usr/sbin/mysqld: Shutdown complete

Delete the /var/lib/mysql/ directory, restart the database service, and initialize it. It is found to be normal. Show engines can find the innodb engine. Then stop the database, overwrite the contents of the previously backed up /var/lib/mysql/ directory with the contents of the current location, and restart. I also found that it could not be started, and the error content was the same as before.

The structure of the contents of the /var/lib/mysql directory is as follows:

-rw-rw---- 1 mysql mysql 10485760 2月  26 18:10 ibdata1
-rw-rw---- 1 mysql mysql 5242880 2月  26 18:10 ib_logfile0
-rw-rw---- 1 mysql mysql 5242880 2月  26 17:20 ib_logfile1
drwx------ 2 mysql mysql   4096 2月  26 17:20 mysql
drwx------ 2 mysql mysql   4096 2月 26 17:24 wiki

The wiki directory is the library for test data, the ibdata1 file is the data file, the two files starting with ib are log files, mysql The directory contains system library-related things. Use the initialized data again, and overwrite the wiki directory and ibdata1 file to the /var/lib/mysql directory. You can start normally and log in normally.

2. Reinstall the innodb module

However, when backing up through mysqldump, it prompts unknown table engine "Innodb". After logging in, check all the current engine types and find that the innodb type does not exist among them:

Use the alter command to modify the type of one of the tables to MyISAM, and find that the error is still reported.

Through find, it is found that there is a ha_innodb_plugin.so file in the /usr/lib64/mysql/plugin/ directory. I have the impression that later versions of mysql5 support online plug-in installation. Check the following to confirm that it is indeed supported:

When loading using the following command, it was found that it was unsuccessful:

install plugin innodb soname 'ha_innodb.so';

3. Backup

Add the following configuration in /etc/my.cnf:

plugin-load=innodb=ha_innodb_plugin.so
plugin_dir=/usr/lib64/mysql/plugin/
default-storage-engine=InnoDB

Found that the startup still failed. Check mysql-error.log and find the following content:

InnoDB: Database page corruption on disk or a failed
InnoDB: file read of page 7.
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.1/en/forcing-innodb-recovery.html

Open the official forcing-innodb-recovery page and find that you can force startup and recovery by specifying the innodb_force_recovery parameter. Add the following content to /etc/my.cnf:

innodb_force_recovery=6

The restart was successful. There is no problem with backing up through mysqldump. Importing the backup data to other hosts can also be found to be normal and can be tested.

Now it’s easy. Delete mysql completely and reinstall Percona server 5.7. After installation, build the database, restore the data, reconnect the program, and everything is OK.

Summary:

Due to the characteristics of mysql innodb data files, when a problem occurs and cannot be started normally, first log ./ib_logfile0 and ./ib_logfile1 Move the file first and then start it. If it still fails, you can use the innodb_force_recovery parameter to force recovery. In addition, the log is also very restartable. If you have any questions, check the log first.

The above is the detailed content of Mysql innodb exception repair process example. For more information, please follow other related articles on the PHP Chinese website!