Quels tableaux peuvent être effacés en toute sécurité?
J'ai hérité d'un site client qui possède une base de données extrêmement volumineuse sans 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 se déplacer facilement et je veux la nettoyer.
J'ai effacé les tables de cache standard, syslog et accesslog.
Y a-t-il d'autres tables que je peux tronquer en toute sécurité dans un site standard Drupal?
Utilisez le module de sauvegarde et de migration , il est livré avec bons paramètres 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, chien de garde et quelques autres tables.
Si cela n'aide pas, jetez un œil à phpMyAdmin et dites-nous quelles tables ont beaucoup d'entrées.
Tables Drupal 7 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é pour faire une migration (comme dans la question sur 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_block
- 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
- flood
- histoire
- queue
- diverses tables de recherche_ *, telles que:
- search_dataset
- search_index
- search_keywords_log
- search_total
- sémaphore
- séances
- chien de garde
- webform_submitted_data
Des tables telles que search_index et watchdog utilisent beaucoup d'espace de base de données, donc la simple suppression de ces 2 tables peut déjà faire une énorme différence.
Autres tableaux qui pourraient être exclus
Vérifiez la taille de vos tables restantes et identifiez laquelle est la plus grande.
En règle générale, vous pouvez trouver des tables de session pour lesquelles aucune procédure de nettoyage n'est en place. Ces tableaux, vous pouvez probablement également exclure.
Sauvegarde et migration de module
Pour réduire davantage le défi, comme indiqué dans " Comment réduire la taille de la base de données exportée localement pour contourner la limite d'importation de mon serveur? ", consultez également le module Sauvegarder et migrer . Voici une citation de sa page de projet (balisage gras ajouté ici):
Sauvegardez et restaurez votre base de données, code et fichiers MySQL Drupal) ou migrez un site entre des environnements. Backup and Migrate prend en charge la compression gzip, bzip et Zip ainsi que les sauvegardes programmées automatiques.
Avec Backup and Migrate, vous pouvez vider une partie ou la totalité de vos tables de base de données dans un fichier à télécharger ou enregistrer dans un fichier sur le serveur ou hors site, et à restaurer à partir d'une image de base de données téléchargée ou précédemment enregistrée. Vous pouvez choisir quelles tables et quelles données sauvegarder et mettre en cache les données 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é exécute (comme Linux), alors ces différences entre les 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 pas posé de problème (a bien fonctionné) dans des situations où l'exportation/importation typique de MySql a é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 historiques Drupal logs
- plus "accesslog" si je me fiche des utilisateurs connectés
- plus "recherche" si je ne me soucie pas du contenu des nœuds indexés
J'exécute parfois ce SQL pour garder un œil sur la croissance des tables supérieures:
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 le tableau '' pour exporter davantage de données, par ex.
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 massives.
Si vous avez ensuite besoin des tables massives, vous pouvez les exporter vers un fichier différent en utilisant l'approche ci-dessus, vous pouvez ensuite les importer en morceaux (bien que des vérifications f k puissent être nécessaires).
Vous avez compressé votre fichier avant de le télécharger, ou est-ce une question stupide?
Utilisez le module OptimizeDB pour nettoyer les tables de cache. Administration de la base de données est également utile.
N'oubliez pas d'avoir une sauvegarde des bases de données.
Vérifier la example.drushrc.php qui en énumère:
$options['structure-tables']['common'] = array('cache', 'cache_*', 'history', 'search_*', 'sessions', 'watchdog');
$options['skip-tables']['common'] = array('migration_*');
Il est sûr de les effacer en termes de déplacement de la base de données entre différents environnements (surtout lorsque vous travaillez avec de grandes bases de données ). Cependant, vous devez toujours comprendre ce que vous effacez.
pas le super expert à ce sujet mais partageant mon expérience ... si vous n'utilisez pas le module de sauvegarde et de migration et que vous les exportez manuellement, certaines des tables que vous pourriez vider/tronquer seraient watchdog, cache, cache_menu, cache_block, cache_content, cache_form car ils pourraient contenir une grande quantité d'effacement de trucs en cache 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 serait de créer des flux RSS en utilisant vues des données que vous souhaitez conserver. Ensuite, créez une nouvelle installation Drupal et importez ces données avec Feed API .
- Et juste une autre approche: embauchez un étudiant et laissez-le transférer manuellement les données dans votre nouvelle installation.
- Ou celui-ci: dites-nous plus sur quelles tables sont très énormes et quelle est la raison de cela (si vous le savez).
Tableaux supplémentaires pouvant être effacés:
- lot
- webform_submitted_data
Autres choses qui pourraient prendre un peu de place: - les anciennes versions de votre contenu (impossible de nettoyer avec une simple troncature). - locales_source et locales_target. Si vous avez des langues qui ne sont plus utilisées ou des traductions de chaînes pour les modules que vous n'utilisez plus. Ces tables semblent ne jamais être nettoyées.