Поддержка Проблемы и решения Как Разрастание базы при конвертации из Joomla в WP

  • Здравствуйте!

    Конвертирую бд Joomla ~ 6ГБ в WP с помощью плагина FG Joomla. Всего около 165000 записей. Однако уже на примерно 22000 объем wp_options.ibd составляет 11 Гб, 2 пара файлов fts*index.ibd по 1,2 Гб, хотя wp_posts — 900 Мб. В результате очень быстро заканчивается свободное место.
    Подскажите, как можно решить эту проблему?

Просмотр 9 ответов — с 1 по 9 (всего 9)
  • База данных 6гб?!!! Вы ничего не путаете? Может быть речь идёт об общем объёме сайта?
    И вообще о какой конвертации идёт речь? Указанный плагин переносит сайт с Джумлы на ВП и ничего не конвертирует.

    Наверняка вы имеете в виду общий объем сайта включая вложения. И в этом нет ничего удивительного, так как WP генерирует из загруженных картинок дополнительные изображения с разными размерами. В этом его специфика. Также текущая тема оформления тоже может генерировать доп. изображения для своего правильного функционирования.

    А «вес» таблиц БД как правило исчисляется в килобайтах. Может быть в мегабайтах. Но никак не в гигабайтах

    • Ответ изменён 3 нед., 4 дн. назад пользователем  Spectrum.
    • Ответ изменён 3 нед., 4 дн. назад пользователем  Spectrum.

    Нет, я ничего не путаю. Это не общий объем, а именно данные — архив новостей за 15 лет и база данных нормативных документов, причем практически без картинок. Темы оформления также никакой пока нет, ей я собирался заняться позже, когда конвертировал бы данные.
    Размер файлов в каталоге с базой joomla.
    du -h
    6,5G

    • Ответ изменён 3 нед., 4 дн. назад пользователем  Ppaa.
    Модератор SeVlad

    (@sevlad)

    wp.me/3YHjQ

    Всего около 165000 записей. Однако уже на примерно 22000 объем wp_options.ibd составляет 11 Гб, 2 пара файлов fts*index.ibd по 1,2 Гб, хотя wp_posts — 900 Мб.

    Возможно, это особенность работы плагина.
    И возможно после конвертации всё придёт в норму.

    Но лучше такие вопросы задавать разработчикам плагина.

    В результате очень быстро заканчивается свободное место.
    Подскажите, как можно решить эту проблему?

    Самое очевидное — взять на хостинге больше места. Хотя бы на несколько дней.

    Проблема оказалась в полнотекстовых индексах для wp_posts удалил их, размер перестал расти бешеными темпами.

    Модератор SeVlad

    (@sevlad)

    wp.me/3YHjQ

    Проблема оказалась в полнотекстовых индексах для 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 в этой таблице?

    Модератор Sergey Biryukov

    (@sergeybiryukov)

    Live and Learn

    Отключение autoload приведёт к большому количеству запросов на сайте, но на размер базы вряд ли повлияет.

Просмотр 9 ответов — с 1 по 9 (всего 9)