Вопрос или проблема
После невнимательности руководства использование диска жесткого диска mysql сервера достигло 100%. В панике я отключил большинство служб, включая mysqld, что, как я предполагаю, и вызвало эту проблему. Затем я удалил файлы, чтобы освободить место. Имея более 1 ГБ доступного пространства, я попытался запустить mysqld, но он просто не запускался. Ошибки, указанные в журнале, были:
[ERROR] [MY-012209] [InnoDB] Найдено несколько файлов для одного и того же ID таблицы:
[ERROR] [MY-012202] [InnoDB] ID таблицы: 23 = ['archive/transaction_archive_1.ibd', 'log/transaction_15.ibd']
[ERROR] [MY-012202] [InnoDB] ID таблицы: 123 =
['archive/order_archive_1.ibd', 'log/cart_15.ibd']
[ERROR] [MY-012202] [InnoDB] ID таблицы: 406 = ['archive/pay_archive_8.ibd', 'log/cart_20.ibd']
[ERROR] [MY-012202] [InnoDB] ID таблицы: 419 = ['archive/pay_archive_9.ibd', 'log/cart_64.ibd']
[ERROR] [MY-012930] [InnoDB] Инициализация плагина прервана с ошибкой Неудалось, повторная попытка может быть успешной.
[ERROR] [MY-010334] [Server] Не удалось инициализировать DD Storage Engine
[ERROR] [MY-010020] [Server] Инициализация словаря данных не удалась.
[ERROR] [MY-010119] [Server] Прерывание
[System] [MY-010910] [Server] /usr/sbin/mysqld: Завершение работы завершено (mysqld 8.0.13) MySQL Community Server - GPL.
‘archive’ и ‘log’ это две отдельные базы данных. Установка ‘innodb_force_recovery’ с 1 до 6 не помогла. Есть ли какие-либо предложения о том, как это восстановить? Сервер работает на Linux и MySQL версии 8.0.13. Спасибо.
Наконец, мне удалось запустить mysql сервер, но я не могу быть уверенным, что это был лучший способ.
Сначала я решил, что таблицы базы данных ‘log’ важнее, чем таблицы ‘archive’. Я переместил четыре затронутых файла – archive/transaction_archive_1.ibd, archive/order_archive_1.ibd, archive/pay_archive_8.ibd, archive/pay_archive_9.ibd) в временное место. Когда я запустил mysqld, было долгое ожидание (думаю, он выполнял откаты и другие операции), и были жалобы на отсутствующие ibd файлы – что было ожидаемо. Но сервер все же запустился.
Затем я сделал резервное копирование четырех затронутых таблиц базы данных ‘log’. Затронутые ‘архивные’ таблицы были там, но я не смог запросить из них данные (‘отсутствует таблица пространства’ ошибка). Затем я отключил mysql и поменял ibd файлы – вернул ibd файлы ‘archive’ и удалил ibd файлы ‘log’. Mysqld снова запустился с жалобами на отсутствующие ibd файлы. На этот раз я зашел в консоль mysql и удалил четыре затронутые таблицы ‘log’. Затем я восстановил эти четыре таблицы из резервных копий, которые я только что сделал немного ранее.
Не могу на 100% быть уверенным, что данные не были потеряны.
Ответ или решение
Анализ проблемы с идентификаторами пространств таблиц в MySQL
Фон:
Недавняя ситуация с MySQL сервером привела к отключению служб из-за превышения предела использования дискового пространства, что в свою очередь вызвало ряд ошибок в работе системы управления базами данных. Судя по логам, MySQL не смог инициализировать хранилище данных из-за наличия нескольких файлов с одинаковыми идентификаторами пространств таблиц. Коды ошибок указывают на конфликты в идентификации файлов, принадлежащих к различным базам данных («archive» и «log»).
Проблема:
Ряд ошибок, таких как:
Multiple files found for the same tablespace ID- Ошибки инициации плагинов и словаря данных
указывает на серьезные проблемы с целостностью данных. Проблема возникла после клетки с дисковым пространством и последующего удаления файлов, что нарушило согласованность данных в InnoDB.
Решения и рекомендации:
-
Понимание идентификаторов пространств таблиц:
- Идентификаторы пространств таблиц (tablespace IDs) используются InnoDB для отслеживания файлов таблиц. Когда происходит конфликт, InnoDB не может однозначно определить, из какого файла следует загружать данные, что приводит к ошибкам.
-
Применение
innodb_force_recovery:- Хотя вы уже использовали
innodb_force_recoveryв диапазоне от 1 до 6, важно понимать, что более высокие значения (особенно 4-6) могут привести к потере данных. Используйте только низкие значения, чтобы попытаться восстановить базу данных с минимальными потерями данных.
- Хотя вы уже использовали
-
Временное перемещение файлов:
- Ваш метод временного перемещения файлов в отдельную директорию является разумным шагом, так как это позволяет MySQL запуститься без конфликтов. Однако, это должно быть осуществлено с осторожностью — убедитесь, что вы знаете, какие таблицы являются приоритетными.
-
Резервное копирование данных:
- Как вы сделали, резервное копирование всех таблиц, которые могут быть затронуты, — важный шаг в процессе восстановления. Убедитесь, что резервные копии содержат все необходимые данные для последующего восстановления таблиц.
-
Восстановление и повторное создание таблиц:
- После успешного старта MySQL с отсутствующими файлами, вы выбрали правильный подход, восстановив таблицы из резервных копий. Однако будьте осторожны с удалением таблиц. При необходимости пытаетесь восстановить данные из оставшихся файлов перед их удалением.
-
Мониторинг и профилактика:
- После успешного восстановления, настройте регулярное мониторинг использования дискового пространства и внедрите процедурные механизмы для предотвращения подобной ситуации в будущем. Рекомендуется установить алерты, которые будут уведомлять о превышении порога дискового пространства.
-
Итоговый анализ:
- Ваша проблема заключалась не только в нехватке дискового пространства, но и в механизме управления данными в MySQL. Систематическое планирование резервного копирования и контроль целостности данных помогут избежать подобных инцидентов в будущем.
Заключение:
Ситуация с конфликтом идентификаторов пространств таблиц может быть чрезвычайно сложной. Важно внимательно анализировать каждый шаг процесса восстановления, чтобы минимизировать риск потерь. Разработка строгих процедур резервного копирования и мониторинга дискового пространства также решит многие потенциальные проблемы в силовых ситуациях.