Моя недавняя история с ошибкой MySQL таблицы () получила неожиданное продолжение. Оно меня настолько удивило, что решил написать об этом отдельно. Напомню, что там побилась одна таблица базы движка InnoDB. Я попытался её починить, но когда понял, что данные можно потерять, просто удалил и пересоздал её, так как не хотелось на работающем сервере эксперименты ставить.
Сама ситуация для меня разрешилась благополучно, но не считаю, что оптимально. В следующий раз данные могут быть нужны. Поэтому я решил её проработать и записать решение, которое не приведёт к потере данных. Для этого я пометил бэкап виртуалки за ту ночь, как неудаляемый. А через некоторое время нашёл место, где её можно спокойно развернуть и поработать с ней.
☝️ Бэкап, кстати, почти всю ночь восстанавливался. И это очень долго. Поэтому я всегда делаю отдельно бэкапы данных внутри виртуалок. Систему можно поднять быстро, залить основные данные, нужные для запуска сервиса, а остальное копировать по ходу дела. Это если архитектура сервиса и данных позволяет.
Виртуалку я восстановил, запустил, убедился, что она работает и выключил. Позже появилось время с ней поработать более внимательно. Настроил там сеть, подключился и стал смотреть. Каково же было моё удивление, когда этой ошибки я там не обнаружил. СУБД работает нормально, CHECK TABLE отрабатывает нормально, дамп делается.
Сначала подумал, что перепутал версии бэкапа. Но нет. Создание дампа логируется локально. Посмотрел лог бэкапа, там последняя операция завершилась с ошибкой именно на той таблице. В логе службы mariadb за то время тоже видны ошибки с таблицей. Смотрю прямо на сервере:
2024-11-23T20:22:17.678755+03:00 mariadbd[738]: 2024-11-23 20:22:17 7451105 [Note] InnoDB: You can use CHECK TABLE to scan your table for
corruption. Please refer to https://mariadb.com/kb/en/library/innodb-recovery-modes/ for information about forcing recovery.
2024-11-23T20:22:17.678779+03:00 mariadbd[738]: 2024-11-23 20:22:17 7451105 [ERROR] InnoDB: We detected index corruption in an InnoDB type table. You have to dump + drop + reimport the table or, in a case of widespread corruption, dump all InnoDB tables and recreate the whole tablespace. If the mariadbd server crashes after the startup or when you dump the tables. Please refer to https://mariadb.com/kb/en/library/innodb-recovery-modes/ for information about forcing recovery.
2024-11-23T20:22:17.678805+03:00 mariadbd[738]: 2024-11-23 20:22:17 7451105 [ERROR] Got error 126 when reading table ‘b_stat_session_data’
2024-11-23T20:22:17.678833+03:00 mariadbd[738]: 2024-11-23 20:22:17 7451105 [ERROR] mariadbd: Index for table ‘b_stat_session_data’ is corrupt; try to repair it
После последней ошибки сервер пару раз перезагружался и вуаля, таблица починилась сама. Хотя никаких встроенных процедур по исправлению ошибок для InnoDB в MariaDB не предусмотрено. И по логам не видно, чтобы что-то делалось.
На основном сервере саму виртуалку я не перезагружал, но службу mariadb перезапускал. Мне тогда это не помогло.
Расстроился из-за этой ситуации, так как потратил кучу времени и всё без толку. Никаких рабочих рецептов не придумал. В следующий раз придётся опять разбираться, когда с этим столкнусь.
Как сказал один читатель к заметке про проблемы с СУБД. В базе иногда происходит какая-то неведомая хрень. Сразу понятен уровень специалиста. Знает, о чём говорит. Теперь я тоже знаю.
#mysql
https://t.me/srv_admin | Авторская информация о системном администрировании
https://t.me/srv_admin/4135
