Liberare spazio su disco dopo aver eliminato il database

12

Sto lavorando su un sistema di sviluppo e sto ripristinando un database, ad esempio "pippo", che sto usando per scopi di sviluppo. Mentre sto lavorando attraverso i nodi, ho appena eseguito DROP DATABASE foo. Tuttavia, ho realizzato rapidamente di aver mangiato tutto lo spazio sul mio disco. Una schifezza.

VACUUM FULL, da un database logico diverso, libera spazio dal database che ho precedentemente lasciato cadere (pippo)? Ho provato questo da un diverso database logico e lo spazio libero è stato recuperato, ma non PENSO che fosse abbastanza per tenere conto di tutte le chiamate CREATE DATABASE / DROP DATABASE che ho effettuato. Potrebbe avere appena VACUUM il database logico da cui sono partito.

Ci deve essere un modo per recuperare quello spazio senza fare un init database totale?

MODIFICARE

Quindi ho reinizializzato il database da un backup, seguendo approssimativamente questi passaggi . Dopo il ripristino, ho recuperato una tonnellata di spazio sul disco! Questo funziona per ora, ma qualsiasi aiuto per quanto riguarda la pulizia di un database eliminato sarebbe comunque utile.

MODIFICA 2

Quindi sono riuscito a raccogliere qualche informazione in più su questo problema ... Ecco cosa ho escogitato come esempio:

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

Quindi mi sembra che il nuovo DB abbia occupato ~ 9.6 GB su disco. Tuttavia, dopo averlo lasciato cadere, lo spazio su disco recuperato è cresciuto solo di ~ 4.6G. Quindi, ci sono circa 5 GB di spazio che mi fanno chiedermi cosa stia succedendo !?

E continua questo ciclo quando ricreare, popolare e rilasciare di nuovo.

Qualcuno ha idea di cosa indugi dopo l'emissione del comando "DROP DATABASE"?

postgresql disk-space

— Jmoney38
fonte

Forse vale anche la pena notare che l'archiviazione è attivata. Sembra che la posizione in cui vengono scritti i file di archivio WAL sia piuttosto grande. Non l'ho monitorato da vicino. Forse proverò la stessa procedura sopra elencata ed eseguirò un "du" su quella directory per vedere se tutto lo spazio viene recuperato. Riporterò indietro.

— Jmoney38,

Suppongo che il vuoto non aiuti allora?

— rogerdpack,

6

Prova sudo lsof| grep deletede controlla se appare qualche processo PostgreSQL. Questo comando cerca i file che sono stati eliminati ma i descrittori dei file sono ancora aperti da qualsiasi processo. Un altro effetto collaterale è quello df -he du -sh /differisce. Questo perché duesamina il file system e riassume le dimensioni di tutti i file e dfesamina il dispositivo fisico.

Ho appena avuto un problema con un database che non ha liberato spazio dopo una DROP tablee questa è stata la causa.

L'unica soluzione che conosco è riavviare il database. Forse puoi provare a inviare una ricarica (SIGHUP).

— Charli
fonte

2

La lsof | grep deletedpunta era buona; a ciò, aggiungi che devi solo determinare quali sessioni postgresql sono ancora attive e ucciderle per rilasciare i file. Nel mio caso, su oltre 500 connessioni attive, quasi tutte in IDLE o COMMIT, uccidendone una sola, trovata con SELECT * FROM pg_stat_activitye bloccata in un ANALYZE, era sufficiente per liberare i file eliminati. ! 00 GB liberati.

— Alex North-Keys,

5

La mia comprensione è che quando si elimina un database, esso e i suoi file scompaiono.

A meno che non si utilizzino tablespace, ogni database dovrebbe avere i propri dati nella propria sottodirectory in $ PGDATA / base. Usando uno dei miei server per un esempio (come l'utente 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

Ora, se creiamo un nuovo database, dovrebbe esserci un'altra sottodirectory in $ 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

Questo è ciò che vediamo ($ PGDATA / base / 83637 è la sottodirectory per il nuovo database).

Se si elimina quel database, è necessario eliminare anche i file di dati:

-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

Il che è quello che ci aspetteremmo: la directory $ PGDATA / base / 83637 è sparita, non dovrebbe esserci nulla da aspirare.

Sei sicuro che non ci sia qualcos'altro che consuma il tuo spazio su disco? Uno dei tuoi altri database? log files?

Qualcosa che potresti provare sarebbe:

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

fare le varie cose del database, creare, eliminare, ecc. e quindi:

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

per avere un'idea di dove sta andando lo spazio su disco.

— gsiems
fonte

Vedo gli stessi risultati che hai tu, ovvero quando aggiungo la tabella, il nuovo DB appare nella directory di base e quando lo rimuovo, non c'è più. Tuttavia, quella directory non sembra comprendere l'intera differenza di dimensioni (cioè ~ 9.6GB)

— Jmoney38

@ Jmoney38 - Ecco perché ho raccomandato di fare il "du -sh ls" nella directory $ PGDATA sia prima che dopo aver fatto il comando di aggiunta / eliminazione del database poiché ciò dovrebbe indicare quali altre directory stanno facendo passi da gigante.

— gsiems,

@ Jmoney38 - Se dovessi indovinare, direi che la differenza si trova nelle directory $ PGDATA / pg_log e / o $ PGDATA / pg_xlog. I file di registro sono per il cluster e non vengono troncati quando si elimina un database.

— gsiems,