утилита для дефрагментации ibdata
утилита для дефрагментации ibdata
Не встречал ли ктонибудь утилиту позволяющую уменьшить размер файла ibdata после чистки базы? (желательно без остановки сервера). dump - restore не предлагать
-
mikkey finn
- Сообщения: 1612
- Зарегистрирован: Пт ноя 10, 2006 15:23
Не оно?
There is a more robust way if you running MySQL 5
Export this query using mysql client to an SQL script like this
mysql -h<...> -u<...> -p<...> --skip-column-names -A -e"SELECT CONCAT('OPTIMIZE TABLE
',table_schema,'.',table_name,';') FROM information_schema.tables WHERE ENGINE='InnoDB'"
Then run the script using mysql client.
Please remember, OPTMIZE TABLE does absolutely nothing if all InnoDB data resides in the shared space.
Your must create all InnoDB tables as separate entities.
To do this, mysqldump all tables to a dump file.
Shutdown MySQL
add 'innodb_file_per_table' to my.cnf
Delete the ibdata files and the logs
Startup MySQL
Reload dump file.
Each InnoDB will reside in .frm and .ibd files
OPTIMIZE will defragment each tablespace (.ibd) file
There is a more robust way if you running MySQL 5
Export this query using mysql client to an SQL script like this
mysql -h<...> -u<...> -p<...> --skip-column-names -A -e"SELECT CONCAT('OPTIMIZE TABLE
',table_schema,'.',table_name,';') FROM information_schema.tables WHERE ENGINE='InnoDB'"
Then run the script using mysql client.
Please remember, OPTMIZE TABLE does absolutely nothing if all InnoDB data resides in the shared space.
Your must create all InnoDB tables as separate entities.
To do this, mysqldump all tables to a dump file.
Shutdown MySQL
add 'innodb_file_per_table' to my.cnf
Delete the ibdata files and the logs
Startup MySQL
Reload dump file.
Each InnoDB will reside in .frm and .ibd files
OPTIMIZE will defragment each tablespace (.ibd) file
-
mikkey finn
- Сообщения: 1612
- Зарегистрирован: Пт ноя 10, 2006 15:23
это да. И срабатывает только на новых таблицах поэтому перед заливкой дампа надо базу убить и заново создать.обращаю внимание на тот факт, что под каждую таблицу базы должен быть свой файл данных.
А еще есть вариант - иннодиби позволяет свои файлы прям на "сыром" разделе использовать - надо будет попробовать производительность померить.
Сделал также, как указано выше. На тестовой системе проверил - после оптимизации таблицы на самом деле дефрагментируются.
А теперь вопрос: не опасно ли для БД проведение оптимизации во время работы биллинга (то-бишь записи в таблицы)?
И если нет, то видимо лучше запускать консольную утилиту - utm5_optimizer, чем напрямую из админки?
А теперь вопрос: не опасно ли для БД проведение оптимизации во время работы биллинга (то-бишь записи в таблицы)?
И если нет, то видимо лучше запускать консольную утилиту - utm5_optimizer, чем напрямую из админки?
- А чем они собственно отличаются? Я всегда считал что utm5_optimizer - это та же функция оптимизации БД, что и в админке, просто вынесенная в отдельную утилиту.это абсолютно разные оптимизации
Вопрос в том, можно ли их запускать во время работы биллинга, т.е. когда он производит запись в таблицы?
Ранее несколько раз делал оптимизацию на тест. системе во время работы биллинга (из админки, т.к. консольной утилиты тогда еще не было) и каждый раз чего-нибудь происходило - то счета с неправильными суммами выставляет, то абонентку не снимает и т.п.
Сейчас делаю оптимизацию при отключенном биллинге, но хотелось бы избежать этого, т.к. оптимизация занимает от 4 до 6 часов. И на это время отключать биллинг проблематично.
включи лог запросов в mysql или в utm5Ata-man писал(а):- А чем они собственно отличаются? Я всегда считал что utm5_optimizer - это та же функция оптимизации БД, что и в админке, просто вынесенная в отдельную утилиту.это абсолютно разные оптимизации
Вопрос в том, можно ли их запускать во время работы биллинга, т.е. когда он производит запись в таблицы?
Ранее несколько раз делал оптимизацию на тест. системе во время работы биллинга (из админки, т.к. консольной утилиты тогда еще не было) и каждый раз чего-нибудь происходило - то счета с неправильными суммами выставляет, то абонентку не снимает и т.п.
Сейчас делаю оптимизацию при отключенном биллинге, но хотелось бы избежать этого, т.к. оптимизация занимает от 4 до 6 часов. И на это время отключать биллинг проблематично.
и посмотри что он делает.
оптимизацию можно сделать "передергиванием" таблиц из inndob в myisam и обратно
типа alter table ... engine=....;
фактически создается временная таблица в которую выгружаются все данные и потом она заменяет рабочую. исключаются "удаленные" записи.
но это тоже без остановки utm5_core лучше не делать.