Я успадкував сайт клієнта, який має надзвичайно велику базу даних без будь-яких причин. Існує помірний об'єм вмісту та дуже мало включених модулів. Однак база даних занадто велика, щоб легко пересуватися, і я хочу її очистити.

Я очистив стандартні таблиці кешу, syslog та accesslog.

Чи є якісь інші таблиці, які я можу сміливо врізати на стандартному Drupal-сайті?

Використовуйте модуль резервного копіювання та переміщення , він постачається з хорошими за замовчуванням для пропуску не потрібних даних . За замовчуванням він генерує резервну копію БД без кешу, сторожової та інших таблиць.

Якщо це не допомагає, подивіться на phpMyAdmin та скажіть нам, у яких таблицях багато записів.

Drupal 7 таблиць, які можна виключити

Ось перелік таблиць в Drupal 7, які ви можете очистити (зменшити розмір бази даних) або безпечно виключити, щоб зробити міграцію (як у питанні про те, як зменшити розмір бази даних, що експортуються на локальному рівні, щоб обійти ліміт імпорту мого сервера? ):

• accesslog
• партія
• всі таблиці, пов’язані з кешем, такі як:
  • кеш *
  • cache_block
  • cache_content
  • cache_filter *
  • cache_form
  • cache_calendar_ical
  • cache_menu *
  • cache_page *
  • cache_views
  • * _cache, наприклад, особливості_cache або views_data_object_export_cache
• ctools_views_cache
• ctools_object_cache
• devel_queries
• devel_times
• повінь
• історія
• чергу
• різні таблиці search_ *, такі як:
  • search_dataset
  • search_index
  • search_keywords_log
  • search_total
• семафор
• сеанси
• сторожовий
• webform_submitted_data

Зазвичай такі таблиці, як search_indexі watchdogвикористовують багато місця в базі даних, тому просто усунення цих двох таблиць вже може зробити величезну зміну.

Інші таблиці, які можуть бути виключені

Перевірте розмір решти таблиць і визначте, яка з них найбільша за розміром.

Зазвичай ви можете знайти таблиці сеансів, для яких немає процедури очищення. Такі таблиці, ймовірно, ви також можете виключити.

Резервне копіювання та міграція модулів

Щоб додатково зменшити виклик, як детально описано у розділі " Як зменшити розмір бази даних, що експортуються на локальному рівні, щоб подолати ліміт імпорту сервера? ", Також подивіться модуль " Резервне копіювання та перенесення" . Ось цитата зі сторінки проекту (сюди додано жирну розмітку):

Створіть резервну копію та відновіть свою базу даних, код та файли Drupal MySQL або перемістіть сайт між середовищами. Резервне копіювання та міграція підтримує стиснення gzip, bzip та zip, а також автоматичне планування резервного копіювання.

За допомогою резервного копіювання та міграції ви можете скинути деякі або всі таблиці ваших баз даних для завантаження файлу або збереження у файл на сервері або за межами сайту, а також відновити з завантаженого або раніше збереженого дампа бази даних. Ви можете вибрати, які таблиці та які дані для резервного копіювання та кешування даних за замовчуванням виключені .

І є ще більше: якщо ваше локальне середовище (наприклад, Win або Mac) відрізняється від ОС тим, що працює сервер вашого розміщеного веб-сайту (наприклад, Linux), то ці відмінності між ОС-ОС означають можливі додаткові проблеми. У мене був хороший досвід роботи з модулем "Резервне копіювання" та "Міграція" між різними ОС, який не спричинив жодних проблем (працював чудово) у ситуаціях, коли типовий експорт / імпорт 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

Це розміщує дані в кінці попереднього файлу, ігноруючи деякі масивні таблиці.

Якщо вам потрібні масивні таблиці, ви можете експортувати їх у інший файл, використовуючи вищезазначений підхід, потім можете імпортувати їх у шматки (хоча, можливо, знадобиться перевірка fk).

Ви gzip файл перед завантаженням, або це дурне питання?

Використовуйте модуль OptimizeDB для очищення таблиць кешу. Адміністрування баз даних також корисно.

Не забудьте створити резервну копію баз даних.

не супер фахівець з цього питання, але ділитися своїм досвідом ... якщо ви не використовуєте резервне копіювання і перенастроювання модуль і вручну експортувати деякі таблиці можна відкачати / усічення б watchdog, cache, cache_menu, cache_block, cache_content, так cache_formяк вони можуть містити велику кількість очищених кешованих матеріалів, які, напевно, не зашкодять ... але знову ж таки, це мій досвід, і я не стикався з проблемами або втратою даних через це.

Деякі ідеї:

• Зовсім інший підхід полягає у створенні RSS-каналів, використовуючи представлення даних, які ви хочете зберегти. Потім створіть свіжу інсталяцію Drupal та імпортуйте ці дані за допомогою API API .
• І лише інший підхід: найміть студента і дозвольте йому / їй перенести дані вручну у вашу нову установку.
• Або цей: Розкажіть більше про те, які таблиці дуже величезні і в чому причина цього (якщо ви знаєте).

Перевірте, example.drushrc.phpякий із них перелік:

$options['structure-tables']['common'] = array('cache', 'cache_*', 'history', 'search_*', 'sessions', 'watchdog');
$options['skip-tables']['common'] = array('migration_*');

Безпечно їх очистити з точки зору переміщення бази даних між різними середовищами (особливо коли ви працюєте з великими базами даних ). Однак вам ще потрібно зрозуміти, що ви очищаєте.

Додаткові таблиці, які можна очистити:

• партія
• webform_submitted_data

Інші речі, які можуть зайняти досить багато місця: - старіші версії вмісту (неможливо очистити за допомогою простого вкорочення). - locales_source та locales_target. Якщо у вас є мови, які вже не використовуються, або строкові переклади для модулів, які ви більше не використовуєте. Ці таблиці, здається, ніколи не очищаються.