Сервер MariaDB не может запуститься: "InnoDB: не найдена правильная контрольная точка".

После того, как мой сервер VM полностью потерпел крах, и я не знаю почему, MariaDB на этом Debian не может быть запущен снова. Содержание error.log с файлами журналов:

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

Я сомневаюсь ibdata1, ib_logfile0 а также ib_logfile1 повреждены, потому что я нашел другой поток, где кто-то хотел перенести свои базы данных с одного сервера на другой, и решение было правильно отключить MySQL на сервере перед передачей файлов.

Если я удаляю файлы журнала, следуя другим потокам, которые утверждают, что MySQL / InnoDB может восстановить их, сервер тоже падает, но InnoDB жалуется, что я, возможно, пропустил копирование файлов журнала. Смотрите журнал здесь (журнал размещен на GitHub, слишком долго для StackExchange)

Если я тоже уберу ibdata1сервер запускается, но я не могу получить доступ к базам данных, потому что "таблица 'xyz' не существует в движке". В этой теме упоминается, что я могу восстановить свои данные, но я не могу просто следовать решению, так как мне нужно применить его к более чем 200 таблицам.

я использую mysqld Ver 10.1.37-MariaDB-0+deb9u1 for debian-linux-gnu on x86_64 (Debian 9.6)и я использовал конфигурацию по умолчанию MariaDB для Debian, за исключением следующего:

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

Есть ли способ восстановить или восстановить данные базы данных?

PS: теперь сервер получит работу cron используя mysqldump каждый час, чтобы предотвратить проблему, что новейшей свалке больше 2 месяцев...

1 ответ

Решение

Я смог восстановить свои данные с помощью самого MySQL, трюк состоял в том, чтобы заставить InnoDB восстановить базы данных / таблицы. См. https://dev.mysql.com/doc/refman/5.7/en/forcing-innodb-recovery.html. Мне нужно было использовать innodb_force_recovery = 6 для MySQL, чтобы принять мои поврежденные файлы.

Кажется, что только одна таблица не подлежит восстановлению; похоже, эта таблица вызвала несоответствие.

Другие вопросы по тегам