Как востановить работу innoDB после падения?

Стандартная ситуация клиент обратился с проблемой на сервере, по факту оказалось 100% диска заняты
В результате этого логи innoDB отказались работать как следствие отказ работы БД
После чистки сервера базы естественно октазались запускаться, сообщив о "111"
После mv файлов mysql так же отказался стартовать.
Сразу пришлось писать
innodb_force_recovere = 2
при этом он на нем запустился вполне себе, но дальше дело не пошло ошибка в таблицах InnoDB
Но они заблокированы для записи
ну и mysqlchck тоже не помогает.
spoiler
You may download the Percona Server operations manual by visiting
www.percona.com/software/percona-server/. You may find information
in the manual which will help you identify the cause of the crash.
2019-02-12T15:27:56.984998Z 0 [Warning] Changed limits: max_open_files: 5000 (requested 37080)
2019-02-12T15:27:56.985152Z 0 [Warning] Changed limits: table_open_cache: 2392 (requested 18432)
2019-02-12T15:27:57.126444Z 0 [Warning] 'NO_AUTO_CREATE_USER' sql mode was not set.
2019-02-12T15:27:57.126917Z 0 [Note] /usr/sbin/mysqld (mysqld 5.7.23-25) starting as process 27262 ...
2019-02-12T15:27:57.132309Z 0 [Warning] InnoDB: Using innodb_file_format is deprecated and the parameter may be removed in future releases. See dev.mysql.com/doc/refman/5.7/en/innodb-file-format.html
2019-02-12T15:27:57.132406Z 0 [Note] InnoDB: PUNCH HOLE support available
2019-02-12T15:27:57.132431Z 0 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2019-02-12T15:27:57.132448Z 0 [Note] InnoDB: Uses event mutexes
2019-02-12T15:27:57.132452Z 0 [Note] InnoDB: GCC builtin __atomic_thread_fence() is used for memory barrier
2019-02-12T15:27:57.132473Z 0 [Note] InnoDB: Compressed tables use zlib 1.2.7
2019-02-12T15:27:57.132475Z 0 [Note] InnoDB: Using Linux native AIO
2019-02-12T15:27:57.132708Z 0 [Note] InnoDB: Number of pools: 1
2019-02-12T15:27:57.132810Z 0 [Note] InnoDB: Using CPU crc32 instructions
2019-02-12T15:27:57.154244Z 0 [Note] InnoDB: Initializing buffer pool, total size = 18G, instances = 8, chunk size = 128M
2019-02-12T15:27:57.352031Z 0 [Note] InnoDB: Completed initialization of buffer pool
2019-02-12T15:27:57.382065Z 0 [Note] InnoDB: If the mysqld execution user is authorized, page cleaner thread priority can be changed. See the man page of setpriority().
2019-02-12T15:27:57.395066Z 0 [Note] InnoDB: Recovering partial pages from the parallel doublewrite buffer at /var/lib/mysql/xb_doublewrite
2019-02-12T15:27:57.405972Z 0 [Note] InnoDB: Highest supported file format is Barracuda.
2019-02-12T15:27:57.433060Z 0 [ERROR] InnoDB: Page [page id: space=0, page number=3] log sequence number 108677477433 is in the future! Current system log sequence number 21193390167.
2019-02-12T15:27:57.433095Z 0 [ERROR] InnoDB: Your database may be corrupt or you may have copied the InnoDB tablespace but not the InnoDB log files. Please refer to dev.mysql.com/doc/refman/5.7/en/forcing-innodb-rec... for information about forcing recovery.
2019-02-12T15:27:57.433267Z 0 [ERROR] InnoDB: Page [page id: space=0, page number=2] log sequence number 132140291279 is in the future! Current system log sequence number 21193390167.
2019-02-12T15:27:57.433286Z 0 [ERROR] InnoDB: Your database may be corrupt or you may have copied the InnoDB tablespace but not the InnoDB log files. Please refer to dev.mysql.com/doc/refman/5.7/en/forcing-innodb-rec... for information about forcing recovery.
2019-02-12T15:27:57.433469Z 0 [ERROR] InnoDB: Page [page id: space=0, page number=4] log sequence number 21194400206
  • Вопрос задан
  • 1356 просмотров
Решения вопроса 2
SubGANs
@SubGANs
Стопните все апачики и пхп-фпм, если они есть, чтобы с базой ничего не работало. Остановите сам мускль и заархивируйте на всякий случай /var/lib/mysql, чтобы если что-то пойдет не так можно было вернуться к исходному состоянию.
Потом запускайте бд с innodb_force_recovery от 3 до 6 и делайте дамп, начните с 3, если дамп не сделается, то повышайте.
Если совсем все плохо и дамп не делается даже на 6 уровне, то надо сливать потаблично. Если и так не сливается, часто всякие большие таблицы логов, то можно у них слить чисто схему таблицы --no-data ключ.
Потом все останавливаете, удаляйте файлы ibdata, ib_log*, и все файлы с расширением .ibd, стартуете мускль в нормальном режиме и загружаете дампы.
Ответ написан
Комментировать
@MechanID
Админ хостинг провайдера
При включенном innodb_force_recovery - неважно какой режим - база доступна только для чтения, чтобы вы смогли сдампить что доступно а потом пересоздать всю папку /var/lib/mysql и залить дамп в чистую БД
P.S. читайте документацию https://dev.mysql.com/doc/refman/5.7/en/forcing-in... там все написано.
Ответ написан
Пригласить эксперта
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы