A background
The host of an entrepreneurial friend's mainframe because the disk array damage machine crash, restart the MySQL service times the following error:
Copy Code code as follows:
innodb:reading tablespace information from the ... ibd files ...
innodb:restoring possible Half-written data pages from the Doublewrite
Innodb:buffer ...
Innodb:doing recovery:scanned up to log sequence number 9120034833
150125 16:12:51 innodb:starting A apply batch of log records to the database ...
The innodb:progress in Percents: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 3 7 150125 16:12:51 [ERROR] mysqld got signal 11;
This could is because you hit a bug. It is also possible the this binary
Or one of the libraries it is corrupt against, improperly built,
Or misconfigured. This error can also is caused by malfunctioning hardware.
To the This bug, Http://kb.askmonty.org/en/reporting-bugs
We'll try our best to scrape up some info that'll hopefully help
Diagnose the problem, but since we have already,
Something is definitely wrong and this may fail.
Server Version:5.5.37-mariadb-log
key_buffer_size=268435456
read_buffer_size=1048576
Max_used_connections=0
max_threads=1002
Thread_count=0
It is possible that mysqld could
Key_buffer_size + (read_buffer_size + sort_buffer_size) *max_threads = 2332093 K bytes of memory
Hope that.
Second analysis
Mainly concerned about the problem of mysqld got signal 11, from the analysis of the log content, the database in the machine crash caused the log file corruption, restart can not normal recovery, but not normal external services.
Three Solutions
Because the logs are corrupted, this is done in unconventional ways, first modifying the innodb_force_recovery parameters, allowing the mysqld to skip the recovery steps, start the mysqld, export the data, and then rebuild the database.
The innodb_force_recovery can be set to 1-6, and the large number contains the effect of all previous digits.
1. (srv_force_ignore_corrupt): Ignore the checked to corrupt page.
2. (srv_force_no_background): Prevents the main thread from running, such as the main thread needs to perform full purge operation, can cause crash.
3. (Srv_force_no_trx_undo): Do not perform transaction rollback operation.
4. (srv_force_no_ibuf_merge): Do not perform a merge operation that inserts a buffer.
5. (Srv_force_no_undo_log_scan): Do not check the value of doing a log, InnoDB storage engine will be uncommitted transactions as committed.
6. (Srv_force_no_log_redo): Do not perform roll forward operation.
Attention
A select,create,drop operation can be performed on a table after the set parameter value is greater than 0, but operations such as insert,update or delete are not allowed.
b when Innodb_purge_threads and Innodb_force_recovery are set together there is a loop phenomenon:
Copy Code code as follows:
150125 17:07:42 innodb:waiting for the background threads to start
150125 17:07:43 innodb:waiting for the background threads to start
150125 17:07:44 innodb:waiting for the background threads to start
150125 17:07:45 innodb:waiting for the background threads to start
150125 17:07:46 innodb:waiting for the background threads to start
150125 17:07:47 innodb:waiting for the background threads to start
Modify the following two parameters in My.cnf
Copy Code code as follows:
Innodb_force_recovery=6
Innodb_purge_thread=0
restart MySQL
Copy Code code as follows:
150125 17:10:47 [note] Crash recovery finished.
150125 17:10:47 [note] Server socket created on IP: ' 0.0.0.0 '.
150125 17:10:47 [note] Event scheduler:loaded 0 Events
150125 17:10:47 [note]/vdata/webserver/mysql/bin/mysqld:ready for connections.
Version: ' 5.5.37-mariadb-log ' socket: '/tmp/mysql.sock ' port:3306 Source distribution
Make a logical export of the database immediately, and then set the Innodb_force_recovery to 0, innodb_purge_thread=1, and then rebuild the database.
In addition to MySQL version 5.5 and before, when the Innodb_purge_threads =1,innodb_force_recovery >1 situation will appear the aforementioned circular report warning problem (=1 no problem),
Reason:
MySQL's source code shows the loop loop when Innodb_purge_threads and Innodb_force_recovery set up together
Copy Code code as follows:
while (srv_shutdown_state = = Srv_shutdown_none) {
   &N bsp; if (srv_thread_has_reserved_slot (srv_master) = = ulint_undefined
| | (srv_n_purge_threads = 1
&& srv_thread_has_ Reserved_slot (srv_worker)
= = ulint_undefined)) {
&nb sp; Ut_print_timestamp (stderr);
fprintf (stderr, innodb:waiting for the background Threads to start\n ");
Os_thread_sleep (1000000);
} else {
break;
}
}
So when you need to set the innodb_force_recovery>1, you need to turn off Innodb_purge_threads, set to 0 (default).
Iv. Summary
MySQL crash or MySQL database server crash can cause a variety of problems, such as the main standby error 1594 (5.6 version of the Open Crash-safe, will maximize the error 1594 to avoid the problem, will write 5.6 new features to introduce the work Can), error 1236, log damage, data file damage, and so on, this case is just one of them, carefully from the log to find related error tips, step-by-step solution can be.
