Odziedziczyłem witrynę klienta, która ma bardzo dużą bazę danych bez powodu. Istnieje umiarkowana ilość treści i bardzo mało włączonych modułów. Baza danych jest jednak zbyt duża, aby można ją było łatwo przenosić i chcę ją wyczyścić.

Wyczyściłem standardowe tabele pamięci podręcznej, syslog i dziennik dostępu.

Czy są jakieś inne tabele, które mogę bezpiecznie obciąć w standardowej witrynie Drupal?

Użyj modułu tworzenia kopii zapasowych i migracji , który ma dobre ustawienia domyślne do pomijania niepotrzebnych danych . Domyślnie generuje kopię zapasową DB bez pamięci podręcznej, watchdoga i niektórych innych tabel.

Jeśli to nie pomoże, zajrzyj do phpMyAdmin i powiedz nam, które tabele zawierają wiele wpisów.

Drupal 7 tabel, które można wykluczyć

Oto lista tabel w Drupal 7, które możesz albo wyczyścić (aby zmniejszyć rozmiar bazy danych), albo bezpiecznie wykluczyć przeprowadzenie migracji (jak w pytaniu o to, jak zmniejszyć rozmiar lokalnie eksportowanej bazy danych, aby ominąć limit importu mojego serwera? ):

• dziennik dostępu
• partia
• wszystkie tabele związane z pamięcią podręczną, takie jak:
  • Pamięć podręczna*
  • blok_pamięci podręcznej
  • cache_content
  • cache_filter *
  • cache_form
  • cache_calendar_ical
  • menu podręczne *
  • cache_page *
  • cache_views
  • * _cache, na przykład cache_cache lub cache_portu_danych_obiektu
• ctools_views_cache
• ctools_object_cache
• devel_queries
• devel_times
• powódź
• historia
• kolejka
• różne tabele search_ *, takie jak:
  • search_dataset
  • search_index
  • search_ke words_log
  • search_total
• semafor
• sesje
• pies podwórzowy
• webform_submitted_data

Zwykle tabele takie jak search_indexi watchdogzajmują dużo miejsca w bazie danych, więc samo wyeliminowanie tych 2 tabel może już mieć ogromną różnicę.

Inne tabele, które można wykluczyć

Sprawdź rozmiar pozostałych tabel i określ, który z nich ma największy rozmiar.

Zazwyczaj można znaleźć tabele sesji, dla których nie ma procedury czyszczenia. Takie tabele można prawdopodobnie również wykluczyć.

Moduł tworzenia kopii zapasowych i migracji

Aby jeszcze bardziej ograniczyć to wyzwanie, jak opisano w „ Jak zmniejszyć lokalnie eksportowany rozmiar bazy danych, aby ominąć limit importu mojego serwera? ”, Spójrz także na moduł Kopia zapasowa i migracja . Oto cytat ze strony projektu (dodano tu pogrubiony znacznik):

Wykonaj kopię zapasową i przywróć bazę danych Drupal MySQL, kod i pliki lub migruj witrynę między środowiskami. Backup and Migrate obsługuje kompresję gzip, bzip i zip, a także automatyczne zaplanowane kopie zapasowe.

Dzięki Backup and Migrate możesz zrzucić niektóre lub wszystkie tabele bazy danych do pliku do pobrania lub zapisać w pliku na serwerze lub poza nim, a także przywrócić z przesłanego lub wcześniej zapisanego zrzutu bazy danych. Możesz wybrać, które tabele i jakie dane do utworzenia kopii zapasowej i pamięci podręcznej są domyślnie wykluczone .

Jest jeszcze więcej: jeśli Twoje środowisko lokalne (np. Win lub Mac) różni się od systemu operacyjnego, w którym działa serwer hostowanej witryny (np. Linux), to różnice między systemami operacyjnymi oznaczają potencjalne dodatkowe wyzwania. Miałem dobre doświadczenia z modułem Backup and Migrate między różnymi systemami operacyjnymi, co nie spowodowało żadnych problemów (działało dobrze) w sytuacjach, w których typowy eksport / import MySql wcześniej nie powiódł się.

Z doświadczenia wiem, że usuwam wszystkie tabele „cache_ *”.

• plus „watchdog”, jeśli nie dbam o wcześniejsze logi Drupala
• plus „dziennik dostępu”, jeśli nie dbam o zalogowanych użytkowników
• plus „szukaj”, jeśli nie dbam o zawartość indeksowanych węzłów

Czasami uruchamiam ten SQL, aby obserwować wzrost liczby najlepszych tabel:

SELECT * 
FROM INFORMATION_SCHEMA.TABLES
WHERE TABLE_SCHEMA =  'yourdbnamehere'
ORDER BY table_rows DESC 

Watchdog i sesje można również wyczyścić, pamiętaj, że wszyscy użytkownicy zostaną wylogowani.

Dzięki mySQL możesz robić fajne rzeczy z programem mysqldump, aby eksportować bazę danych w całości lub w części. Na przykład to po prostu eksportuje strukturę:

mysqldump -u root -pBatteryHorseStapleObviously -h some_host --no-data dbname > ~/dbname.sql

Następnie możesz użyć opcji „zignoruj ​​tabelę” w celu dalszego eksportu danych, np

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

To umieszcza dane na końcu wcześniejszego pliku, ignorując niektóre ogromne tabele.

Jeśli następnie potrzebujesz ogromnych tabel, możesz je wyeksportować do innego pliku, stosując powyższe podejście, możesz następnie zaimportować je we fragmentach (chociaż może być konieczne wyłączenie kontroli fk).

Skopiowałeś plik przed przesłaniem, czy to głupie pytanie?

Użyj modułu OptimizeDB , aby wyczyścić tabele pamięci podręcznej. Administracja bazy danych jest również pomocne.

Nie zapomnij mieć kopii zapasowej baz danych.

nie super ekspertem od tego, ale dzielenie się moje doświadczenie ... jeśli nie korzystasz z kopii zapasowej oraz moduł migrować i ręcznie wyeksportować je niektórych stołach można opróżnić / truncate byłoby watchdog, cache, cache_menu, cache_block, cache_content, cache_formponieważ mogą one zawierać duże ilość usuwanych danych z pamięci podręcznej, która, jak sądzę, nie zaszkodzi ... ale znowu to jest moje doświadczenie i nie napotkałem z tego powodu problemów ani utraty danych.

Jakieś pomysły:

• Zupełnie innym podejściem byłoby tworzenie kanałów RSS przy użyciu widoków danych, które chcesz zachować. Następnie utwórz nową instalację Drupal i zaimportuj te dane za pomocą Feed API .
• I jeszcze jedno podejście: Zatrudnij studenta i pozwól mu ręcznie przenieść dane do nowej instalacji.
• Lub ten: Powiedz nam więcej o tym, które tabele są bardzo duże i jaki jest tego powód (jeśli wiesz).

Sprawdź, example.drushrc.phpktóra lista:

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

Można je bezpiecznie wyczyścić w zakresie przenoszenia bazy danych między różnymi środowiskami (szczególnie podczas pracy z dużymi bazami danych ). Jednak nadal musisz zrozumieć, co rozliczasz.

Dodatkowe tabele, które można wyczyścić:

• partia
• webform_submitted_data

Inne rzeczy, które mogą zająć trochę miejsca: - starsze wersje treści (niemożliwe do wyczyszczenia za pomocą prostego obcięcia). - locales_source i locales_target. Jeśli masz języki, które nie są już używane lub tłumaczenia ciągów dla modułów, których już nie używasz. Te tabele wydają się nigdy nie zostać oczyszczone.