У нас есть относительно небольшая база данных Postgres с непрерывным архивированием, настроенным для сжатия каждого сегмента WAL и отправки его на S3. Поскольку это система с небольшим объемом, она срабатывает archive_timeoutкаждые 10 минут или около того и архивирует в основном неиспользуемый сегмент WAL, который раньше очень хорошо сжимался, поскольку в основном это были просто нули.
Однако Postgres перерабатывает свои сегменты WAL, чтобы избежать затрат на выделение новых файлов на каждом коммутаторе WAL, что полезно в ситуации высокой нагрузки, но это означает, что после всплеска более тяжелой, чем обычно, активности наши файлы сегментов WAL теперь заполнены. мусора из предыдущих сегментов и не очень хорошо сжимаются. Мы храним много копий всего этого барахла.
Есть ли способ уменьшить количество места, которое мы используем для хранения нашего архива WAL? Некоторые неоптимальные возможности:
Не позволяйте Postgres каким-либо образом перерабатывать сегменты WAL, поэтому каждый раз он начинается с обнуленного файла. Документы не указывают, что есть возможность сделать это, но я мог пропустить это.
Пусть Postgres обнулит файл сегмента WAL, когда он начинает / заканчивает его использовать. Опять же, документы, похоже, не предполагают, что это возможно.
Внешне обнулите или удалите некоторые файлы сегментов WAL, пока они не используются. Есть ли безопасный способ определить, какие это файлы?
Обнулите неиспользуемую часть сегмента, прежде чем архивировать ее, используя выходные данные,
pg_xlogdumpчтобы определить, где начинается мусор. Возможно, хотя мне это не нравится. По крайней мере, выполнив это в команде архивирования, вы можете быть уверены, что Postgres не собирается повторно использовать файл.Только заархивируйте использованную часть файла сегмента, опять-таки, интерпретировав результат
pg_xlogdumpкаким-либо образом, а затем добавьте его в нули во время восстановления. Также возможно звучит, хотя мне это не очень нравится.