Zwalnianie miejsca na dysku po usunięciu bazy danych

Pracuję nad systemem deweloperów i przywracam do bazy danych, powiedz „foo”, której używam do celów programistycznych. Gdy pracuję nad załamaniami, właśnie uruchomiłem DROP DATABASE foo. Szybko jednak zdałem sobie sprawę, że zjadłem całe miejsce na dysku. Bzdury.

Czy VACUUM FULL z innej logicznej bazy danych zwalnia miejsce z bazy danych, którą wcześniej upuściłem (foo)? Próbowałem tego z innej logicznej bazy danych i odzyskano wolne miejsce, ale nie sądzę, że wystarczyło uwzględnić wszystkie wywołania CREATE DATABASE / DROP DATABASE, które wykonałem. Być może właśnie VACUUM wykorzystało logiczną bazę danych, z której uruchomiłem.

Musi istnieć sposób na odzyskanie tego miejsca bez wykonania całkowitej inicjalizacji bazy danych?

EDYTOWAĆ

Ponownie zainicjowałem bazę danych z kopii zapasowej, z grubsza wykonując te kroki . Po przywróceniu odzyskałem TONĘ miejsca na dysku! Działa to na razie, ale wszelka pomoc dotycząca czyszczenia upuszczonej bazy danych nadal byłaby przydatna.

EDYCJA 2

Udało mi się zebrać więcej informacji o tym problemie ... Oto przykład, który wymyśliłem:

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

Wydaje mi się więc, że nowa baza danych zajęła ~ 9,6 GB na dysku. Jednak po upuszczeniu odzyskane miejsce na dysku wzrosło tylko o ~ 4,6G. Jest więc około 5 GB miejsca, co sprawia, że ​​zastanawiam się, co się dzieje !?

I kontynuuje ten cykl, gdy ponownie tworzę, wypełniam i upuszczam.

Czy ktoś ma pojęcie, co pozostaje po wydaniu polecenia „DROP DATABASE”?

Spróbuj sudo lsof| grep deletedsprawdzić, czy pojawi się jakikolwiek proces PostgreSQL. To polecenie szuka plików, które zostały usunięte, ale jego deskryptory plików są nadal otwarte przez dowolny proces. Innym efektem ubocznym jest to df -hi du -sh /różni się. Wynika to z tego, że dupatrzy na system plików i podsumowuje rozmiar wszystkich plików, a dftakże urządzenie fizyczne.

Właśnie miałem problem z bazą danych, która nie zwalniała miejsca po DROP tableai to było przyczyną.

Jedyne znane mi rozwiązanie to zrestartowanie bazy danych. Może możesz spróbować wysłać reload (SIGHUP).

Rozumiem, że kiedy upuścisz bazę danych, to i jej pliki znikną.

O ile nie używasz obszarów tabel, każda baza danych powinna mieć swoje dane we własnym podkatalogu w $ PGDATA / base. Na przykład na jednym z moich serwerów (jako użytkownik 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

Teraz, jeśli tworzymy nową bazę danych, powinien istnieć jeszcze jeden podkatalog w $ 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

To właśnie widzimy ($ PGDATA / base / 83637 jest podkatalogiem nowej bazy danych).

Usunięcie tej bazy danych powinno również usunąć pliki danych:

-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

Tego się spodziewalibyśmy - nie ma katalogu $ PGDATA / base / 83637, nie powinno być nic do odkurzania.

Czy na pewno nie ma czegoś innego, co pochłania miejsce na dysku? Jedna z twoich innych baz danych? pliki dziennika?

Można by spróbować:

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

wykonaj różne czynności związane z bazą danych, utwórz, upuść itp., a następnie:

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

aby dowiedzieć się, dokąd zmierza miejsce na dysku.