0

After my VM server has fully crashed, and I do not know why, MariaDB on this Debian cannot be launched again. Content of error.log with log files:

2019-04-15  0:40:43 139787712552320 [Note] InnoDB: innodb_empty_free_list_algorithm has been changed to legacy because of small buffer pool size. In order to use backoff, increase buffer pool at least up to 20MB.

2019-04-15  0:40:43 139787712552320 [Note] InnoDB: Using mutexes to ref count buffer pool pages
2019-04-15  0:40:43 139787712552320 [Note] InnoDB: The InnoDB memory heap is disabled
2019-04-15  0:40:43 139787712552320 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2019-04-15  0:40:43 139787712552320 [Note] InnoDB: GCC builtin __atomic_thread_fence() is used for memory barrier
2019-04-15  0:40:43 139787712552320 [Note] InnoDB: Compressed tables use zlib 1.2.8
2019-04-15  0:40:43 139787712552320 [Note] InnoDB: Using Linux native AIO
2019-04-15  0:40:43 139787712552320 [Note] InnoDB: Using SSE crc32 instructions
2019-04-15  0:40:43 139787712552320 [Note] InnoDB: Initializing buffer pool, size = 128.0M
2019-04-15  0:40:43 139787712552320 [Note] InnoDB: Completed initialization of buffer pool
2019-04-15  0:40:43 139787712552320 [Note] InnoDB: Highest supported file format is Barracuda.
InnoDB: No valid checkpoint found.
InnoDB: A downgrade from MariaDB 10.2.2 or later is not supported.
InnoDB: If this error appears when you are creating an InnoDB database,
InnoDB: the problem may be that during an earlier attempt you managed
InnoDB: to create the InnoDB data files, but log file creation failed.
InnoDB: If that is the case, please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.6/en/error-creating-innodb.html
2019-04-15  0:40:43 139787712552320 [ERROR] Plugin 'InnoDB' init function returned error.
2019-04-15  0:40:43 139787712552320 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
2019-04-15  0:40:43 139787712552320 [Note] Plugin 'FEEDBACK' is disabled.
2019-04-15  0:40:43 139787712552320 [ERROR] Unknown/unsupported storage engine: InnoDB
2019-04-15  0:40:43 139787712552320 [ERROR] Aborting

I doubt the ibdata1, ib_logfile0 and ib_logfile1 are corrupted because I found another thread where someone wanted to transfer their databases from one server to another and the solution was properly shutdown MySQL on the server before transfering the files.

If I remove the log files following other threads which claim that MySQL / InnoDB can restore them, the server crashes too but InnoDB complains that I may have missed to copy the log files. See log here (log posted on GitHub, too long for StackExchange)

If I also remove ibdata1, the server starts but I cannot access the databases because "The table 'xyz' doesn't exist in engine". This thread mentions that I may can restore my data but I cannot simply follow the solution as I have to apply it to over 200 tables.

I am using mysqld Ver 10.1.37-MariaDB-0+deb9u1 for debian-linux-gnu on x86_64 (Debian 9.6) and I have used the default configuration of MariaDB for Debian except following:

[mysqld]
innodb_large_prefix=ON
innodb_file_format=barracuda
innodb_file_per_table=ON

Is there a way to restore or repair the database data?

PS: Now the server will get a cron job using mysqldump every hour to prevent the issue that the newest dump is over 2 months old ...

1 Answer 1

0

I was able to restore my data with MySQL itself, the trick was to force InnoDB to recover the databases / tables. See https://dev.mysql.com/doc/refman/5.7/en/forcing-innodb-recovery.html. I needed to use innodb_force_recovery = 6 for MySQL to accept my corrupted files.

Only one table seems to be non-restorable, seems that this table caused the inconsistency.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .