Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
10.1.10
-
None
-
Centos 6.7 x86_64
-
10.1.14
Description
I have installed mariadb 10.1.9 in virtualbox with some tables compressed using "ENGINE=Innodb,COLLATE=utf8mb4_bin,page_compressed=1;" in create statements.
After I power off the machine when mariadb is running,of course its data is corrupted.But what is important is that it reports the following assertion failure during recovery:
2015-12-07 09:33:52 7f6ecb1f1760 InnoDB: Assertion failure in thread 140113830942560 in file buf0dblwr.cc line 579
|
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.
|
151207 9:33:52 [ERROR] 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
|
Can mariadb automatically recover data in such situations?
PS:The full error log is in the attachment.
Generally yes, InnoDB can often recover data in such situations. It can do it automatically if the damage is not big, or can do it upon request, controlled by innodb_force_recovery option. See MariaDB KB for a short reference on available values, or MySQL manual for a more detailed discussion.
However, there are two things that make your case more complicated.
First, according to your full log, InnoDB considers this particular corruption really bad:
InnoDB: Also the page in the doublewrite buffer is corrupt.
InnoDB: Cannot continue operation.
InnoDB: You can try to recover the database with the my.cnf
InnoDB: option:
InnoDB: innodb_force_recovery=6
innodb_force_recovery=6 is a really desperate measure, and if InnoDB correctly detects that it's the only option (and is not just being pessimistic), chances on binary recovery are nearly non-existent, the best you can hope for to be able to dump the data and load it into a clean server.
Secondly, there is a known upstream issue with high values of innodb_force_recovery:
MDEV-8963/MDEV-9121. It is said to be fixed in InnoDB 5.6.27, but if you are using XtraDB (which is default), it is not there yet.Nevertheless, you can try different innodb_force_recovery values to see if there is any luck with any of them.