Всё о GUC по порядку: archive_cleanup_command
Автор: Christophe Pettus, All your GUCs in a Row: archive_cleanup_command
Алфавитный порядок выдал нам первую «жертву». archive_cleanup_command — это параметр резервного сервера (standby-server knob), который существует исключительно для того, чтобы прибираться после archive_command. Однако алфавит настаивает на том, чтобы отложить рассмотрение archive_command до следующей статьи. Поэтому мы опишем, как прибирать вечеринку, которую ещё не устраивали.
Кратчайшая предыстория: Первичный сервер PostgreSQL (primary) может архивировать свои сегменты WAL в некоторое место — каталог, корзину S3, общий ресурс NFS — выполняя команду оболочки для каждого заполненного сегмента. Резервные серверы (standbys) читают из этого места, чтобы догонять изменения, а инструменты резервного копирования читают из него для обеспечения восстановления на момент времени (point-in-time recovery, PITR). Файлы накапливаются. Кто-то должен их удалять.
archive_cleanup_command — это один из вариантов для этого «кого-то». Он выполняется на резервном сервере в каждой точке перезапуска (restartpoint, примерно эквивалент контрольной точки на первичном сервере) и удаляет сегменты WAL, которые резервному серверу больше не нужны для восстановления. GUC принимает команду оболочки, обычно вызывающую pg_archivecleanup:
archive_cleanup_command = 'pg_archivecleanup /mnt/archive %r'Заполнитель %r раскрывается в имя самого старого файла WAL, который всё ещё нужен резервному серверу; pg_archivecleanup удаляет всё, что строго старше. Контекст параметра — sighup, значение по умолчанию — пустая строка.
Две вещи, которые стоит знать
Этот параметр опасен именно в той конфигурации, которая чаще всего встречается. Инструмент безопасен, только если архив, согласно документации, является «временной промежуточной областью для этого конкретного резервного сервера». Если ваш архив служит также источником для восстановления на момент времени (PITR) с помощью инструментов резервного копирования или если несколько резервных серверов читают из него, то запуск archive_cleanup_command на одном резервном сервере благополучно удалит файлы, которые всё ещё нужны другим. Вы узнаете об этом во время восстановления, а это самое неподходящее время.
Если вы используете настоящий инструмент резервного копирования, вам этот параметр не нужен вообще. pgBackRest, Barman и WAL-G самостоятельно управляют удержанием архивов на основе политик резервного копирования и состояния реплик, и они делают это корректно для нескольких потребителей. Установка archive_cleanup_command поверх этого в лучшем случае избыточна, а в худшем — активна вредна (способ удалить файлы, которые ваш инструмент резервного копирования планировал сохранить).
Историческое примечание: Этот параметр существовал в файле recovery.conf до версии PostgreSQL 12, когда этот файл был объединён с postgresql.conf. Если вы читаете древнюю операционную документацию, он будет спрятан именно там.
Рекомендация: Оставьте этот параметр пустым. Используйте инструмент резервного копирования, который управляет удержанием архива, и позвольте ему делать свою работу. Единственный случай, когда имеет смысл установить archive_cleanup_command, — это игрушечная настройка высокой доступности (HA) с одним резервным сервером и без значимых резервных копий. То есть не в производственной среде.
(Это #5 в серии о каждом GUC PostgreSQL по состоянию на версию 18, в алфавитном порядке.)
Trackbacks
No Trackbacks
The author does not allow comments to this entry
Comments
Display comments as Linear | Threaded