Всем привет. На одном проекте случилась такая история. Во время выполнения операции vacuum full analyze был выполнен снапшот виртуальной машины. После чего размер базы данных вырос с 1.4 ТБ до 2 ТБ.
Я на сколько мне позволяют знания проанализировал ситуацию и выяснил что:
1. Это не временные файлы
2. Размер пользовательских таблиц с индексами составляет 1419 ГБ
3. Если сделать бэкап и развернуть на другом сервере, то вес становиться 1.4 ТБ (тот который должен быть)
4. vacuum full analyze, reindex и vacuumlo не исправляют ситуацию.
- место занимает именно PGDATA/base/ ? PGDATA/pg_wal нормального размера?
- "Если сделать бэкап и развернуть на другом сервере" - какой именно бекап имеется в виду?
- ошибки в логах базы при снапшоте?
- как именно снапшот делался? (LXC на btrfs/zfs/etc тоже можно назвать виртуалкой, а вот грабли будут свои)
PS: vacuum full на 1,4тб базе это довольно неожиданная идея
Melkij, Приветствую тебя гуру PG )
1. Все верно, все место занимает PGDATA/base/
2. pg_dump -F c -b -v
3. Да были ошибки в логах о недоступности для записи таблиц.
4. Стандартный снапшот со стороны гипервизора proxmox.
Исторически так сложилось что данная операция vacuumfull выполняется каждые выходные )
3. Да были ошибки в логах о недоступности для записи таблиц.
можно пару цитат?
То есть основная гипотеза, vacuum full писал что-то большое, но не смог удалить либо старые либо новые датафайлы.
База при этом не уходила ли вообще в crash recovery по какой-то причине? Там есть варианты при которых остаются осиротевшие датафайлы https://www.cybertec-postgresql.com/en/orphaned-fi...
Melkij в комментарии хорошую мини статью скинул
По моему это 100% мой случай, у меня можно сказать как раз был сбой и вероятно появились осиротевшие файлы.
Там как раз описано что самый простой и безопасный способ это восстановление из pg_dump. Как я выше и писал с бэкапа у меня при восстановлении размер нормализуется.
