Движок MySQL не может запуститься.

Я пытаюсь перезапустить MySQL, однако застрял в этом цикле. Ниже прикреплен дамп из журнала ошибок MySQL.

Я попробовал установить innodb_force_recovery = 4, чтобы создать резервную копию таблиц, но даже это не сработало. Пожалуйста, подскажите, как запустить это.

2024-09-21T11:41:21.146039Z 0 [System] [MY-010116] [Server] /usr/sbin/mysqld (mysqld 8.0.39-0ubuntu0.20.04.1) начинает работу как процесс 287290
2024-09-21T11:41:21.155269Z 0 [Warning] [MY-013907] [InnoDB] Устаревшие параметры конфигурации innodb_log_file_size и/или innodb_log_files_in_group использовались для вычисления innodb_redo_log_capacity=1073741824. Пожалуйста, используйте innodb_redo_log_capacity вместо этого.
2024-09-21T11:41:21.156630Z 1 [System] [MY-013576] [InnoDB] Инициализация InnoDB началась.
2024-09-21T11:41:23.407433Z 0 [ERROR] [MY-013183] [InnoDB] Ошибка утверждения: fut0lst.ic:82:addr.page == FIL_NULL || addr.boffset >= FIL_PAGE_DATA поток 140535711876864
InnoDB: Мы намеренно создали ошибку памяти.
InnoDB: Подайте подробный отчет об ошибке на http://bugs.mysql.com.
InnoDB: Если вы получаете повторяющиеся ошибки утверждения или сбои, даже
InnoDB: немедленно после запуска mysqld, возможно, есть
InnoDB: повреждение в пространстве таблиц InnoDB. Пожалуйста, обратитесь к
InnoDB: http://dev.mysql.com/doc/refman/8.0/en/forcing-innodb-recovery.html
InnoDB: для получения информации о вынуждении восстановления.
2024-09-21T11:41:23Z UTC - mysqld получил сигнал 6;
Скорее всего, вы столкнулись с ошибкой, но эта ошибка также может быть вызвана неисправным оборудованием.
BuildID[sha1]=26eb959d4d27330a3b28319eb9ea144b2a96f707
Указатель потока: 0x0
Пытаемся создать стек вызовов. Вы можете использовать следующую информацию, чтобы выяснить,
где mysqld завершил работу. Если вы не увидите сообщений после этого, что-то пошло
удивительно не так...
stack_bottom = 0 thread_stack 0x100000
/usr/sbin/mysqld(my_print_stacktrace(unsigned char const*, unsigned long)+0x41) [0x5609f1d2c771]
/usr/sbin/mysqld(print_fatal_signal(int)+0x39b) [0x5609f0b9ed6b]
/usr/sbin/mysqld(my_server_abort()+0x76) [0x5609f0b9eeb6]
/usr/sbin/mysqld(my_abort()+0xe) [0x5609f1d2670e]
/usr/sbin/mysqld(ut_dbg_assertion_failed(char const*, char const*, unsigned long)+0x349) [0x5609f1fca2e9]
/usr/sbin/mysqld(+0x258619c) [0x5609f1fa419c]
/usr/sbin/mysqld(trx_rseg_init_thread(void*, unsigned long)+0x663) [0x5609f1fab383]
/usr/sbin/mysqld(std::thread::_State_impl<std::thread::_Invoker<std::tuple<Detached_thread, void (*)(void*, unsigned long), void*, unsigned long> > >::_M_run()+0xcc) [0x5609f1f9ff4c]
/lib/x86_64-linux-gnu/libstdc++.so.6(+0xd6df4) [0x7fd6dc93cdf4]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x8609) [0x7fd6dca58609]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x43) [0x7fd6dc629353]
Страница справки на http://dev.mysql.com/doc/mysql/en/crashing.html содержит
информацию, которая может помочь вам выяснить, что вызывает сбой.

Обновление 1: Мне удалось запустить сервер с innodb_force_recovery = 6. Размер базы данных составляет около 300 ГБ. Как лучше всего решить эту проблему? Есть ли способ понять, какая таблица является виновником, а затем исправить это?

Так как вы успешно запустили MySQL с innodb_force_recovery = 6, ваша приоритетная задача — выявить поврежденные таблицы и восстановить данные. Вот пошаговый подход:

