J'ai hérité d'un site client qui possède une base de données extrêmement volumineuse sans aucune raison. Il y a une quantité modérée de contenu et très peu de modules activés. Cependant, la base de données est trop volumineuse pour pouvoir être déplacée facilement et je souhaite la nettoyer.

J'ai effacé les tables de cache standard, syslog et accesslog.

Existe-t-il d'autres tables que je peux tronquer en toute sécurité sur un site Drupal standard?

Utilisez le module de sauvegarde et de migration , il est livré avec de bonnes valeurs par défaut pour ignorer les données non nécessaires . Par défaut, il génère une sauvegarde de base de données sans cache, sans chien de garde et quelques autres tables.

Si cela ne vous aide pas, jetez un œil à phpMyAdmin et dites-nous quelles tables contiennent de nombreuses entrées.

Drupal 7 tables pouvant être exclues

Voici une liste de tables dans Drupal 7 que vous pouvez effacer (pour réduire la taille de la base de données) ou exclure en toute sécurité d'une migration (comme dans la question intitulée Comment réduire la taille de la base de données exportée localement pour contourner la limite d'importation de mon serveur? ):

• accesslog
• lot
• toutes les tables liées au cache, telles que:
  • cache *
  • cache_bloc
  • cache_content
  • cache_filter *
  • cache_form
  • cache_calendar_ical
  • cache_menu *
  • cache_page *
  • cache_views
  • * _cache, tel que features_cache ou views_data_object_export_cache
• ctools_views_cache
• ctools_object_cache
• devel_queries
• devel_times
• inonder
• histoire
• queue
• diverses tables search_ *, telles que:
  • search_dataset
  • index_recherche
  • search_keywords_log
  • total_recherche
• sémaphore
• sessions
• chien de garde
• webform_submitted_data

Habituellement, les tables telles que search_indexet watchdogutilisant beaucoup d’espace de base de données, il suffit donc d’éliminer ces 2 tables pour faire une énorme différence.

Autres tables pouvant être exclues

Vérifiez la taille de vos tables restantes et identifiez lesquelles sont les plus grandes.

En règle générale, vous pouvez trouver des tables de session pour lesquelles aucune procédure de nettoyage n'est en place. Vous pouvez probablement également exclure de telles tables.

Module de sauvegarde et de migration

Pour réduire davantage le défi, comme indiqué dans " Comment réduire la taille de la base de données exportée localement afin de contourner la limite d'importation de mon serveur? ", Consultez également le module Sauvegarde et migration . Voici une citation de sa page de projet (annotations en gras ajoutées ici):

Sauvegardez et restaurez votre base de données MySQL Drupal, votre code et vos fichiers, ou migrez un site entre environnements. Backup and Migrate prend en charge la compression gzip, bzip et zip ainsi que les sauvegardes automatiques programmées.

Avec Backup and Migrate, vous pouvez transférer tout ou partie de vos tables de base de données vers un fichier téléchargé ou sauvegardé dans un fichier sur le serveur ou hors site, et restaurer à partir d'un vidage de la base de données téléchargé ou précédemment enregistré. Vous pouvez choisir les tables et les données à sauvegarder et les données en cache sont exclues par défaut .

Et il y a encore plus: si votre environnement local (par exemple Win ou Mac) diffère du système d'exploitation que le serveur de votre site Web hébergé est en cours d'exécution (comme Linux), ces différences entre systèmes d'exploitation impliquent des défis supplémentaires potentiels. J'ai eu de bonnes expériences avec le module de sauvegarde et de migration entre différents systèmes d'exploitation, ce qui n'a posé aucun problème (a bien fonctionné) dans les cas où l'exportation / importation MySql classique avait échoué auparavant.

D'après mon expérience, je purge toutes les tables "cache_ *".

• plus "chien de garde" si je ne me soucie pas des journaux Drupal passés
• plus "accesslog" si je ne me soucie pas des utilisateurs connectés
• plus "recherche" si je ne me soucie pas du contenu des noeuds indexés

Je lance parfois ce SQL pour garder un œil sur la croissance des premières tables:

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

Le chien de garde et les sessions peuvent également être effacés, gardez à l'esprit que tous les utilisateurs seront déconnectés.

Avec MySQL, vous pouvez faire des choses amusantes avec le programme mysqldump pour exporter la base de données dans son intégralité ou en partie. Par exemple, cela exporte simplement la structure:

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

Vous pouvez ensuite utiliser l'option "ignorer la table" pour poursuivre l'exportation des données, par exemple:

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

Cela place les données à la fin du fichier précédent en ignorant certaines tables volumineuses.

Si vous avez ensuite besoin des tables volumineuses, vous pouvez les exporter dans un fichier différent en utilisant l’approche ci-dessus, puis les importer en morceaux (bien que des vérifications fk puissent être nécessaires).

Vous avez déjà compressé votre fichier avant de télécharger, ou est-ce une question idiote?

Utilisez le module OptimizeDB pour nettoyer les tables de cache. L' administration de la base de données est également utile.

N'oubliez pas d'avoir une sauvegarde des bases de données.

pas super expert en la matière, mais partager mon expérience ... si vous n'utilisez pas la sauvegarde et le module Migrate et les exporter manuellement certaines des tables , vous pouvez vider / troncature serait watchdog, cache, cache_menu, cache_block, cache_content, cache_formcomme ils peuvent contenir un grand quantité de choses en cache effacer qui, je suppose, ne ferait pas de mal ... mais encore une fois c'est mon expérience et je n'ai pas rencontré de problèmes ou de perte de données à cause de cela.

Quelques idées:

• Une approche complètement différente consisterait à créer des flux RSS à l'aide de vues des données que vous souhaitez conserver. Créez ensuite une nouvelle installation Drupal et importez ces données avec Feed API .
• Et juste une autre approche: Engagez un étudiant et laissez-le transférer les données manuellement dans votre nouvelle installation.
• Ou celui-ci: Dites-nous en plus sur quelles tables sont très énormes et quelle en est la raison (si vous le savez).

Vérifiez la example.drushrc.phpliste de ceux-ci:

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

Vous pouvez les effacer en termes de déplacement de la base de données entre différents environnements (en particulier lorsque vous travaillez avec de grandes bases de données ). Cependant, vous devez toujours comprendre ce que vous effacez.

Tables supplémentaires pouvant être effacées:

• lot
• webform_submitted_data

Autres éléments susceptibles de prendre un peu de place: - les anciennes versions de votre contenu (impossible de nettoyer avec un simple tronqué). - locales_source et locales_target. Si vous avez des langues qui ne sont plus utilisées ou des traductions de chaînes pour des modules que vous n'utilisez plus. Ces tables semblent ne jamais être nettoyées.