Этот параметр является multixact-эквивалентом autovacuum_freeze_max_age. Механизм параллелен; защищаемый объект — не пространство идентификаторов транзакций (XID), а пространство идентификаторов MultiXact, о котором большинство пользователей PostgreSQL никогда не задумывались, а остальные узнали о нём во время аварии. Итак, перед рассмотрением параметра — краткий обзор multixact.
За годы обучения, консультирования и поддержки пользователей PostgreSQL я разработал несколько запросов для мониторинга автовакуума. Мониторинг автовакуума — не новое требование, поэтому существует уже много готовых запросов для мониторинга. Однако не все эти запросы полезны. Поэтому я подумал, что будет хорошей идеей написать статью о моей собственной коллекции — как для себя в качестве справочника, так и в качестве услуги для администраторов PostgreSQL по всему миру.
autovacuum_max_workers задаёт максимальное количество фоновых процессов автовакуума (autovacuum worker processes), которые могут выполняться одновременно. Значение по умолчанию — 3. Контекст параметра — postmaster, поэтому его изменение требует перезапуска сервера. Процесс-планировщик (launcher process) является отдельным и не учитывается в этом числе.
Это тот параметр, который кто-то увеличивает с 3 до 10, решив, что автовакуум работает слишком медленно, после чего обнаруживает, что вакуум, как ни странно, на самом деле не стал быстрее. У этого есть причина, и это самое важное, что нужно понять об этом GUC.
Архиватор запускается только после завершения сегмента WAL. В загруженной базе данных это происходит постоянно, а в малоактивной — может не происходить часами или даже днями. Параметр archive_timeout предназначен для того, чтобы избежать ситуации вроде «наша база данных весь день принимала операции записи, но ни одна из них ещё не попала в архив».
archive_mode — это главный выключатель архивации WAL. После трёх предыдущих статей — archive_cleanup_command, archive_command, archive_library — мы наконец добрались до параметра, который решает, будет ли вообще работать вся эта механика.
Прежде чем погрузиться в этот параметр, небольшое исправление (errata) к предыдущей статье. Я сказал, что инструменты резервного копирования «могут зарегистрироваться как archive_library и полностью обойти archive_command» начиная с PostgreSQL 15+. Именно для этого и была предназначена эта функциональность. Однако это не то, что на самом деле появилось в экосистеме. Подробнее об этом чуть позже.
archive_library, добавленный в PostgreSQL 15, позволяет настроить загружаемый C-модуль для обработки архивации WAL вместо команды оболочки (shell command). Процесс архиватора (archiver process) вызывает колбэки модуля напрямую, внутри своего процесса, один раз на каждый сегмент. Никакого fork(). Никакой оболочки. Никакого cp. PostgreSQL передаёт завершённые WAL-файлы модулю и не будет переиспользовать их, пока модуль не подтвердит успех, — контракт тот же, что и у archive_command, но без накладных расходов и режимов отказа, присущих сценариям оболочки.
Алфавитный порядок выдал нам первую «жертву». archive_cleanup_command — это параметр резервного сервера (standby-server knob), который существует исключительно для того, чтобы прибираться после archive_command. Однако алфавит настаивает на том, чтобы отложить рассмотрение archive_command до следующей статьи. Поэтому мы опишем, как прибирать вечеринку, которую ещё не устраивали.
Кратчайшая предыстория: Первичный сервер PostgreSQL (primary) может архивировать свои сегменты WAL в некоторое место — каталог, корзину S3, общий ресурс NFS — выполняя команду оболочки для каждого заполненного сегмента. Резервные серверы (standbys) читают из этого места, чтобы догонять изменения, а инструменты резервного копирования читают из него для обеспечения восстановления на момент времени (point-in-time recovery, PITR). Файлы накапливаются. Кто-то должен их удалять.
Для хорошего бэкенд-разработчика существует определенное стремление к оптимизации запросов (скорости и памяти). Одним из полезных инструментов оптимизации баз данных являются подзапросы SQL.
Подзапрос - это запрос внутри другого запроса. Он позволяет вам вытащить связанные данные или результаты вычислений без написания нескольких запросов или тяжелых соединений. Он также позволяет динамически выполнять вычисления и агрегировать данные.
Большинство GUC в этой серии будут операционно не важны для большинства читателей. Этот — не такой. application_name — это самое дешёвое средство наблюдаемости (observability infrastructure), которое поставляет PostgreSQL, и поразительное количество производственных баз данных работают с неустановленным значением или со значением, застрявшим на значении по умолчанию клиентской библиотеки (psql, PostgreSQL JDBC Driver или, что я люблю больше всего, — пустая строка).
Это метка уровня сеанса (per-session label). Значение по умолчанию — пустая строка, контекст — user, поэтому любая роль может его установить. Установите его через SET application_name = 'order-service';, через параметр подключения application_name или через переменную окружения PGAPPNAME, которую libpq учитывает автоматически. Максимальная длина — NAMEDATALEN - 1 — 63 байта в стандартной сборке, а непечатаемые символы заменяются на ?.
Вот GUC, который поставляется с предупреждающей этикеткой. Документация, обычно сдержанная до степени пародии, прямо заявляет, что неправильная установка этого параметра может привести к «необратимой потере данных или серьёзному повреждению системы базы данных». Когда документация PostgreSQL так повышает голос — прислушайтесь.
Давайте начнем с базы данных Stack Overflow (будет работать версия любого размера), удалим все индексы на таблице Users и выполним DELETE:
SET STATISTICS IO ON;
GO
BEGIN TRAN
DELETE dbo.Users WHERE DisplayName = N'Brent Ozar';
Я использую SET STATISTICS IO ON, о чем мы говорили в статье "Как думать подобно серверу SQL Server" для иллюстрации количества прочитанных данных, и я делаю это в транзакции, которую я могу периодически откатывать, каждый раз демонстрируя полученные эффекты. Вот действительный план выполнения:
allow_in_place_tablespaces существует для того, чтобы набор тестов PostgreSQL мог тестировать репликацию. Вот и всё. Если вы читаете это как администратор (оператор), вы никогда к нему не прикоснётесь. Но раз он есть в алфавите, вот мы здесь.
