Quelles tables sont sûres pour effacer?

40

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?

Nigel Waters
la source
1
Vous pouvez trier les tables en fonction de leur taille dans phpmyadmin. Essayez cela, puis regardez quelles tables sont les plus grandes et signalez-les ici. J'ai par exemple vu d'énormes tables de session qui n'ont pas été nettoyées pour une raison quelconque. C'est quelque chose que vous pouvez effacer si vous pouvez vivre avec des utilisateurs ayant à se connecter à nouveau (et éventuellement à perdre les données de formulaire saisies s'ils sont sur le site, alors vous voudrez peut-être coordonner cela avec les utilisateurs)
Berdir
Juste une note de côté ici, que toutes les réponses ci-dessous qui mentionnent le tronquage {cache_form}ne sont pas vraiment correctes. Ce n'est pas une vraie table de cache. Il contient des formulaires en cours de soumission. Si vous supprimez toutes les données de cette table, votre utilisateur risque de perdre des données. La bonne chose à faire avec cette table est d’expirer les entrées.
mpdonadio

Réponses:

21

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.

BetaRide
la source
1
C'est le premier endroit où je suis allé. Cependant, la base de données dépasse un gigaoctet et ne sauvegarde pas avec cette méthode. Mon intention est de vider la base de données afin que je puisse utiliser la sauvegarde et migrer de manière régulière. Essentiellement, je me demande s’il est possible de vider d’autres tables (qui ne sont pas ignorées par défaut par BAM).
Nigel Waters
Si vous avez un accès en ligne de commande, vous pouvez utiliser drush pour démarrer la sauvegarde et migrer. Vous pouvez également accéder à mysql en ligne de commande (exemple: mysqldump --host = your.host.com --user = utilisateur_bd --compress - mot de passe your_pw> dump.sql). Ainsi, vous ne rencontrerez pas de délais. En général, effacer sans une sauvegarde n'est pas très sauver. Vous pouvez facilement vous retrouver avec une page brisée et sans aucun moyen de revenir en arrière.
BetaRide
Le problème n'est pas avec les délais d'attente. Je sais que je peux facilement exécuter des sauvegardes avec ssh / drush. Je voudrais nettoyer la base de données car elle a été très souvent manipulée au cours des dernières années et contient beaucoup de choses inutiles. J'ai juste besoin de savoir quelles tables je peux effacer en toute sécurité, (pas savoir comment sauvegarder ou déplacer mon site).
Nigel Waters
@BetaRide est correct, les valeurs par défaut exclues par BAM sont les valeurs sûres. Les autres peuvent ou peuvent ne pas avoir de données réelles.
mpdonadio
22

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.

Pierre.Vriens
la source
Bon à ajouter que toutes les tables avec cache_préfixé ou en _cacheannexe sont sûrs tronquer ainsi, par exemple features_cacheou , views_data_object_export_cacheetc.
Beebee
1
Les données de la table de recherche peuvent être exclues, mais la reconstruction des index sur des sites volumineux peut prendre beaucoup de temps. Jugez ceci au cas par cas.
mpdonadio
2
En outre, l'extrait de B & M sur les données en cache est légèrement incorrect. Lorsqu'il est activé sur un site, il exclut les tables de cache. Toutefois, si vous ajoutez un module après la configuration de B & M, les tables de cache peuvent ne pas être ajoutées à la liste de données à exclure. J'ai vu cela se produire de nombreuses fois, généralement lorsque je remplace les paramètres du profil par défaut.
mpdonadio
@MPD: merci pour ce retour intéressant (je ne le savais pas encore!). A propos de la table de recherche: point valide. Personnellement, j’adopte toujours l’approche de reconstruction: cela permet de contourner la limitation et de garantir que l’index correspond au contenu réel de la cible. À propos de votre deuxième commentaire: l’extrait est un copier-coller de la page du projet, alors vous souhaitez peut-être archiver un problème à ce sujet dans sa file d’attente (Drupal.SE n’est pas l’endroit idéal pour les rapports sur les bogues, pas vrai?) .
Pierre.Vriens
@ Pierre.Vriens Faire correspondre le contenu ne devrait pas avoir d'importance, en supposant que cron soit en cours d'exécution et que l'indexation soit effectuée. B & M, à peu près sûr que c'est un problème connu. De plus, la section concernant les données de session n'est pas correcte à 100%. Ce tableau devient volumineux car le temps de session par défaut est d'environ trois semaines. _drupal_session_garbage_collectiongardera cette table rangée, en fonction des paramètres du système.
mpdonadio
19

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
thePanz
la source
1
Idem ici, j'aurais aussi des séances.
Alex Weber
2
Une note pour tous ceux qui tentent ceci: Créez d'abord une sauvegarde. Et ne laissez pas tomber les tables, plutôt vide ou tronquer.
timofey.com
9

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 
uwe
la source
Quelle colonne dois-je vérifier pour la croissance?, Vous voulez dire TABLE_ROWS
Bala
8

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

Attiks
la source
6

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?

Henry's Cat
la source
5

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.

M ama D
la source
la base de données est maintenant 14Mo, j'ai utilisé OptimizeDB, Thak you again
Mitch
@Mitch vous souhaite la bienvenue
M ama D
2

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.

optimusprime619
la source
2

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).
BetaRide
la source
2

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.

Kenorb
la source
1

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.

Fietserwin
la source