Ho ereditato un sito client che ha un database estremamente grande senza motivo. C'è una moderata quantità di contenuto e pochissimi moduli abilitati. Tuttavia, il database è troppo grande per spostarsi facilmente e voglio ripulirlo.

Ho cancellato le tabelle cache standard, syslog e accesslog.

Ci sono altri tavoli che posso troncare in modo sicuro in un sito Drupal standard?

Utilizza il modulo backup e migrazione , viene fornito con buone impostazioni predefinite per saltare i dati non necessari . Per impostazione predefinita, genera un backup del DB senza cache, watchdog e alcune altre tabelle.

Se questo non aiuta, dai un'occhiata a phpMyAdmin e dicci quali tabelle contengono molte voci.

Drupal 7 tabelle che possono essere escluse

Ecco un elenco di tabelle in Drupal 7 che puoi cancellare (per ridurre le dimensioni del database) o escludere in modo sicuro per eseguire una migrazione (come nella domanda su Come ridurre le dimensioni del database esportato localmente per aggirare il mio limite di importazione del server? ):

• AccessLog
• partita
• tutte le tabelle relative alla cache, come:
  • Cache *
  • cache_block
  • cache_content
  • cache_filter *
  • cache_form
  • cache_calendar_ical
  • cache_menu *
  • cache_page *
  • cache_views
  • * _cache, come features_cache o views_data_object_export_cache
• ctools_views_cache
• ctools_object_cache
• devel_queries
• devel_times
• alluvione
• storia
• coda
• varie tabelle search_ *, come:
  • search_dataset
  • search_index
  • search_keywords_log
  • search_total
• semaforo
• sessioni
• cane da guardia
• webform_submitted_data

Di solito tabelle come search_indexe watchdogusano molto spazio nel database, quindi eliminare queste 2 tabelle può già fare una grande differenza.

Altre tabelle che potrebbero essere escluse

Controlla le dimensioni delle tabelle rimanenti e identifica quali sono le più grandi.

In genere è possibile trovare tabelle di sessioni per le quali non è in atto alcuna procedura di pulizia. Probabilmente puoi anche escludere tali tabelle.

Modulo di backup e migrazione

Per ridurre ulteriormente la sfida, come spiegato in " Come ridurre le dimensioni del database esportato localmente per aggirare il limite di importazione del mio server? ", Guarda anche il modulo Backup e migrazione . Ecco una citazione dalla sua pagina del progetto (marcatura in grassetto aggiunta qui):

Eseguire il backup e il ripristino del database, del codice e dei file Drupal MySQL o migrare un sito tra ambienti. Backup e migrazione supporta la compressione gzip, bzip e zip, nonché i backup automatici pianificati.

Con Backup e migrazione è possibile scaricare alcune o tutte le tabelle del database in un file scaricato o salvarlo in un file sul server o fuori sede e ripristinare da un dump del database caricato o salvato in precedenza. È possibile scegliere quali tabelle e quali dati eseguire il backup e memorizzare nella cache i dati per impostazione predefinita .

E c'è ancora di più: se l'ambiente locale (ad esempio Win o Mac) differisce dal sistema operativo in esecuzione sul server del sito Web ospitato (come Linux), queste differenze tra i sistemi operativi implicano potenziali sfide extra. Ho avuto buone esperienze con il modulo Backup e migrazione tra diversi sistemi operativi, il che non ha causato problemi (ha funzionato bene) in situazioni in cui l'esportazione / importazione tipica di MySql non è riuscita prima.

Nella mia esperienza, elimino tutte le tabelle "cache_ *".

• più "cane da guardia" se non mi importa dei registri Drupal precedenti
• più "accesslog" se non mi interessano gli utenti che hanno effettuato l'accesso
• più "cerca" se non mi interessa il contenuto dei nodi indicizzati

A volte eseguo questo SQL per tenere d'occhio la crescita delle tabelle principali:

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

Il watchdog e le sessioni possono anche essere cancellati, tenere presente che tutti gli utenti verranno disconnessi.

Con mySQL puoi fare cose divertenti con il programma mysqldump per esportare il database nella sua interezza o in parti. Ad esempio, questo esporta solo la struttura:

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

È quindi possibile utilizzare l'opzione 'ignora tabella' per esportare ulteriormente i dati, ad es

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

Ciò posiziona i dati alla fine del file precedente ignorando alcune tabelle di massa.

Se poi hai bisogno delle enormi tabelle, puoi esportarle in un altro file usando l'approccio sopra, puoi quindi importarle in blocchi (anche se potrebbe essere necessario spuntare fk).

Hai decompresso il tuo file prima del caricamento o è una domanda stupida?

Utilizzare il modulo OptimizeDB per pulire le tabelle della cache. Anche l' amministrazione del database è utile.

Non dimenticare di avere un backup dei database.

Non il super esperto su questo, ma condividere la mia esperienza ... se non si sta utilizzando il backup e il modulo di migrazione e manualmente esportarli alcune delle tabelle si può svuotare / troncare sarebbe watchdog, cache, cache_menu, cache_block, cache_content, cache_formin quanto potrebbe contenere un grande quantità di operazioni di memorizzazione nella cache che suppongo non farebbero male ... ma di nuovo questa è la mia esperienza e non ho riscontrato problemi o perdita di dati a causa di ciò.

Qualche idea:

• Un approccio completamente diverso sarebbe quello di creare feed RSS utilizzando le visualizzazioni dei dati che si desidera conservare. Quindi crea una nuova installazione di Drupal e importa questi dati con l' API Feed .
• E solo un altro approccio: assumere uno studente e lasciarlo trasferire manualmente i dati nella nuova installazione.
• O questo: dicci di più su quali tabelle sono molto grandi e qual è il motivo (se lo sai).

Controlla example.drushrc.phpquale elenco questi:

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

È sicuro cancellarli in termini di spostamento del database tra ambienti diversi (specialmente quando si lavora con database di grandi dimensioni ). Tuttavia, devi ancora capire cosa stai cancellando.

Tabelle aggiuntive che possono essere cancellate:

• partita
• webform_submitted_data

Altre cose che potrebbero occupare un po 'di spazio: - versioni precedenti dei tuoi contenuti (non è possibile pulire con un semplice troncato). - locales_source e locales_target. Se hai lingue che non vengono più utilizzate o traduzioni di stringhe per moduli che non usi più. Queste tabelle sembrano non essere mai pulite.