Природа внутренней ошибки движка InnoDB Errno 168

Системный код MySQL Error 1030 (SQLSTATE HY000): «Got error 168 from storage engine» представляет собой обобщенное внутреннее исключение движка InnoDB (HA_ERR_GENERIC / Unknown storage engine exception). В отличие от ошибки 28 (проблема диска), код 168 указывает на низкоуровневый сбой при обращении к страницам данных таблицы. Наиболее частые первопричины возникновения:

• Повреждение страниц данных (Page Corruption): Аппаратный сбой дискового контроллера, некорректная работа кэша RAID без батарейки (BBU) или внезапное отключение электропитания сервера во время сброса грязных страниц (Flush Dirty Pages).
• Проблемы подсистемы шифрования (InnoDB Tablespace Encryption): Утерян, поврежден или заблокирован мастер-ключ в плагине шифрования (keyring_file / keyring_vault). Таблица зашифрована, но MySQL не может прочитать ее заголовок.
• Несоответствие флагов формата страниц: Попытка открыть таблицу с форматом сжатия или параметрами ROW_FORMAT, неподдерживаемыми текущей версией ядра.

Бизнес-риски

Критическая угроза безвозвратной потери данных, циклическое падение демона MySQL при попытке доступа к поврежденной таблице (CrashLoop).

Диагностические признаки повреждения InnoDB

Регламент восстановления поврежденных таблиц при ошибке 168

Сценарий 1: Проверка журнала ошибок на факт повреждения страниц

# Анализ системного журнала MySQL на предмет повреждения страниц:
sudo grep -i -E "corrupt|checksum mismatch|page [0-9]+" /var/log/mysql/error.log

# Пример критической записи:
# [ERROR] [MY-011899] [InnoDB] [FATAL] InnoDB: Page [page id: space=45, page number=128] log sequence number 4589201 is in the future!

Сценарий 2: Аварийный запуск в режиме innodb_force_recovery

Режим форсированного восстановления позволяет запустить СУБД в режиме Read-Only для снятия дампа данных, игнорируя поврежденные сектора:

# 1. Остановите службу MySQL:
sudo systemctl stop mysql

# 2. Откройте конфигурационный файл my.cnf и установите минимальный уровень восстановления:
sudo nano /etc/mysql/mysql.conf.d/mysqld.cnf

[mysqld]
# Уровни от 1 до 6 (начинайте строго с 1!):
innodb_force_recovery = 1

# 3. Запустите службу:
sudo systemctl start mysql

# 4. Снимите дамп поврежденной таблицы:
mysqldump -u root -p my_database corrupted_table > /backup/corrupted_table_recovered.sql

# 5. Если запуск не удался -> последовательно повышайте innodb_force_recovery до 2, 3 или 4.

Сценарий 3: Пересоздание таблицы из восстановленного дампа

# 1. Подключитесь к MySQL и удалите поврежденную таблицу:
mysql -u root -p my_database
DROP TABLE `corrupted_table`;
EXIT;

# 2. Отключите innodb_force_recovery в my.cnf (закомментируйте строку!):
# innodb_force_recovery = 1

# 3. Перезапустите MySQL в штатном режиме:
sudo systemctl restart mysql

# 4. Восстановите таблицу из снятого дампа:
mysql -u root -p my_database < /backup/corrupted_table_recovered.sql

Типовые ошибки администраторов

• Попытка записи (INSERT/UPDATE) в режиме innodb_force_recovery > 0: Режим форсированного восстановления предназначен ИСКЛЮЧИТЕЛЬНО ДЛЯ ВЫГРУЗКИ ДАННЫХ (mysqldump). Попытки записи приведут к необратимому разрушению структуры данных.
• Установка innodb_force_recovery = 6 без крайней необходимости: Уровень 6 полностью отключает откат транзакций и обработку redo-логов, что может внести логическую рассинхронизацию в данные.