Librar espacio en disco después de la base de datos caída

Question

Estoy trabajando en un sistema de desarrollo, y he estado restaurando una base de datos, diga "foo", que estoy usando para fines de desarrollo. Mientras estoy trabajando a través de los problemas, acabo de ejecutar la base de datos Drop Foo. Sin embargo, rápidamente me di cuenta de que comía todo el espacio en mi disco. Tonterías.

¿Vacuum está lleno, de una base de datos lógica diferente, libera espacio de la base de datos que eliminé anteriormente (FOO)? Intenté esto de una base de datos lógica diferente, y el espacio libre fue recuperado, pero no creo que fuera suficiente para tener en cuenta todas las llamadas de base de datos Crear base de datos/Drop que hice. Podría haber aspirado la base de datos lógica desde la que corrí.

¿Debe haber una manera de reclamar ese espacio sin hacer un init de base de datos total?

EDITAR

Así que reinicialicé la base de datos desde una copia de seguridad, más o menos estos pasos. ¡Después de la restauración, reclamé una tonelada de espacio en el disco! Esto funciona por ahora, pero cualquier ayuda sobre cómo limpiar una base de datos caída aún sería útil.

Edición 2

Así que he logrado recopilar más información sobre este problema ... esto es lo que se me ocurre como ejemplo:

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

Entonces me parece que el nuevo DB tomó ~ 9.6 GB en el disco. Sin embargo, después de dejarlo caer, el espacio de disco recuperado solo creció en ~ 4.6 g. Entonces, ¿hay aproximadamente 5 GB de espacio que me hace preguntarme qué está pasando?

Y continúa este ciclo cuando recreo, pueblo y dejo de nuevo.

¿Alguien tiene alguna idea de lo que se demora después de que se emite un comando de "Drop Base de datos"?

Answer 1

Probar sudo lsof| grep deleted y verifique si aparece algún proceso PostgreSQL. Este comando busca archivos que se han eliminado, pero sus descriptores de archivos aún están abiertos por cualquier proceso. Otro efecto secundario es que df -h y du -sh / difiere. Esto es porque du mira el sistema de archivos y resume el tamaño de todos los archivos, y df Mira el dispositivo físico.

Acabo de tener un problema con una base de datos que no liberó ningún espacio después de un DROP table Y esa fue la causa.

La única solución que sé es reiniciar la base de datos. Tal vez pueda intentar enviar una recarga (suspiro).

Answer 2

Tengo entendido que cuando sueltas una base de datos, y sus archivos se han ido.

A menos que esté utilizando espacios de tabla, cada base de datos debe tener sus datos en su propio subdirectorio en $ PGDATA/base. Usando uno de mis servidores para un ejemplo (como usuario de 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

Ahora, si creamos una nueva base de datos, entonces debería haber un subdirectorio más bajo $ 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

Que es lo que vemos ($ PGDATA/BASE/83637 es el subdirectorio para la nueva base de datos).

Dejar caer esa base de datos también debe eliminar los archivos de datos:

-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

Que es lo que esperaríamos: el directorio $ PGDATA/BASE/83637 se ha ido, no debería haber nada para aspirarse.

¿Estás seguro de que no hay nada más comiendo tu espacio en disco? Una de sus otras bases de datos? ¿archivos de registro?

Algo que podrías probar sería:

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

Haga sus diversas cosas de base de datos, cree, caiga, etc. y luego:

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

Para tener una idea de dónde va el espacio en el disco.