[ТЕМА ЗАКРЫТА]
Опции темы
09.03.2014 13:15  
Tiger
На УКМ сервер магазина база mysql распухла до 80 Гб, так что осталось места около 2Гб от жесткого! Снял дамп базы, подкинул чистую базу поставил заливаться! Все шло нормально, но на каком-то этапе все зависло, где посмотреть в логах, вливается ли дамп? Заметил вот еще, что размер папки ukmserver стал больше, чем у старой data (300 Мб старая, а сейчас во время восстановления уже 10Гб), а сам файл ibdata1 размером 300Мб, и не изменяется! Что не так пошло?
 
09.03.2014 14:08  
whitewizard
Покажи скрипты экчпорта и импорта
 
09.03.2014 23:00  
Onesoft
Цитата:
Сообщение от Tiger
Заметил вот еще, что размер папки ukmserver стал больше, чем у старой data (300 Мб старая, а сейчас во время восстановления уже 10Гб), а сам файл ibdata1 размером 300Мб, и не изменяется! Что не так пошло?
Сервер на винде? Убирай из my.ini настройку innodb_file_per_table и перезаливай базу заново с нуля. Винде не хватает ресурсов для работы с многочисленными открытиями многочисленных файлов (причина твоего зависания), единый файл ibdata1 - самое оптимальное решение доя виндовой mysql в ukmserver, не смотря на то, что файл этот несжимаем.

Когда БД хранит таблицы в отдельных файлах, то после модификации/удаления данных размер этих файлов можно легко уменьшить (т.е. "сжать" файлы БД) командой optimize table. В случае, если все InnoDB таблицы хранятся в едином файле ibdata1, то такое сжатие БД невозможно. То есть перспектива сжатия БД ukmserver после удаления чеков возможна только при innodb_file_per_table=1. Но УКМ сервер весьма интенсивно работает с БД ukmserver и ресурсы винды быстро иссякают на операциях открытия файлов БД. В октябре позапрошлого года я потратил ночь с пятницы на субботу на перевод БД СГО на режим работы в таком режиме. Затем всю субботу я пытался понять, почему так катастрофически упала производительность сервера, перезагрузив сервер раз пять, затем в ночь с субботы на воскресенье перевёл БД обратно на innodb_file_per_table=0, но БД при этом не стал перезаливать, поскольку старые продажи ещё не восстановил, поэтому для каждой innodb таблицы сделал просто alter table ... engine=innodb. И в воскресенье всё заработало как раньше. Размер БД тогда достиг примерно 1 ТБ и для сокращения времени восстановления работы СГО я разделил дамп БД на две части: все данные плюс продажи за последние несколько дней и дамп остальных старых продаж. Потом после восстановления БД из первого дампа после того, как я убедился в нормальном функционировании СГО, я заливаю в фоновом режиме второй дамп. Кстати, используя этот метод, можно существенно ускорить обновление СГО на новую версию..
 
"Спасибо" Onesoft от:
10.03.2014 04:01  
Tiger
Влил дамп на тестовом сервере в чистую базу, всё прошло нормально! Всем спасибо кто откликнулся!
 
 
Опции темы



Часовой пояс GMT +3, время: 15:33.

Все в прочитанное - Календарь - RSS - - Карта - Вверх 👫 Яндекс.Метрика
Форум сделан на основе vBulletin®
Copyright ©2000 - 2016, Jelsoft Enterprises Ltd. Перевод: zCarot и OlegON
В случае заимствования информации гипертекстовая индексируемая ссылка на Форум обязательна.