|
Задавайте вопросы, мы ответим
Вы не зашли.
Страниц: 1
Добрый день!
Случилась проблема: во время alter table над таблицой в ~10ГБ была проблема с сервером(неожиданный перебой питания) и в итоге в директории с базой, где лежит таблица подвергавшаяся alter table, образовались временные файлы типа "#sql-6f1_c#P#p2.ibd". Также тут особенность в том что таблица разбита на партишны.
В последствии все-таки выполнив нужную мне процедуру alter table, я залез в директорию базы данных и увидел эти временные файлы.
Эти временные файлы нисколько не мешали работе самого mysql(запросы выполняются, репликация идет), но меня напрягали т.к. по логике вещей они не должны оставаться, к тому же они занимали много места ~8ГБ (как раз то что успел сделать alter table пока сервер не вырубился)
Перезапускал mysql, но они не исчезли.
Я решил что mysql забыл о них при крахе системы и соответсвенно забыл их удалить.
И я удалил в ручную. При рестарте mysql "вспомнил" о них и написал в error.log сообщения о том что он не может открыть таблицу т.к. tablespace не найден и указывал путь к файлам типа "#sql-6f1_c#P#p2.ibd". Количество этих собщений об ошибке было равно количеству партиций таблицы. Несмотря на эти ошибки, сам mysql стартовал и работает в обычном режиме. Я специально прошелся по всем базам и таблицам и не заметил каких либо проблем - везде все запросы работают.
Чтобы избавится от сообщений от ошибок я создал вручную (touch) нужные ему файлы, но пустые.
При рестарте он их нашел и эти ошибки не выводит.
Но все равно остался вопрос Как корректно удалить эти временные файлы?
также читал тут http://dev.mysql.com/doc/refman/5.6/en/ … adict.html но это ничего не дало (не понятно что делать)
Отредактированно boa (29.09.2011 13:43:39)
Неактивен
Ох, вручную удалять файлы InnoDB очень плохо, понадобавили себе работы 
Самый простой способ был — создать табличку с тем же именем в другой базе
данных, скопировать файлик .frm рядом с .ibd, а потом удалить и то, и другое
командой DROP TABLE. Сейчас, если будете так делать, учтите, что спецсимволы
будут преобразованы MySQL, поэтому «с тем же именем» — это как-то так:
CREATE TABLE `#mysql50##sql-6f1_c#P#p2` ...
Сейчас, скорее всего, такой способ не пройдет (т.к. touch), и, возможно, Вам
нужно будет поиграть с ALTER TABLE ... DISCARD TABLESPACE (а потом уже с
удалением таблички).
Неактивен
спасибо за совет, все получилось!
1. от той таблицы, над которой делал альтер тейбл во время которого произошел крах, взял CREATE TABLE и создал в другой базе табличку `#mysql50##sql-6f1_c`
2. скопировал во каталог с БД файлики .frm и .par
3. сделал в нужной БД ALTER TABLE `#mysql50##sql-6f1_c` DISCARD TABLESPACE. Мускул выполнил, но проругался
4. а потом сделал drop table `#mysql50##sql-6f1_c`; Выполнилось тихо, написал предупреждение только в error.log на тему что он удаляет внутренние данные из иннодб для этой таблицы, а внешних idb файликов он не увидел.
5. проверил работу сервера - все ОК: репликация идет траблов не замечено 
После всей проделанной процедуры, появилось узнать получше как работает иннодб внутри.
Можете ли посоветовать какие нибудь русские или англоязычные материалы на эту тему?
Неактивен
Страниц: 1
