Сервер 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, чтобы принять мои поврежденные файлы.
Кажется, что только одна таблица не подлежит восстановлению; похоже, эта таблица вызвала несоответствие.