Comments 1
Хорошие новости, спасибо.
Но есть один момент:
Перед base backup мы создаем репликационный слот и при каждом инкрементном бэкапе считываем все накопившиеся в слоте WAL‑файлы.
Это не инкрементальный бэкап, это бэкап журналов транзакций, по аналогии с BACKUP LOG MS SQL Server.
Сам инкрементный бэкап выполняется очень быстро и минимально нагружает систему — его можно делать хоть каждые 10–15 мин.
В этом-то и кроется проблема. На средненагруженном сервере поток WAL генерируется со скоростью 3-5 Гб/мин. То есть за 10-15 минут можно получить от 30 до 75 Гб при нормальной работе СУБД.
В случае пропуска нескольких инкрементальных бэкапов возникает угроза остановки сервера СУБД из-за переполнения тома, на котором расположен pg_wal.
Решая эту проблему, настроив параметр max_slot_wal_keep_size, попадаем в другую: КБ при потери слота вместо инкрементального бэкапа инициирует полный бэкап в момент пиковой нагрузки на сервер.
Каждые 10-15 минут. )
На ненагруженных, но толстых БД также достаточно просто попасть в такую же ситуацию: Массовая операция (copy/pg_restore/vacuum_lo/update) вызовет генерацию WAL файлов, переполнение тома или инвалидацию слота с выполнением полного бэкапа.
Поэтому, для прода такая история мало подходит.
Ну либо обходиться без PITR.
Как мы делали поддержку PostgreSQL