Osennij_Lis:
Решил тут обновиться с 9.1.7.1 на 9.2 и выше. При обновлении система ругнулась на слишком большой лог файл. Погуглив эту тему, я наткнулся на плагин purge_logs, и воспользовался им. После чего запустил оптимизацию базы mysql.
В результате база стала весить вместо 3.7Gb - 100Mb. При этом в веб интерфейсе все осталось на месте и архив ПК, и схемы сетей и тикеты. Тоесть инфы как раз на 3.7GB, но mysql показыват 100Mb.
Если сделать дамп уже оптимизированной базы и развернуть на новом сервере - никакой инфы в веб интерфейсе уже нет. Ни ПК, ни юзеров, ни тикетов.
Сравнил таблицы из бэкапа до оптимизации и после - разнива только в таблице glpi_logs.
До оптимизации она весила 3.6Gb, после оптимизации 50Mb.
И я вот в замешательстве. Как так то? Почему вся инфа хранится в одной таблице и почему рекомендуется использовать purge_logs если он приводит к таким результатам. И как после использования purge_logs в таком случае переносить базу при необходимости.
Решил тут обновиться с 9.1.7.1 на 9.2 и выше. При обновлении система ругнулась на слишком большой лог файл. Погуглив эту тему, я наткнулся на плагин purge_logs, и воспользовался им. После чего запустил оптимизацию базы mysql.
В результате база стала весить вместо 3.7Gb - 100Mb. При этом в веб интерфейсе все осталось на месте и архив ПК, и схемы сетей и тикеты. Тоесть инфы как раз на 3.7GB, но mysql показыват 100Mb.
Если сделать дамп уже оптимизированной базы и развернуть на новом сервере - никакой инфы в веб интерфейсе уже нет. Ни ПК, ни юзеров, ни тикетов.
Сравнил таблицы из бэкапа до оптимизации и после - разнива только в таблице glpi_logs.
До оптимизации она весила 3.6Gb, после оптимизации 50Mb.
И я вот в замешательстве. Как так то? Почему вся инфа хранится в одной таблице и почему рекомендуется использовать purge_logs если он приводит к таким результатам. И как после использования purge_logs в таком случае переносить базу при необходимости.