Звільнення дискового простору після скидання бази даних

Я працюю в системі розробок, і я відновлюю базу даних, скажімо "foo", яку я використовую для цілей розробників. Коли я працюю через перегини, я щойно запускаю DROP DATABASE foo. Однак я швидко зрозумів, що з'їв весь простір на своєму диску. Лайно.

Чи звільняє ВАКУУМ ПОВНО з іншої логічної бази даних простір із бази даних, яку я раніше скинув (foo)? Я спробував це з іншої логічної бази даних, і вільний простір було повернено, але я не думаю, що цього було достатньо, щоб врахувати всі CREATE DATABASE / DROP DATABASE дзвінки, які я здійснив. Можливо, це просто VACUUM'е логічна база даних, з якої я біг.

Має бути спосіб відновити цей простір, не роблячи загальної бази даних init?

EDIT

Тому я повторно реалізував базу даних із резервної копії, приблизно виконуючи ці кроки . Після відновлення я відновив ТОН місця на диску! Це працює наразі, але будь-яка допомога щодо очищення відпалої бази даних все-таки буде корисною.

EDIT 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"?

Спробуйте sudo lsof| grep deletedперевірити, чи з’являється який-небудь процес PostgreSQL. Ця команда шукає файли, які були видалені, але дескриптори файлів все ще відкриті будь-яким процесом. Іншим побічним ефектом є те , що df -hі du -sh /відрізняється. Це тому, що duдивиться на файлову систему і підсумовує розмір усіх файлів, а також dfдивиться на фізичний пристрій.

У мене щойно виникла проблема з базою даних, яка не звільнила місця після a, DROP tableі це було причиною.

Єдине мені відоме рішення - перезапустити базу даних. Можливо, ви можете спробувати надіслати перезавантаження (SIGHUP).

Я розумію, що коли ви скидаєте базу даних, то вона, а це файли, пропадає.

Якщо ви не використовуєте простори таблиць, то кожна база даних повинна мати свої дані у власному підкаталозі під $ 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

щоб зрозуміти, куди діється простір на диску.