On 06.07.24 04:08, Eric Pruitt wrote:
> On Sat, Jul 06, 2024 at 01:49:05AM +0200, Christian Schulte wrote:
>> A database admin would have monitored the system and just enhanced
>> storage when required. Bad thing for me was, that I could not vaccuum
>> the database, because postgresql copies tables to new files to reclaim
>> disk space afterwards. So the database was unusable for about 12
>> hours, until I could manage to xz a backup and transfer it to another
>> machine. Making postgresql aware of keeping some free disk space, it
>> would need to preserve around 50%, so that vaccuum can always be
>> performed.
>
> This is tangential to the original issue, but I've heard of some
> administrators leaving around large files so they can be removed when
> the disk unexpectedly fills up buying them more time to address the
> underlying issue, and CockroachDB implements this natively:
> <https://www.cockroachlabs.com/docs/stable/cockroach-debug-ballast>.
>
> Eric
Those large files resided in /root/backup for me. Luckily I setup a
cronjob doing some daily backups just to be save. If it would not have
been possible to delete those, freeing some GB, I would have been really
screwed. No way to get out of this situation without increasing storage.
That would have been impossible with my provider as well. For the
record: Never ever let postgresql fill up your storage 100%, when there
is no way for you to increase storage. Just wondering how the postgresql
port is configured. Really should setup quotas automatically when
pkg_adding in a way, just to ensure, that no one ever runs into a
situation, that there is no way out of a disk full situation.
Regards,
--
Christian
No comments:
Post a Comment