Membebaskan ruang disk setelah menjatuhkan basis data


12

Saya sedang mengerjakan sistem dev, dan saya telah memulihkan ke database, katakan "foo", yang saya gunakan untuk tujuan dev. Saat saya sedang mengerjakan masalah, saya baru saja menjalankan DROP DATABASE foo. Namun, saya segera menyadari bahwa saya menghabiskan semua ruang pada disk saya. Sampah.

Apakah VACUUM FULL, dari database logis yang berbeda, membebaskan ruang dari database yang sebelumnya saya jatuhkan (foo)? Saya mencoba ini dari database logis yang berbeda, dan ruang kosong telah direklamasi, tetapi saya tidak berpikir itu cukup untuk menjelaskan semua panggilan CREATE DATABASE / DROP DATABASE yang saya buat. Mungkin baru saja VACUUM'ed database logis saya lari dari.

Harus ada cara untuk mendapatkan kembali ruang itu tanpa melakukan init database total?

EDIT

Jadi saya menginisialisasi ulang database dari cadangan, kira-kira mengikuti langkah-langkah ini . Setelah pemulihan, saya telah mengambil kembali TON ruang pada disk! Ini berfungsi untuk saat ini, tetapi bantuan apa pun tentang cara membersihkan database yang dijatuhkan akan tetap berguna.

EDIT 2

Jadi saya berhasil mengumpulkan beberapa informasi lebih lanjut tentang masalah ini ... Inilah yang saya berikan sebagai contoh:

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

Jadi nampak bagi saya bahwa DB baru mengambil ~ 9,6 GB pada disk. Namun, setelah menjatuhkannya, ruang disk yang direklamasi hanya tumbuh ~ 4.6G. Jadi, ada sekitar 5 GB ruang yang membuat saya bertanya-tanya apa yang terjadi !?

Dan ini melanjutkan siklus ini ketika saya membuat ulang, mengisi, dan menjatuhkan lagi.

Adakah yang tahu apa yang tersisa setelah perintah "DROP DATABASE" dikeluarkan?


Mungkin perlu juga dicatat bahwa pengarsipan saya AKTIF. Tampaknya lokasi di mana file arsip WAL sedang ditulis agak besar. Saya belum memonitornya dengan cermat. Mungkin saya akan mencoba prosedur yang sama yang tercantum di atas dan menjalankan "du" pada direktori itu untuk melihat apakah semua ruang direklamasi. Saya akan melaporkan kembali.
Jmoney38

Saya berasumsi vakum tidak membantu?
rogerdpack

Jawaban:


6

Coba sudo lsof| grep deleteddan periksa apakah ada proses PostgreSQL yang muncul. Perintah ini mencari file yang telah dihapus tetapi deskriptor file masih terbuka oleh proses apa pun. Efek samping lain adalah itu df -hdan du -sh /berbeda. Ini karena dumelihat pada sistem file dan meringkas ukuran semua file, dan dfmelihat pada perangkat fisik.

Saya baru saja mengalami masalah dengan database yang tidak membebaskan ruang apa pun setelah DROP tabledan itulah penyebabnya.

Satu-satunya solusi yang saya tahu adalah me-restart database. Mungkin Anda dapat mencoba mengirim ulang (SIGHUP).


2
The lsof | grep deletedtip adalah satu yang baik; untuk itu, tambahkan bahwa Anda hanya perlu menentukan sesi postgresql mana yang masih aktif, dan bunuh mereka, untuk melepaskan file. Dalam kasus saya, dari 500+ koneksi aktif, hampir semuanya di IDLE atau COMMIT, membunuh satu, ditemukan dengan SELECT * FROM pg_stat_activitydan terjebak dalam ANALYZE, cukup untuk membebaskan file yang dihapus. ! 00 GB dibebaskan.
Alex North-Keys

5

Pemahaman saya adalah bahwa ketika Anda menjatuhkan database maka itu, dan itu file, hilang.

Kecuali Anda menggunakan tablespace maka setiap database harus memiliki data di subdirektori sendiri di bawah $ PGDATA / base. Menggunakan salah satu server saya sebagai contoh (sebagai pengguna 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

Sekarang, jika kita membuat database baru maka harus ada satu subdirektori lagi di bawah $ 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

Itulah yang kami lihat ($ PGDATA / base / 83637 menjadi subdirektori untuk database baru).

Menjatuhkan basis data itu juga harus menghapus file data:

-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

Itulah yang kita harapkan - direktori $ PGDATA / base / 83637 hilang, seharusnya tidak ada yang vakum.

Apakah Anda yakin tidak ada sesuatu yang memakan ruang disk Anda? Salah satu database Anda yang lain? file log?

Sesuatu yang bisa Anda coba adalah:

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

lakukan berbagai hal basis data Anda, buat, jatuhkan, dll. lalu:

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

untuk mendapatkan ide di mana ruang disk akan pergi.


Saya memang melihat hasil yang sama seperti yang Anda lakukan - yaitu Ketika saya menambahkan tabel, DB baru muncul di direktori dasar, dan ketika saya menghapusnya, itu hilang. Namun, direktori itu tampaknya tidak mencakup seluruh perbedaan ukuran (mis. ~ 9.6GB)
Jmoney38

@ Jmoney38 - Itulah sebabnya saya merekomendasikan melakukan "du -sh ls" pada direktori $ PGDATA baik sebelum dan sesudah melakukan database add / drop seperti yang seharusnya menandai direktori lain mana yang tumbuh pesat.
gsiems

@ Jmoney38 - Jika saya harus menebak saya akan mengatakan bahwa perbedaannya dapat ditemukan di direktori $ PGDATA / pg_log dan / atau $ PGDATA / pg_xlog. File log untuk cluster dan tidak terpotong saat Anda menjatuhkan database.
gsiems
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.