Libérer de l'espace disque après la suppression de la base de données

12

Je travaille sur un système de développement et j'ai restauré une base de données, disons "foo", que j'utilise à des fins de développement. Alors que je travaille sur les problèmes, je viens de lancer DROP DATABASE foo. Cependant, j'ai rapidement réalisé que j'avais consommé tout l'espace sur mon disque. Merde.

VACUUM FULL, d'une autre base de données logique, libère-t-il de l'espace de la base de données que j'ai précédemment supprimée (foo)? J'ai essayé cela à partir d'une base de données logique différente, et l'espace libre a été récupéré, mais je ne pense pas que c'était suffisant pour tenir compte de tous les appels CREATE DATABASE / DROP DATABASE que j'ai faits. Il se peut que cela ait simplement VIDE la base de données logique à partir de laquelle j'ai couru.

Il doit y avoir un moyen de récupérer cet espace sans faire d'initialisation totale de la base de données?

ÉDITER

J'ai donc réinitialisé la base de données à partir d'une sauvegarde, en suivant approximativement ces étapes . Après la restauration, j'ai récupéré une tonne d'espace sur le disque! Cela fonctionne pour l'instant, mais toute aide concernant la façon de nettoyer une base de données supprimée serait toujours utile.

EDIT 2

J'ai donc réussi à collecter plus d'informations sur ce problème ... Voici ce que j'ai trouvé à titre d'exemple:

Initial partition size:
                       Size   Used  Avail Use% Mounted on
                        25G   8.1G    16G  35% /apps1

After creating my new database and populating it:
                        25G    18G   6.4G  73% /apps1

After Dropping the database using "DROP database mydb" from a separate logical DB:
                        25G    13G    11G  56% /apps1

Il me semble donc que la nouvelle base de données occupait environ 9,6 Go sur le disque. Cependant, après l'avoir supprimé, l'espace disque récupéré n'a augmenté que de ~ 4,6 G. Donc, il y a environ 5 Go d'espace qui me font me demander ce qui se passe!?

Et il continue ce cycle lorsque je recrée, remplis et retombe.

Quelqu'un at-il une idée de ce qui subsiste après l'émission d'une commande "DROP DATABASE"?

postgresql disk-space Jmoney38
la source
Il est peut-être également utile de noter que l'archivage est activé. Il semble que l'emplacement dans lequel les fichiers d'archive WAL sont écrits est assez grand. Je ne l'ai pas suivi de près. Je vais peut-être essayer la même procédure que celle listée ci-dessus et exécuter un "du" sur ce répertoire pour voir si tout l'espace est récupéré. Je ferai rapport.
Jmoney38
Je suppose que le vide n'aide pas alors?
rogerdpack

Réponses:

6

Essayez de sudo lsof| grep deletedvérifier si un processus PostgreSQL apparaît. Cette commande recherche les fichiers qui ont été supprimés mais ses descripteurs de fichiers sont toujours ouverts par n'importe quel processus. Un autre effet secondaire est cela df -het du -sh /diffère. En effet, duexamine le système de fichiers et résume la taille de tous les fichiers, et dfexamine le périphérique physique.

Je viens d'avoir un problème avec une base de données qui n'a pas libéré d'espace après un DROP tableet c'était la cause.

La seule solution que je connaisse est de redémarrer la base de données. Vous pouvez peut-être essayer d'envoyer un rechargement (SIGHUP).

charli
la source
2
Le lsof | grep deletedpourboire était bon; à cela, ajoutez qu'il vous suffit de déterminer quelles sessions postgresql sont toujours actives et de les tuer pour libérer les fichiers. Dans mon cas, sur 500+ connexions actives, presque toutes en IDLE ou COMMIT, en tuer une seule, trouvée avec SELECT * FROM pg_stat_activityet coincée dans une ANALYSE, était suffisante pour libérer les fichiers supprimés. ! 00 Go libérés.
Alex North-Keys
5

Je crois comprendre que lorsque vous supprimez une base de données, elle et ses fichiers disparaissent.

Sauf si vous utilisez des tablespaces, chaque base de données doit avoir ses données dans son propre sous-répertoire sous $ PGDATA / base. En utilisant un de mes serveurs pour un exemple (en tant qu'utilisateur postgres):

-bash-3.2$ cd $PGDATA/base

-bash-3.2$ ls | wc -l
9

-bash-3.2$ du -sh `ls`
6.9M    1
6.7M    12690
6.9M    12698
11M     16391
341M    17339
3.8G    17341
11M     17343
6.8M    19047
8.0K    pgsql_tmp

Maintenant, si nous créons une nouvelle base de données, il devrait y avoir un sous-répertoire supplémentaire sous $ PGDATA / base:

-bash-3.2$ createdb foo

-bash-3.2$ ls | wc -l
10

-bash-3.2$ du -sh `ls`
6.9M    1
6.7M    12690
6.9M    12698
11M     16391
341M    17339
3.8G    17341
11M     17343
6.8M    19047
6.9M    83637
8.0K    pgsql_tmp

C'est ce que nous voyons ($ PGDATA / base / 83637 étant le sous-répertoire de la nouvelle base de données).

La suppression de cette base de données devrait également supprimer les fichiers de données:

-bash-3.2$ dropdb foo

-bash-3.2$ ls wc -l
9

-bash-3.2$ du -sh `ls`
6.9M    1
6.7M    12690
6.9M    12698
11M     16391
341M    17339
3.8G    17341
11M     17343
6.8M    19047
8.0K    pgsql_tmp

C'est ce à quoi nous nous attendrions - le répertoire $ PGDATA / base / 83637 a disparu, il ne devrait rien y avoir à aspirer.

Êtes-vous sûr qu'il n'y a rien d'autre qui consomme votre espace disque? Une de vos autres bases de données? fichiers journaux?

Vous pourriez essayer de:

-bash-3.2$ cd $PGDATA
-bash-3.2$ du -sh `ls` > ../pre_sizes

faites vos divers trucs de base de données, créez, supprimez, etc. puis:

-bash-3.2$ du -sh `ls` > ../post_sizes

pour avoir une idée de l’emplacement de l’espace disque.

gsiems
la source
Je vois les mêmes résultats que vous - c'est-à-dire lorsque j'ajoute la table, la nouvelle base de données apparaît dans le répertoire de base et quand je la supprime, elle disparaît. Cependant, ce répertoire ne semble pas comprendre toute la différence de taille (c'est-à-dire ~ 9,6 Go)
Jmoney38
@ Jmoney38 - C'est pourquoi j'ai recommandé de faire le "du -sh ls" sur le répertoire $ PGDATA à la fois avant et après avoir fait l'ajout / la suppression de la base de données, car cela devrait signaler les autres répertoires qui augmentent et sautent.
gsiems
@ Jmoney38 - Si je devais deviner, je dirais que la différence se trouve dans les répertoires $ PGDATA / pg_log et / ou $ PGDATA / pg_xlog. Les fichiers journaux sont pour le cluster et ne sont pas tronqués lorsque vous supprimez une base de données.
gsiems