#Как проявляется проблема и где искать причину
После перезапуска MySQL таблица может остаться недоступной из-за повреждения таблиц/индексов, проблем с правами на файлы, отсутствующего файла tablespace либо неправильного экземпляра. Команды восстановления зависят от движка и типа повреждения.
| Возможная причина | Как узнать | Что делать |
|---|---|---|
| Не тот экземплярПодключение указывает на другой порт/каталог данных | Список таблиц отличается от ожидаемого | Сверить @@hostname, @@datadir |
| Ошибка InnoDBВ журнале повреждённая страница/словарь или tablespace | Table doesn’t exist in engine, I/O error | Сохранить копию данных и привлечь DBA |
#Пошаговая диагностика и устранение
- 1. Остановите повторные измененияЕсли таблица критична, переведите приложение в режим без записи по согласованному плану. Не удаляйте .ibd и не переносите файлы tablespace из чужого экземпляра. Зафиксируйте точную ошибку SQL и время первого отказа.
- 2. Уточните, к какому серверу подключеныВ mysql-клиенте выполните запрос и сверяйте хост, datadir и версию с ожидаемыми параметрами. Так можно обнаружить ошибку подключения после перезапуска или переключения порта.
- Чтение; значение datadir может быть скрыто настройками окруженияSQLКомандаЧтение; значение datadir может быть скрыто настройками окружения.
SELECT @@hostname, @@port, @@datadir, VERSION();
- 3. Проверьте каталог таблиц без изменения данныхПосмотрите, присутствует ли объект в INFORMATION_SCHEMA. Убедитесь, что обращаетесь к правильной базе и что видимость не ограничена правами.
- Замените appdb/orders; чтение метаданныхSQLКомандаЗамените appdb/orders; чтение метаданных.
SELECT TABLE_SCHEMA, TABLE_NAME, ENGINE FROM information_schema.tables WHERE TABLE_SCHEMA='appdb' AND TABLE_NAME='orders';
- 4. Прочитайте журналы запускаВ Linux с systemd получите последние сообщения MySQL за текущую загрузку; если служба называется mysqld/mariadb, используйте её реальное имя. Ищите InnoDB, tablespace, permission denied и ошибки диска.
- Дополнительная команда по темеLinux · Терминал (Bash)КомандаНужен sudoНужны права просмотра системного журнала; журнал может содержать конфиденциальные сведения.
sudo journalctl -u mysql -b --no-pager -n 200
- 5. Оцените файловую систему и копию данныхНа хосте проверьте наличие свободного места и состояние диска; при I/O error дальнейшая нагрузка может ухудшить ситуацию. Сохраните согласованную копию файлов/снимок по инструкции DBA. Не копируйте рабочие файлы InnoDB во время записи как единственное резервирование.
- 6. Отделите ошибку доступа от поврежденияЕсли лог указывает Permission denied, сравните владельца и режим каталога данных с официальными настройками сервиса; не выполняйте рекурсивный chmod/chown. При ошибке InnoDB организуйте проверку на восстановленной копии.
- 7. Проверяйте CHECK TABLE только на изолированной копииПосле получения полного снимка и запуска отдельной тестовой копии DBA может оценить CHECK TABLE. Для InnoDB эта команда при обнаружении некоторых повреждений может завершить сервер: на рабочей базе её не выполняют как безобидную диагностику.
- 8. Восстановите из проверенной копии при необходимостиЕсли таблица действительно повреждена, используйте штатную стратегию InnoDB, резервную копию и журнал изменений. Проверьте целостность, число строк и прикладные операции в изолированном тесте до возвращения нагрузки.
#Как проверить результат
Таблица вновь доступна в нужном экземпляре, контрольные запросы возвращают ожидаемые данные, в журнале нет новых ошибок движка.
#Если исправление не помогло
Если есть подозрение на неисправность накопителя, прекратите эксперименты на исходных данных и передайте образ диска/копию DBA для восстановления.