Освобождение дискового пространства после удаления базы данных

12

Я работаю над системой разработки и восстановил базу данных, скажем «foo», которую я использую для целей разработки. Пока я работаю, я только что запустил DROP DATABASE foo. Однако я быстро понял, что съел все пространство на моем диске. Дерьмо.

Освобождает ли VACUUM FULL из другой логической базы данных пространство из базы данных, которую я ранее отбросил (foo)? Я попробовал это из другой логической базы данных, и освободилось свободное место, но я не думаю, что этого было достаточно, чтобы учесть все вызовы CREATE DATABASE / DROP DATABASE, которые я сделал. Возможно, это просто логическая база данных, из которой я работал.

Должен быть способ вернуть это пространство без выполнения инициализации всей базы данных?

РЕДАКТИРОВАТЬ

Поэтому я повторно инициализировал базу данных из резервной копии, примерно выполнив следующие действия . После восстановления я восстановил тонну места на диске! Пока это работает, но любая помощь в том, как очистить удаленную базу данных, все равно будет полезна.

РЕДАКТИРОВАТЬ 2

Поэтому мне удалось собрать больше информации об этой проблеме ... Вот что я привел в качестве примера:

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

Поэтому мне кажется, что новая БД заняла ~ 9,6 ГБ на диске. Однако, после его сброса, освободившееся дисковое пространство только выросло на ~ 4.6G. Итак, примерно 5 ГБ свободного места заставляет меня задуматься о том, что происходит !?

И этот цикл продолжается, когда я воссоздаю, заполняю и снова опускаюсь.

Кто-нибудь имеет какие-либо идеи, что остается после того, как команда "DROP DATABASE" выдается?

postgresql disk-space Jmoney38
источник
Возможно, стоит также отметить, что у меня включено архивирование. Похоже, что место, в которое записываются архивные файлы WAL, довольно велико. Я не следил за этим внимательно. Может быть, я попробую ту же процедуру, что указана выше, и запусту «du» в этом каталоге, чтобы проверить, все ли места освобождены. Я вернусь.
Jmoney38
Я полагаю, что вакуум не помогает тогда?
rogerdpack

Ответы:

6

Попробуйте sudo lsof| grep deletedи проверьте, появляется ли какой-либо процесс PostgreSQL. Эта команда ищет файлы, которые были удалены, но ее файловые дескрипторы все еще открыты любым процессом. Еще один побочный эффект заключается в том, что df -hи du -sh /отличается. Это потому, что duсмотрит на файловую систему и суммирует размер всех файлов, и dfсмотрит на физическое устройство.

У меня только что была проблема с базой данных, которая не освобождала место после a, DROP tableи это было причиной.

Единственное решение, которое я знаю, это перезапустить базу данных. Может быть, вы можете попытаться отправить перезагрузку (SIGHUP).

Charli
источник
2
lsof | grep deletedНаконечник был хороший; добавьте, что вам нужно только определить, какие сеансы postgresql все еще активны, и уничтожить их, чтобы освободить файлы. В моем случае из 500+ активных соединений, почти всех в IDLE или COMMIT, было убито одно, найденное с SELECT * FROM pg_stat_activityпомощью ANALYZE и застрявшее в нем, чтобы освободить удаленные файлы. ! 00 ГБ освобождено.
Алекс Норт-Кис
5

Насколько я понимаю, когда вы удаляете базу данных, ее и ее файлов больше нет.

Если вы не используете табличные пространства, то каждая база данных должна иметь свои данные в своем собственном подкаталоге в каталоге $ PGDATA / base. Используя один из моих серверов для примера (как пользователь 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

Теперь, если мы создадим новую базу данных, в каталоге $ 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

Именно это мы и видим ($ PGDATA / base / 83637 является подкаталогом для новой базы данных).

Удаление этой базы данных также должно удалить файлы данных:

-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

Именно этого мы и ожидали - каталог $ PGDATA / base / 83637 пропал, не должно быть ничего для вакуумирования.

Вы уверены, что больше нет места на диске? Одна из ваших других баз данных? лог-файлы?

То, что вы могли бы попробовать, это:

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

делать различные вещи из базы данных, создавать, удалять и т. д., а затем:

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

чтобы получить представление о том, куда идет дисковое пространство.

gsiems
источник
Я вижу те же результаты, что и вы - т.е. когда я добавляю таблицу, новая база данных появляется в базовой директории, а когда я ее удаляю, она исчезает. Однако этот каталог, по-видимому, не содержит всей разницы в размере (т.е. ~ 9,6 ГБ)
Jmoney38
@ Jmoney38 - Вот почему я рекомендовал делать «du -sh ls» в каталоге $ PGDATA как до, так и после добавления / удаления базы данных, поскольку это должно указывать, какие другие каталоги растут как на дрожжах.
gsiems
@ Jmoney38 - Если бы мне пришлось угадывать, я бы сказал, что разница находится в каталогах $ PGDATA / pg_log и / или $ PGDATA / pg_xlog. Файлы журнала предназначены для кластера и не усекаются при удалении базы данных.
gsiems