Каждый кортеж кучи (heap tuple) живёт внутри страницы размером строго 8 КБ. Всё остальное построено поверх этого жёсткого ограничения: MVCC, HOT update и индексы, указывающие на (страница, указатель_строки). И тем не менее, это всё ещё работает:
CREATE TABLE docs (id int PRIMARY KEY, body jsonb);
INSERT INTO docs VALUES (1, (SELECT jsonb_agg(g) FROM generate_series(1, 100000) g));
Это значение body где-то за полмегабайта. Страница кучи по-прежнему имеет размер 8 КБ. Оба утверждения истинны одновременно, и механизм, который позволяет им сосуществовать, называется TOAST: The Oversized-Attribute Storage Technique (техника хранения чрезмерно больших атрибутов).
Прозрачное шифрование данных (Transparent Data Encryption, TDE) стало обязательным требованием для многих предприятий, хранящих конфиденциальные данные, будь то персональные или финансовые. Однако этот эффект обычно означает, что резервные копии бесполезны без отдельного хранимого ключа шифрования, а запуск самого сервера может не выполняться в полностью автоматизированном режиме (в зависимости от того, как настроено управление ключами). Взаимодействие между этими компонентами не всегда интуитивно понятно. Данная статья призвана внести ясность.
Этот документ по планированию содержит базовое введение или обзор как высокой доступности, так и прозрачного шифрования данных, а затем даёт обзор операционных проблем, связанных с совместным использованием этих двух технологий. Рекомендации касаются как инфраструктуры, которую следует учитывать, так и процессов, которые необходимо документировать, тестировать и отрабатывать.
Мы открываем кластер параметров на букву B параметром, само существование которого является признанием сложных отношений. У PostgreSQL сложные отношения с кэшем страниц Linux (page cache), и backend_flush_after — один из четырёх GUC, которые существуют для управления этими отношениями. Остальные три — bgwriter_flush_after, checkpoint_flush_after и wal_writer_flush_after — получат свои собственные статьи в своё время. Они используют общий механизм и имеют общую мотивацию, и эту мотивацию стоит понять, прежде чем мы погрузимся в конкретный параметр.
Последняя запись в кластере параметров автовакуума и самая новая. PostgreSQL 18 представил autovacuum_worker_slots для решения давней операционной проблемы: изменение autovacuum_max_workers ранее требовало перезапуска сервера, что делало невозможным реагирование на меняющуюся рабочую нагрузку вакуума без окна обслуживания. PG 18 исправляет это, разделяя параметр на две части.
С тех пор как в PostgreSQL существует логическая репликация, правило было таковым: если вы когда-нибудь захотите её использовать, установите wal_level = logical при запуске сервера и живите с объёмом WAL вечно. Стоимость не была катастрофической, но она была постоянной. Установите один раз — платите всегда, включая 364 дня в году, когда вы не использовали ни одного логического слота.
PostgreSQL 19 меняет это. Параметр всё ещё существует. Он просто больше не совсем то, что вы установили.
autovacuum_work_mem задаёт максимальный объём памяти, который каждый рабочий процесс автовакуума может использовать для отслеживания идентификаторов мёртвых кортежей (TID — tuple identifier) во время вакуума. Значение по умолчанию: -1, что означает «унаследовать от maintenance_work_mem». Контекст параметра — sighup. Этот параметр существует для того, чтобы потребление памяти автовакуумом можно было настраивать независимо от памяти, используемой ручным VACUUM, CREATE INDEX, REINDEX и другими разовыми операциями обслуживания.
За последний год я работал в нескольких контекстах, управляя большими объёмами данных, хранящихся в формате JSONB в PostgreSQL. Сценарий обычен: пользователи ценят гибкость документо-ориентированной модели хранения, избегая необходимости предопределять схемы или постоянно мигрировать структуры таблиц по мере изменения их требований к данным. JSONB-документы могут быть глубоко вложенными с многочисленными необязательными полями и масштабироваться до сотен килобайт на запись без проблем. Однако, когда приходит время запрашивать эти документы — фильтровать по идентификатору пользователя, типу события, временным меткам или вложенным свойствам действий — запросы могут стать медленными и/или неудобными для работы.
Проблема, которую я хочу решить: «Как сделать поиск по JSONB-данным более эффективным, не разбивая наши документы и не вставляя их в столбцы реляционной базы данных?» В Postgres доступно несколько подходов, каждый со своими компромиссами. Я надеюсь пролить свет на эти подходы в этой статье.
Классическая пара параметров запуска вакуума, наконец. Последние несколько статей мы потратили на параметры, которые изменяют, ограничивают или дополняют формулу запуска, управляемую этими двумя; теперь мы добрались до оригиналов.
Когда количество устаревших кортежей (обновлённых или удалённых строк) с момента последнего вакуума превышает это значение, автовакуум планирует выполнение VACUUM для таблицы. В PostgreSQL 18 и новее результат также ограничивается параметром autovacuum_vacuum_max_threshold. Значения по умолчанию: autovacuum_vacuum_threshold = 50, autovacuum_vacuum_scale_factor = 0.2. Оба параметра имеют контекст sighup, и для каждого существуют переопределения на уровне таблицы через параметры хранения.
Новинка в PostgreSQL 18. Этот параметр является первоклассным исправлением проблемы, с которой всё сообщество боролось около пятнадцати лет: на очень больших таблицах стандартная формула запуска вакуума ждёт абсурдно долго, прежде чем что-либо сделать.
При значениях по умолчанию — autovacuum_vacuum_threshold = 50 и autovacuum_vacuum_scale_factor = 0.2 — таблица на 100 миллионов строк ждёт 20 миллионов мёртвых кортежей, прежде чем запустится вакуум. Таблица на миллиард строк ждёт 200 миллионов. К моменту, когда вакуум действительно запускается, у вас уже огромное количество раздувания (bloat), сам вакуум занимает часы, а следующий запускается из такого же плохого состояния.
Классическим обходным решением (workaround) была покадровая настройка autovacuum_vacuum_scale_factor для каждой таблицы до значений вроде 0.02 или 0.005, которую мы обсудим, когда доберёмся до этих параметров в следующей статье. Это работает, но требует предварительного выявления каждой большой таблицы и назначения ей индивидуальных параметров хранения (storage parameters). Легко забыть, легко упустить, когда маленькая таблица вырастает в большую.
Эти два параметра образуют третью согласованную пару в комплекте автовакуума, после пары для ANALYZE и пары для обычного вакуума (последняя будет рассмотрена следующей). Они управляют тем, когда автовакуум запускает VACUUM для таблицы на основе количества вставок (INSERT) с момента последнего вакуума — не обновлений, не удалений, только вставок. Они были добавлены в PostgreSQL 13 и существуют для решения конкретной проблемы.
Первичный сервер PostgreSQL теряет питание в 2 часа ночи. Запись возобновляется менее чем за тридцать секунд. Дежурный инженер читает оповещение утром, видит, что кластер восстановился самостоятельно, и возвращается к кофе. Это тот результат, который должна обеспечивать высокая доступность PostgreSQL.
Работающий кластер Patroni сам по себе доводит вас лишь до половины пути. Выборы лидера работают. Резервный сервер (standby) повышается до первичного. Состояние кластера в etcd остаётся согласованным. Затем приложение продолжает пытаться подключиться к IP-адресу, который теперь указывает на неправильный узел, старый первичный сервер требует ручного повторного присоединения (rejoin), и дежурный инженер оказывается на конференц-связи, а не в постели.
Я видел этот шаблон достаточно часто, чтобы назвать его стандартным. Кластер делает свою работу. Приложение ждёт человека. Достаётся инструкция (runbook). Время восстановления (RTO) превышает соглашение об уровне обслуживания (SLA). Все соглашаются после этого, что «нам следует серьёзнее отнестись к высокой доступности».
Эти три параметра вместе задают темп работы автовакуума: как часто он запускается, как интенсивно работает во время выполнения и как долго приостанавливается, чтобы не монополизировать ваш ввод-вывод. Как и пара параметров autovacuum_analyze_*, их лучше всего понимать как единое целое.
В предыдущей статье мы видели, как каждое обновление (UPDATE) оставляет после себя мёртвый кортеж. То же поведение «копирования при записи» (copy-on-write) проявляется с операционной точки зрения в статье «DELETEs are difficult». Это плата за MVCC, и если мы имеем дело только с кучей (heap) это терпимо. Проблема в индексах.
Каждое обновление в PostgreSQL потенциально записывает данные во все индексы таблицы, даже если индексированные столбцы не изменились. Пять индексов, один обновлённый столбец? Пять лишних операций записи в индексы, пять новых записей для вакуума, в пять раз больше трафика WAL. При тысячах обновлений в секунду это становится доминирующей стоимостью работы с таблицей, в которой много обновлений.
Heap-Only Tuple (HOT) updates — это механизм PostgreSQL, позволяющий обойти эту проблему. На мой взгляд, это самое изящное оптимизационное решение в движке хранения. Давайте проследим, как именно оно работает.
Этот параметр является multixact-эквивалентом autovacuum_freeze_max_age. Механизм параллелен; защищаемый объект — не пространство идентификаторов транзакций (XID), а пространство идентификаторов MultiXact, о котором большинство пользователей PostgreSQL никогда не задумывались, а остальные узнали о нём во время аварии. Итак, перед рассмотрением параметра — краткий обзор multixact.
