Mysql – InnoDB ibdata1 corrupted, innodb_force_recover not working

corruptioninnodbmariadbMySQLrecovery

I think I have checked every post in the internet.
Thing is my MySQL (MariaDB) won't come up and after much testing I have seen it is because of the InnoDB files.

I have tried with different innodb_force_recover and also with mysqld_safe, also with online tools and with every tut I have found.

I'm pretty desperate at this point, so any kind of help is welcome.

The log that matters is this one:

2018-11-27 15:00:16 140309240685120 [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.

2018-11-27 15:00:16 140309240685120 [Note] InnoDB: Using mutexes to ref count buffer pool pages
2018-11-27 15:00:16 140309240685120 [Note] InnoDB: The InnoDB memory heap is disabled
2018-11-27 15:00:16 140309240685120 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2018-11-27 15:00:16 140309240685120 [Note] InnoDB: GCC builtin __atomic_thread_fence() is used for memory barrier
2018-11-27 15:00:16 140309240685120 [Note] InnoDB: Compressed tables use zlib 1.2.8
2018-11-27 15:00:16 140309240685120 [Note] InnoDB: Using Linux native AIO
2018-11-27 15:00:16 140309240685120 [Note] InnoDB: Using SSE crc32 instructions
2018-11-27 15:00:16 140309240685120 [Note] InnoDB: Initializing buffer pool, size = 128.0M
2018-11-27 15:00:16 140309240685120 [Note] InnoDB: Completed initialization of buffer pool
2018-11-27 15:00:16 140309240685120 [Note] InnoDB: Highest supported file format is Barracuda.
2018-11-27 15:00:16 140309240685120 [Note] InnoDB: The log sequence number 1154517884 in ibdata file do not match the log sequence number 1345427345 in the ib_logfiles!
2018-11-27 15:00:16 140309240685120 [Note] InnoDB: Restoring possible half-written data pages from the doublewrite buffer…
InnoDB: Page directory corruption: infimum not pointed to

Best Answer

MDEV-13939 Page directory corruption: infimum not pointed appears to be a bug upstream that has some tips on recovery.