Как уменьшить Wal в postgresql?

Question

[Luan]

Имеется сервак с базами 1с. Места не так много, 80 гигов диск и 10 под бекап для wal журналов, крутятся не большие 2 базы. С начала все было нормально. Потом Со временем начал расти каталог pg_wal. Но тут разобрались, копился лог, который не пернесся на диск под бекап. Выключили и включили archive_mode и журнал стал переноситься на резервный диск. Но логов накопилось на 40 гигов а у нас только 10, т.е. еще остались не перенесенные.
Диска теперь не хватает и встал вопрос: можно ли удалить, то что перенесено в бекап и чтоб разгрузить журнал, чтоб он не копился?
И можно как то уменьшить количество файлов и для бекапа и для баз? Не уж то postgres нужно так много журналов хранить?

Answer 1

[Melkij]

Не уж то postgres нужно так много журналов хранить?

А то что перенесено куда-либо через archive_command самому postgresql вообще не нужно и база об этих файлах никак не беспокоится. Это нужно тому, кто это настраивает. И в ведении как раз этого человека и будет вопрос "сколько валов нужно хранить".
Если тот кто настраивал archive_command тоже не беспокоится об архиве - то архив будет бесконечен (16 EiB, это не шутка).

Архив wal нужен для pitr (или file-shipment replication). Для pitr нужны абсолютно все wal без исключения с момента снятия basebackup до требуемой точки восстановления (при том точка восстановления не может быть ранее времени окончания взятого за основу basebackup). В каких временных рамках вам нужен pitr - выбираете соответственно при определении собственной же политики требований к бекапам.
(10гб места под бекапы звучит откровенно поразительно, если у вас настолько маленькая база - то зачем вам 80гб основной диск? И 8 было бы много)

Comments

[Luan]

Т.е. логи на резервном диске можно спокойно тереть, если репликации нет?
А диски настраивались с тем учетом что не понятно сколько займут базы и иногда одну выливаем для баловства бухгалтерии как третью. А 10 ГБ брали для wal, т.к. теоретически они не должны много места были занимать

[Melkij]

А 10 ГБ брали для wal, т.к. теоретически они не должны много места были занимать

Почему? Как раз должны.
Вот если вы хотели вынести на отдельный диск pg_wal (pg_xlog в eol релизах), а не бекап настраивать - то это никак не связано с archive_command и archive_mode.

Если вы не настраиваете pitr бекапы - то выключите archive_mode либо замените archive_command на /bin/true. После этого переместите куда-нибудь директорию, куда писали wal, через пару дней проверив что не сломали базу - удалите.

[Luan]

вопрос нубской.... а что такое pitr бекапы?.. Настройка планировалась так, что wal был бекап на всякий случай, но не хранить их все до скончания веков

[Melkij]

https://www.postgresql.org/docs/current/continuous...

Если вы сделали только архивацию wal и не сделали снятие basebackup - у вас по-прежнему нет бекапов. А чтобы не собирать этот конструктор (а это именно конструктор) - используйте готовые решения управления бекапами: pgbackrest, wal-g, barman из популярных.

[Luan]

А нет вариантов без отдельной машины? Или я так понимаю для оперативного восстановления не обойтись без этих инструментов? А если без них то проще восстанавливаться с бекапов?

[Melkij]

А при чём тут отдельная машина?
Впрочем, хранить бекап на том же самом диске, что и всё остальное - по определению к приключениям.
При том, уметь восстанавливаться из бекапа быстро - это отдельное требование к организации бекапов и disaster recovery plan в целом, несовместимое с "как проще".

Answer 2

[Prog]

Не понятно, зачем вам WAL под 1С "с небольшими базами"?
pg_dump сделает вам за секунды...