Цитата: 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 ТБ и для сокращения времени восстановления работы СГО я разделил дамп БД на две части: все данные плюс продажи за последние несколько дней и дамп остальных старых продаж. Потом после восстановления БД из первого дампа после того, как я убедился в нормальном функционировании СГО, я заливаю в фоновом режиме второй дамп. Кстати, используя этот метод, можно существенно ускорить обновление СГО на новую версию..