Какие таблицы безопасны для очистки?
Я унаследовал клиентский сайт с чрезвычайно большой базой данных без причины. Существует умеренное количество контента и очень мало модулей. Однако база данных слишком велика, чтобы легко перемещаться, и я хочу ее очистить.
Я очистил стандартные таблицы кэша, syslog и accesslog.
Есть ли другие таблицы, которые можно безопасно обрезать на стандартном сайте Drupal?
11 ответов
Используйте backup & migrate module , он содержит хорошие значения по умолчанию для пропуска ненужных данных. По умолчанию создается резервная копия БД без кеша, сторожевого таймера и некоторых других таблиц.
Если это не поможет посмотреть с phpMyAdmin и сообщить нам, какие таблицы содержат много записей.
Таблицы Drupal 7, которые можно исключить
Вот список таблиц в Drupal 7, который можно либо очистить (уменьшить размер базы данных), либо безопасно исключить, чтобы выполнить миграцию (как в вопросе о Как уменьшить локально экспортированный размер базы данных, чтобы обойти ограничение на импорт моего сервера ? ):
- accesslog
- партия
- все связанные с кешем таблицы, такие как:
- кэш *
- cache_block
- cache_content
- cache_filter *
- cache_form
- cache_calendar_ical
- cache_menu *
- cache_page *
- cache_views
- * _ cache, например features_cache или views_data_object_export_cache
- ctools_views_cache
- ctools_object_cache
- devel_queries
- devel_times
- Наводнение
- история
- очереди
- различные таблицы поиска *, такие как:
- search_dataset
- search_index
- search_keywords_log
- search_total
- Семафор
- сессии
- сторожевого
- webform_submitted_data li>
Обычно такие таблицы, как search_index
и watchdog
, используют много пространства базы данных, поэтому просто исключить эти две таблицы могут уже сейчас огромные различия.
Другие таблицы, которые могут быть исключены
Проверьте размер оставшихся таблиц и определите, какой из них самый большой по размеру.
Обычно вы можете найти таблицы сеансов, для которых не существует процедуры очистки. Такие таблицы, возможно, также можно исключить.
Резервное копирование и миграция модуля
Чтобы еще больше уменьшить проблему, как описано в « Как уменьшить локально экспортированный размер базы данных, чтобы обойти ограничение на импорт моего сервера? , посмотрите Backup and Migrate . Вот цитата с его страницы проекта (добавлена жирная разметка):
Резервное копирование и восстановление базы данных, кода и файлов Drupal MySQL или перенос сайта между средами. Резервное копирование и миграция поддерживает сжатие gzip, bzip и zip, а также автоматическое резервное копирование по расписанию.
С помощью «Резервное копирование» и «Миграция» вы можете сбросить некоторые или все ваши таблицы базы данных на загрузку или сохранение файла в файл на сервере или вне его, а также восстановить из загруженного или ранее сохраненного дампа базы данных. Вы можете выбрать, какие таблицы и какие данные для резервного копирования и кеширования исключаются по умолчанию .
И есть еще больше: если ваша локальная среда (например, Win или Mac) отличается от операционной системы, на которой работает сервер вашего размещенного веб-сайта (например, Linux), то эти различия между OS-es подразумевают потенциальные дополнительные проблемы. У меня был хороший опыт работы с модулем «Резервное копирование» и «Миграция» между различными операционными системами, что не вызвало никаких проблем (отлично работает) в ситуациях, когда ранее не выполнялся типичный экспорт /импорт MySql.
По моему опыту, я очищаю все таблицы «cache_ *».
- плюс «сторожевой таймер», если мне не нужны предыдущие журналы Drupal
- плюс "accesslog", если я не забочусь о зарегистрированных пользователях
- плюс «поиск», если мне не интересно содержимое индексированных узлов
Я иногда запускаю этот SQL, чтобы следить за ростом верхних таблиц:
SELECT *
FROM INFORMATION_SCHEMA.TABLES
WHERE TABLE_SCHEMA = 'yourdbnamehere'
ORDER BY table_rows DESC
Сторожевой таймер и сеансы также могут быть очищены, имейте в виду, что все пользователи будут выходить из системы.
С mySQL вы можете делать забавные вещи с помощью программы mysqldump для экспорта базы данных целиком или по частям. Например, это просто экспортирует структуру:
mysqldump -u root -pBatteryHorseStapleObviously -h some_host --no-data dbname > ~/dbname.sql
Затем вы можете использовать опцию «игнорировать таблицу» для дальнейшего экспорта данных, например.
mysqldump -u root -pBatteryHorseStapleObviously -h some_host --ignore-table=dbname.huge_table --ignore-table=dbname.massive_table --ignore-table=dbname.useless_table some_host >> ~/dbname.sql
Это помещает данные в конец предыдущего файла, игнорируя некоторые массивные таблицы.
Если вам нужны массивные таблицы, вы можете экспортировать их в другой файл, используя описанный выше подход, затем вы можете импортировать их в куски (хотя может потребоваться проверка f k).
Вы загружали файл перед загрузкой, или это глупый вопрос?
Используйте модуль OptimizeDB для очистки таблиц кеша. Администрирование базы данных также полезно.
Не забудьте создать резервную копию баз данных.
не супер эксперт по этому вопросу, но поделился своим опытом ... если вы не используете резервную копию и не переносите модуль и вручную экспортируете их, некоторые из таблиц, которые вы могли бы пустить /усекать, были бы watchdog
, cache
, cache_menu
, cache_block
, cache_content
, cache_form
), поскольку они могут содержать из-за большого количества очищенного кэшированного материала, которое, я полагаю, не повредит ... но опять же это мой опыт, и из-за этого я не сталкивался с проблемами или потерей данных.
Некоторые идеи:
- Совершенно другой подход - создать RSS-каналы, используя представления данных, которые вы хотите сохранить. Затем создайте новую установку Drupal и импортируйте эти данные с помощью API фида .
- И только другой подход: нанять студента и позволить ему /ей передавать данные вручную в вашу новую установку.
- Или это одно: Расскажите нам больше о том, какие таблицы очень велики и в чем причина этого (если вы знаете).
Отметьте example.drushrc.php
, которые перечислены ниже:
$options['structure-tables']['common'] = array('cache', 'cache_*', 'history', 'search_*', 'sessions', 'watchdog');
$options['skip-tables']['common'] = array('migration_*');
Безопасно их очищать с точки зрения перемещения базы данных между различными средами (особенно, когда вы работаете с большими базами данных ). Однако вам все равно нужно понять, что вы очищаете.
Дополнительные таблицы, которые можно очистить:
- партия
- webform_submitted_data li>
Другие вещи, которые могут занимать достаточно места: - более старые версии вашего контента (невозможно очистить простым усечением). - locales_source и locales_target. Если у вас есть языки, которые больше не используются или строковые переводы для модулей, которые вы больше не используете. Эти таблицы, кажется, никогда не очищаются.