1. Создайте резервную копию данных немедленно
   Поскольку режим восстановления 6 — это самый высокий уровень и очень рискованный (только для чтения), сразу создайте резервную копию всех ваших баз данных с помощью инструмента, такого как mysqldump:
   bash
   Код для копирования
   mysqldump –all-databases –skip-lock-tables > backup.sql
   Это гарантирует, что у вас есть резервная копия всех данных перед дальнейшей диагностикой.

2. Выявите поврежденные таблицы
   Проверьте журнал ошибок MySQL на наличие подсказок о конкретных таблицах, вызывающих проблемы.
   В качестве альтернативы выполните CHECK TABLE для каждой таблицы InnoDB, чтобы выявить повреждение:
   sql
   Код для копирования
   CHECK TABLE table_name EXTENDED;
   Сосредоточьтесь на таблицах с большими данными или которые были активно использованы перед сбоем.

3. Восстановите поврежденные таблицы
   Если вы выявили поврежденные таблицы, используйте следующие подходы:

Для не критичных таблиц вы можете удалить и заново создать таблицу.
Для важных таблиц попытайтесь экспортировать данные и затем импортировать их снова:
bash
Код для копирования
mysqldump database_name table_name > table_backup.sql
Если дамп не удался, вы можете попробовать использовать такие инструменты, как innodb-tools для более глубокого восстановления или попытаться восстановить отдельные таблицы, выполнив:
sql
Код для копирования
REPAIR TABLE table_name;
4. Уменьшите уровень восстановления и перезапустите
После того, как вы создали резервную копию данных, попробуйте постепенно уменьшить значение innodb_force_recovery (например, до 4 или 2) и перезапустить MySQL. В идеале база данных должна запуститься без необходимости включения режима восстановления.

5. Пересоздайте базу данных при необходимости
   Если повреждение сохраняется, рассмотрите возможность создания нового экземпляра базы данных, восстановления из резервной копии (backup.sql) и импорта данных в новый экземпляр.

Этот процесс должен помочь стабилизировать сервер. Дайте мне знать, если вам нужна помощь с какой-либо конкретной частью восстановления!

Поскольку вы работаете с innodb_force_recovery = 6, механизм InnoDB находится в режиме только для чтения, что предотвращает возможность непосредственного удаления поврежденной таблицы. Вот как вы можете действовать:

1. Понизьте innodb_force_recovery до 4 или 3
   Сначала попробуйте понизить режим восстановления до более низкого значения, что позволит выполнять некоторые операции, такие как удаление таблицы:

Отредактируйте конфигурацию MySQL (my.cnf или my.ini):
bash
Код для копирования
innodb_force_recovery = 4
Перезапустите MySQL, а затем попробуйте удалить таблицу:
sql
Код для копирования
DROP TABLE database_name.corrupt_table_name;
Если innodb_force_recovery = 4 не сработает, попробуйте снизить его до innodb_force_recovery = 3 или 2.

2. Удалите таблицу, используя innodb_force_recovery = 1 или без режима восстановления
   Если вам удастся запустить MySQL с innodb_force_recovery = 1, база данных позволит выполнять больше операций записи. Вы можете попытаться удалить таблицу на этом уровне, хотя некоторые таблицы могут оставаться только для чтения. Если это успешно, вы сможете удалить таблицу обычным способом.

3. Используйте ALTER TABLE, чтобы переименовать или переместить таблицу
   Если удалить таблицу невозможно, попробуйте сначала переименовать ее:

sql
Код для копирования
ALTER TABLE corrupt_table_name RENAME TO corrupt_table_backup;
Это изолирует таблицу для дальнейшего анализа или удаления.

4. Удалите таблицу вручную с диска
   В качестве последнего средства вы можете вручную удалить таблицу из файловой системы, но будьте осторожны, так как это может привести к дальнейшим проблемам:

Найдите файлы таблицы .frm, .ibd и другие файлы на диске (обычно в /var/lib/mysql/database_name/).
Удалите эти файлы, соответствующие поврежденной таблице.
Перезапустите MySQL и затем выполните DROP TABLE, чтобы удалить метаданные.
5. Восстановите поврежденную таблицу
Если вам нужно сохранить таблицу, вы можете попробовать экспортировать данные:

Используйте SELECT * INTO OUTFILE, чтобы создать дамп данных из поврежденной таблицы (если они читаемы).
Убедите, что вы удалили таблицу после снижения innodb_force_recovery, затем воссоздайте ее и импортируйте данные обратно.
Сообщите мне, если хотите получить больше деталей по любому из этих шагов!