Zwalnianie miejsca na dysku po usunięciu bazy danych

12

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”?

Jmoney38
źródło
Może warto również zauważyć, że mam włączoną archiwizację. Wygląda na to, że lokalizacja, w której zapisywane są pliki archiwów WAL, jest dość duża. Nie monitorowałem tego dokładnie. Może spróbuję wykonać tę samą procedurę, co wymieniona powyżej i uruchomić „du” w tym katalogu, aby sprawdzić, czy całe miejsce zostało odzyskane. Zamelduję się.
Jmoney38
Zakładam, że próżnia nie pomaga?
rogerdpack,

Odpowiedzi:

6

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).

charli
źródło
2
lsof | grep deletedWierzchołek był dobry; do tego dodaj, że musisz tylko ustalić, które sesje postgresql są nadal aktywne, i zabić je, aby zwolnić pliki. W moim przypadku spośród ponad 500 aktywnych połączeń, prawie wszystkich w IDLE lub COMMIT, zabicie pojedynczego, znalezionego SELECT * FROM pg_stat_activityi utkniętego w ANALIZIE, wystarczyło, aby zwolnić usunięte pliki. ! 00 GB uwolnione.
Alex North-Keys,
5

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.

gsiems
źródło
Widzę te same wyniki co ty - tzn. Kiedy dodam tabelę, nowy DB pojawia się w katalogu podstawowym, a kiedy go usuwam, nie ma go. Jednak katalog ten nie wydaje się obejmować całej różnicy wielkości (tj. ~ 9,6 GB)
Jmoney38,
@ Jmoney38 - Dlatego zaleciłem wykonanie „du -sh ls” w katalogu $ PGDATA zarówno przed, jak i po dodaniu / upuszczeniu bazy danych, ponieważ powinno to oznaczać, które inne katalogi mają coraz większy skok.
gsiems
@ Jmoney38 - Gdybym musiał zgadywać, powiedziałbym, że różnicę można znaleźć w katalogach $ PGDATA / pg_log i / lub $ PGDATA / pg_xlog. Pliki dziennika dotyczą klastra i nie są obcinane po upuszczeniu bazy danych.
gsiems