|
Задавайте вопросы, мы ответим
Вы не зашли.
Доброго времени суток уважаемые!
Столкнулся с такой проблемой. Общий (нормальный) размер базы (на диске) 120-150Гб. В один момент, при генерации некоторой "статистики", база разрослась до ~300Гб. После удаления всех "лишних" данных, база на диске меньше не стала.
MySQL 5.6, основной движок - InnoDB.
Лучшее, решение проблемы, которое мне удалось вычитать из документации - это включить настройку innodb_file_per_table, которая позволит хранить данные каждой таблицы в отдельном файле. Соответственно, все "лишние" данные можно будет генерировать в отдельных таблицах, после чего их удалять с диска физически, тем самым освобождая место, т.к. SSD'шник - не резиновый.
Скажите пожалуйста, эта проблема относится к InnoDB и можно/нужно поискать некий альтернативный движок (например, изучить возможности XtraDB, на предмет "как там обстоят дела?"), или возможно она решена в более поздних версиях БД? Или возможно её планируется решить в новых версиях БД?
На данный момент, единственное решение известное мне - создать полный бэкап базы и восстановить её обратно. Возможно есть какие-то менее "варварские" способы, позволяющие работать без остановки работы БД?
Неактивен
На данный момент, единственное решение известное мне - создать полный бэкап базы и восстановить её обратно.
Аналогично столкнулся с проблемой свободного места. Прошерстир интернет, но похоже это единственное решение. 
Неактивен
а чем не устраивает режим innodb_file_per_table ?
в XtraDB дела обстоят также как и InnoDB.
Неактивен
vasya написал:
а чем не устраивает режим innodb_file_per_table ?
После его использования объем занимаемого места вырос почти в 2 раза. Из без танцев с бубнами его обратно не вернуть.
Неактивен
довольно странное поведение
в 5.7 добавили general tablespace, позволяет вынести в отдельное пространство лишь часть таблиц
Неактивен
Почему странное? Данные из ibdata1 перенеслись в table.idb, но размер файла ibdata1 ведь не уменьшается.
Неактивен
ага, понял, вы не пересоздаете ibdata
нужно: сделать дамп, остановить сервер, удалить все файлы (данные и журналы) innodb, запустить сервер в режиме innodb_file_per_table, восстановить данные из бекапа
тогда данные будут в idb файлах, а в общем пространстве только служебная информация
перед остановкой имеет смысл сделать drop баз данных, чтобы при запуске не было frm от несуществующих таблиц
Неактивен
Вот это и называется танцы с бубнами. Не могу понять почему разработчики не предусмотрели более простое решение по освобождению места в ibdata, например, копию этого файла, но без свободного места?
Ведь бекам и последующее восстановление это как минимум останов БД. Кроме того, есть риск что-то сделать не так (забыли включить триггеры или события в бекап) и вся работа может накрыться медным тазом. А у меня вообще сложилась патовая ситуация. Бекап сделал, но места для резервной копии данных СУБД нет, а без этого удалять базы это большой риск.
Отредактированно klow (23.04.2017 08:47:47)
Неактивен
Для того, чтобы сделать «копию файла без свободного места» можно сделать ALTER:
Неактивен
Это все понятно, что один раз, но ее нужно проделать на боевой базе с остановкой на время создания бекапа, восстановления из бекпа и проверки.
Неактивен
