Eu herdei um site cliente que possui um banco de dados extremamente grande sem motivo. Há uma quantidade moderada de conteúdo e muito poucos módulos ativados. No entanto, o banco de dados é muito grande para se mover facilmente e eu quero limpá-lo.

Limpei as tabelas de cache padrão, syslog e accesslog.

Existem outras tabelas que eu possa truncar com segurança em um site padrão do Drupal?

Use o módulo de backup e migração , ele vem com bons padrões para ignorar dados não necessários . Por padrão, ele gera um backup do banco de dados sem cache, watchdog e algumas outras tabelas.

Se isso não ajudar, consulte o phpMyAdmin e informe quais tabelas possuem muitas entradas.

Drupal 7 tabelas que podem ser excluídas

Aqui está uma lista de tabelas no Drupal 7 que você pode limpar (para reduzir o tamanho do banco de dados) ou excluir com segurança para fazer uma migração (como na pergunta sobre Como reduzir o tamanho do banco de dados exportado localmente para contornar o limite de importação do meu servidor? ):

• accesslog
• lote
• todas as tabelas relacionadas ao cache, como:
  • cache *
  • cache_block
  • cache_content
  • cache_filter *
  • cache_form
  • cache_calendar_ical
  • cache_menu *
  • cache_page *
  • cache_views
  • * _cache, como features_cache ou views_data_object_export_cache
• ctools_views_cache
• ctools_object_cache
• devel_queries
• devel_times
• inundar
• história
• fila
• várias tabelas de pesquisa_ *, como:
  • search_dataset
  • search_index
  • search_keywords_log
  • total da pesquisa
• semáforo
• sessões
• cão de guarda
• webform_submitted_data

Normalmente, tabelas como search_indexe watchdogusam muito espaço no banco de dados, portanto, apenas a eliminação dessas duas tabelas já pode fazer uma enorme diferença.

Outras tabelas que podem ser excluídas

Verifique o tamanho das tabelas restantes e identifique qual delas é a maior em tamanho.

Normalmente, você pode encontrar tabelas de sessões para as quais nenhum procedimento de limpeza está em vigor. Essas tabelas você provavelmente também pode excluir.

Backup e migração de módulos

Para reduzir ainda mais o desafio, conforme detalhado em " Como reduzir o tamanho do banco de dados exportado localmente para contornar o limite de importação do meu servidor? ", Consulte também o módulo Backup e Migrar . Aqui está uma citação de sua página do projeto (marcação em negrito adicionada aqui):

Faça backup e restaure o banco de dados, código e arquivos do Drupal MySQL ou migre um site entre ambientes. O Backup and Migrate suporta compactação gzip, bzip e zip, bem como backups agendados automáticos.

Com o Backup and Migrate, você pode despejar algumas ou todas as tabelas do banco de dados em um download de arquivo ou salvar em um arquivo no servidor ou fora do local e restaurar a partir de um despejo de banco de dados carregado ou salvo anteriormente. Você pode escolher quais tabelas e quais dados para backup e cache de dados são excluídos por padrão .

E há ainda mais: se o seu ambiente local (por exemplo, Win ou Mac) diferir do SO que o servidor do site hospedado está executando (como o Linux), essas diferenças entre os SOs implicam possíveis desafios extras. Eu tive boas experiências com o módulo Backup and Migrate entre diferentes sistemas operacionais, o que não causou nenhum problema (funcionou bem) em situações em que a exportação / importação típica do MySql falhou antes.

Na minha experiência, eu limpo todas as tabelas "cache_ *".

• mais "watchdog" se eu não me importo com os logs antigos do Drupal
• mais "accesslog" se eu não me importo com usuários logados
• mais "pesquisa" se eu não me importo com o conteúdo dos nós indexados

Às vezes, eu executo esse SQL para ficar de olho no crescimento das tabelas principais:

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

O watchdog e as sessões também podem ser limpos, lembre-se de que todos os usuários serão desconectados.

Com o mySQL, você pode fazer coisas divertidas com o programa mysqldump para exportar o banco de dados na sua totalidade ou em partes. Por exemplo, isso apenas exporta a estrutura:

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

Você pode usar a opção 'ignorar tabela' para exportar mais dados, por exemplo

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

Isso coloca os dados no final do arquivo anterior, ignorando algumas tabelas massivas.

Se você precisar das tabelas maciças, poderá exportá-las para um arquivo diferente usando a abordagem acima, importando-as em pedaços (embora possa ser necessário marcar o fk).

Você compactou seu arquivo antes de fazer o upload ou é uma pergunta boba?

Use o módulo OptimizeDB para limpar as tabelas de cache. A administração do banco de dados também é útil.

Não se esqueça de ter um backup dos bancos de dados.

não o super especialista sobre isso, mas partilhar a minha experiência ... se você não estiver usando a cópia de segurança e módulo de migrar manualmente e exportá-los algumas das tabelas que você poderia esvaziar / truncado seria watchdog, cache, cache_menu, cache_block, cache_content, cache_form, já que podem conter uma grande quantidade de limpeza de coisas em cache que suponho que não faria mal ... mas, novamente, essa é a minha experiência e não encontrei problemas ou perda de dados por causa disso.

Algumas ideias:

• Uma abordagem completamente diferente seria criar feeds RSS usando visualizações dos dados que você deseja manter. Em seguida, crie uma nova instalação do Drupal e importe esses dados com a API do Feed .
• E apenas uma outra abordagem: contrate um aluno e permita que ele transfira os dados manualmente para sua nova instalação.
• Ou este: conte-nos mais sobre quais tabelas são muito grandes e qual a razão disso (se você souber).

Verifique a example.drushrc.phplista que estes:

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

É seguro limpá-los em termos de movimentação do banco de dados entre diferentes ambientes (especialmente quando você está trabalhando com grandes bancos de dados ). No entanto, você ainda precisa entender o que está limpando.

Tabelas adicionais que podem ser limpas:

• lote
• webform_submitted_data

Outras coisas que podem ocupar bastante espaço: - versões mais antigas do seu conteúdo (não é possível limpar com um simples truncado). - locales_source e locales_target. Se você possui idiomas que não são mais usados ​​ou traduções de string para módulos que não são mais usados. Essas mesas parecem nunca ficar limpas.