O
(@perdyllo)
База данных 6гб?!!! Вы ничего не путаете? Может быть речь идёт об общем объёме сайта?
И вообще о какой конвертации идёт речь? Указанный плагин переносит сайт с Джумлы на ВП и ничего не конвертирует.
Наверняка вы имеете в виду общий объем сайта включая вложения. И в этом нет ничего удивительного, так как WP генерирует из загруженных картинок дополнительные изображения с разными размерами. В этом его специфика. Также текущая тема оформления тоже может генерировать доп. изображения для своего правильного функционирования.
А «вес» таблиц БД как правило исчисляется в килобайтах. Может быть в мегабайтах. Но никак не в гигабайтах
-
Ответ изменён 5 лет, 2 месяца назад пользователем
O.
-
Ответ изменён 5 лет, 2 месяца назад пользователем O.
Нет, я ничего не путаю. Это не общий объем, а именно данные — архив новостей за 15 лет и база данных нормативных документов, причем практически без картинок. Темы оформления также никакой пока нет, ей я собирался заняться позже, когда конвертировал бы данные.
Размер файлов в каталоге с базой joomla.
du -h
6,5G
-
Ответ изменён 5 лет, 2 месяца назад пользователем
Ppaa.
Всего около 165000 записей. Однако уже на примерно 22000 объем wp_options.ibd составляет 11 Гб, 2 пара файлов fts*index.ibd по 1,2 Гб, хотя wp_posts — 900 Мб.
Возможно, это особенность работы плагина.
И возможно после конвертации всё придёт в норму.
Но лучше такие вопросы задавать разработчикам плагина.
В результате очень быстро заканчивается свободное место.
Подскажите, как можно решить эту проблему?
Самое очевидное — взять на хостинге больше места. Хотя бы на несколько дней.
Проблема оказалась в полнотекстовых индексах для wp_posts удалил их, размер перестал расти бешеными темпами.
Проблема оказалась в полнотекстовых индексах для wp_posts удалил их,
Что Вы имеете ввиду? В тч и что-как делали?
Удаление полнотекстового индекса
SHOW CREATE TABLE wp_posts;
В структуре таблицы были строки, начинающиеся с
FULLTEXT KEY
У меня это были
crp_related
crp_related_title
crp_related_content
Для mysql 8 возможно понадобятся следующие команды
set global sql_mode=’ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION’ ;
set session sql_mode=’ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION’ ;
Затем
ALTER TABLE wp_posts DROP INDEX crp_related;
ALTER TABLE wp_posts DROP INDEX crp_related_title;
ALTER TABLE wp_posts DROP INDEX crp_related_content;
PS. Однако в итоге это еще не все. Таблица wp_options все равно достигла 12 Гб и место снова закончилось, но был найден плагин https://ru.wordpress.org/plugins/fg-fix-serialized-strings/ от разработчика FG Joomla, который возможно поможет решить и эту проблему. Сейчас снова запустил конвертацию, наблюдаю за процессом.
Добавление плагина ситуацию не меняет, wp_options также растет.
Немного улучшает ситуацию периодический запуск wp db optimize.
Не пойму, почему все-таки wp_options растет? Можно ли безболезненно отключить autoload в этой таблице?
Отключение autoload приведёт к большому количеству запросов на сайте, но на размер базы вряд ли повлияет.
