Логическая репликация PostgreSQL 15–18: что нового и почему это важно

Если вы администрируете PostgreSQL уже не первый год, то наверняка помните отношение к логической репликации образца версий 10–14: «работает, но лучше не трогать без крайней нужды». Слишком много граблей — от внезапных конфликтов до полной остановки подписки после любого сбоя. С выходом PostgreSQL 15 всё изменилось. Механизм перестал быть просто альтернативой физической репликации для узких задач и превратился в полноценный фундамент для миграций, масштабирования и сложной интеграции.

Примерно в то же время начали появляться новые сценарии: SaaS-платформам нужна изоляция клиентских данных, аналитическим контурам — выборочная синхронизация без тяжёлых ETL, а распределённым командам — репликация между разными мажорными версиями без простоя. Разработчики PG ответили на эти запросы лавиной улучшений. Давайте разберём, что именно появилось в версиях с 15-й по 18-ю и как эти изменения повлияли на реальную эксплуатацию.

PostgreSQL 15: фильтрация, безопасность и управление ошибками

Именно 15-й релиз заложил основу для промышленного применения логической репликации. Разработчики добавили гранулярный контроль над тем, что именно передаётся подписчику, пересмотрели модель прав и дали инструменты для автоматического и ручного выхода из конфликтных ситуаций.

Публикация схем и отдельных столбцов

Раньше вы могли включить в публикацию только целые таблицы. В 15-й версии ситуация изменилась радикально:

Публикация всех таблиц в схеме. Одной командой можно добавить в публикацию целую схему, и любые новые таблицы, созданные в ней позже, автоматически попадут в репликацию. Для микросервисов и мультитенантных приложений это резко снижает объём рутинного администрирования.
Публикация выбранных столбцов. Допустим, в таблице users есть поле password_hash, которое вы категорически не хотите передавать во внешние системы. Теперь можно явно перечислить только те столбцы, которые должны реплицироваться, и остальные останутся исключительно на мастере . Это не просто удобно, это критически важно для compliance и защиты персональных данных.

Фильтрация строк: реплицируем только нужное

Ещё один мощный слой селективности — фильтрация строк на уровне публикации. При создании публикации вы задаёте условие WHERE, и подписчик получает только те записи, которые этому условию удовлетворяют .

На практике это означает, что мастер может содержать данные всех клиентов SaaS-решения, а подписчик конкретного клиента — только строки с его tenant_id. Без дополнительных скриптов, без хрупких триггерных схем. Условие фильтрации вычисляется на мастере до отправки WAL, что снижает трафик и нагрузку на подписчика.

Подготовленные транзакции и two_phase commit

В классической логической репликации декорирование WAL и передача изменений происходит только после фиксации транзакции. Это создаёт проблемы для долгих пакетных обновлений: пока транзакция не завершена, на подписчике ничего не появляется, а по её завершении происходит резкий всплеск.

В PG 15 в подписке появился флаг two_phase = true. Если он включён, декодирование начинается уже на этапе PREPARE TRANSACTION. Это даёт несколько преимуществ:

Лаг репликации снижается, поскольку данные передаются постепенно.
Появляется окно для обнаружения конфликтов до коммита: если на подписчике блокировка или нарушение уникальности, можно откатить операцию на этапе подготовки, не доводя до аварии .

Для систем, где большие транзакции — норма, этот режим стал настоящим спасением.

Управление конфликтами: SKIP LSN и disable_on_error

Логическая репликация работает асинхронно, и конфликты неизбежны. Классический пример — нарушение уникальности, когда строка уже существует на подписчике. Раньше администратору приходилось либо вручную править данные на подписчике, либо пересоздавать подписку целиком.

В PG 15 появились два дополняющих друг друга механизма:

Точечный пропуск конфликтной записи: ALTER SUBSCRIPTION ... SKIP (lsn = ...). Вы указываете конкретный LSN, вызвавший ошибку, и подписка продолжает работу со следующей транзакции . Это быстро, обратимо и не требует переинициализации.
Автоматическое отключение при ошибке: параметр disable_on_error. Если установить его в true, подписка при возникновении ошибки не будет бесконечно пытаться применить проблемный сегмент, а сразу отключится, оповестив администратора через системные представления . Это предотвращает «залипание» слота репликации и бесконтрольное раздувание WAL на мастере. Дальше вы уже вручную разбираетесь с конфликтом и включаете подписку обратно.

Дополнительно появилось представление pg_stat_subscription_stats, где видны счётчики ошибок применения и данные по фазам начального копирования таблиц . Мониторинг перестал быть гаданием на кофейной гуще.

Безопасность: владелец подписки и Row Level Security

Одно из самых недооценённых изменений, которое на самом деле закрывает дыру в безопасности. Раньше apply-процесс работал с правами суперпользователя, игнорируя любые политики RLS на целевых таблицах. Это означало, что настройка логической репликации в таблицу с включённым RLS могла привести к утечке строк, которые текущий пользователь не должен видеть.

В PG 15 процесс применения выполняется с правами владельца подписки. Если владелец подчиняется RLS-политике на целевой таблице, репликация в неё будет запрещена . Для мультитенантных систем и платформ, где RLS — основной механизм изоляции, это изменение принципиально важно. Администратор теперь должен явно продумывать, кто будет владельцем подписки и какие права ему нужны.

Оптимизация трафика: пустые транзакции и keep-alive

Два точечных, но ощутимых улучшения на уровне walsender:

Если на мастере прошла транзакция, все операции которой отфильтрованы публикацией, отправитель больше не шлёт пару BEGIN/COMMIT для такой пустой транзакции . Экономия трафика и ресурсов процессора оказывается значительной в сценариях с интенсивными, но нерелевантными изменениями.
Для больших транзакций, содержащих много DML-операций, введена периодическая отправка keep-alive сообщений (по умолчанию после каждых 100 операций). Это не даёт walreceiver'у упасть по тайм-ауту, пока длится декодирование массивной пачки данных .

PostgreSQL 16: новые контуры высокой доступности

Если 15-я версия сделала логическую репликацию гибкой и безопасной, то 16-я расширила её архитектурные границы. Ключевое изменение здесь — возможность подключать подписку не только к мастеру, но и к физической реплике (standby) .

Раньше все логические слоты создавались исключительно на основном сервере. Это создавало дополнительную нагрузку на мастер и ограничивало сценарии распределённых систем. Теперь, имея несколько физических реплик под нагрузкой, можно вынести логическую репликацию на одну из них. Преимущества очевидны:

Разгрузка мастера от декодирования WAL для логических подписок.
Возможность построить цепочку: физическая реплика как источник для нескольких аналитических и отчётных подписчиков, не затрагивая основной OLTP-узел.
Более простая архитектура для географически распределённых систем, где standby находится ближе к подписчику.

Важно понимать, что на standby должен быть включён режим hot_standby, и на нём должен существовать логический слот. Это накладывает свои требования к конфигурации, но результат — гибкость, которой раньше сильно не хватало.

Точные детали и синтаксические конструкции для настройки репликации со standby следует сверять с официальной документацией PostgreSQL 16, так как они могут варьироваться в зависимости от минорной версии.

PostgreSQL 17 и 18: курс на стабильность и энтерпрайз-сценарии

Информация о конкретных изменениях в логической репликации для версий 17 и 18 на момент публикации остаётся фрагментарной и требует уточнения по официальным release notes. Однако направление развития можно оценить по патчам и обсуждениям в списках рассылки разработчиков.

Если в PG 15 и 16 акцент делался на расширение функциональности и архитектурные прорывы, то в 17 и 18 разработчики, судя по всему, сосредоточены на стабилизации, производительности и поддержке сложных корпоративных сценариев. Можно ожидать:

Дальнейшего улучшения обработки конфликтов.
Оптимизации работы с очень большим количеством публикаций и подписок.
Более плавной интеграции с инструментами мониторинга и управления.

Точные параметры, синтаксис и замеры производительности должны браться исключительно из документации соответствующих версий. Всё остальное — предположения.

Почему эти изменения принципиально важны уже сейчас

Эволюция логической репликации — не просто технический прогресс. Она напрямую влияет на архитектурные решения, которые принимают команды сегодня.

Миграции мажорных версий без долгого простоя

Обновление PostgreSQL с 14 на 15 или с 15 на 16 традиционно требовало либо даунтайма на pg_dump/pg_restore, либо сложной процедуры с pg_upgrade и физической репликацией. Логическая репликация с фильтрацией схем и столбцов позволяет построить схему миграции с минимальным окном обслуживания: создаётся подписка на новую версию, данные синхронизируются online, а переключение трафика занимает секунды. Это переводит мажорные апгрейды из разряда «ночных подвигов» в рутинную операцию.

Распределённые системы без Kafka

Многим проектам нужна асинхронная передача изменений между сервисами, но внедрение Kafka или аналогов оправдано не всегда. С фильтрацией строк и столбцов, а также возможностью подключаться к standby, логическая репликация забирает часть сценариев, которые раньше требовали внешнего брокера сообщений. Аналитическая база получает только нужные столбцы, сервис уведомлений — только строки по определённому статусу. Всё нативно, без дополнительной инфраструктуры.

Безопасная изоляция данных в мультитенантных платформах

Если ваше приложение обслуживает несколько заказчиков в одной базе, вы наверняка используете RLS для разделения данных. Появление проверок прав владельца подписки и фильтрации строк на уровне публикации означает, что вы можете безопасно организовать выгрузку данных конкретного клиента в его выделенное хранилище, не рискуя перепутать строки и не изобретая собственные велосипеды.

Практические рекомендации: стартуем без риска

Если вы только присматриваетесь к новым возможностям, начните с малого. Не пытайтесь сразу построить сложную многоверсионную схему.

Первым делом проверьте совместимость ваших текущих версий. Если мастер на PG 15, подписчик на PG 16 — проблем быть не должно, но всегда тестируйте на стенде. Определите, какие данные действительно нужно передавать. Возможно, вам не нужны все столбцы таблицы, и фильтрация на стороне публикации сэкономит трафик.

Особое внимание уделите правам. Создайте отдельную роль — владельца подписки — и выдайте ей минимально необходимые привилегии. Помните, что если на целевой таблице включён RLS, владелец подписки должен иметь BYPASSRLS или явно подпадать под политику, иначе репликация остановится.

Обязательно настройте мониторинг pg_stat_subscription_stats и следите не только за лагом, но и за счётчиками ошибок. В сочетании с параметром disable_on_error это даст вам полностью контролируемую картину.

FAQ

Можно ли с помощью логической репликации обновить мажорную версию PostgreSQL с минимальным простоем?

Да, это один из основных сценариев. Создаётся новый сервер с целевой версией, на нём разворачивается подписка на старый мастер. После завершения синхронизации трафик приложения переключается на новый сервер, и подписка удаляется. Простой при таком подходе минимален.

Как избежать конфликтов при репликации, если на подписчике уже есть часть записей?

Идеальный вариант — настроить репликацию так, чтобы подписчик изначально не получал дублирующихся данных. Если конфликт уже возник, используйте ALTER SUBSCRIPTION ... SKIP (lsn = ...) для пропуска проблемной транзакции. Для предотвращения автоматических повторных ошибок можно включить параметр disable_on_error, чтобы подписка не зацикливалась.

Поддерживает ли логическая репликация большие пакетные транзакции?

Да, с режимом two_phase = true. Декодирование начинается на этапе подготовки транзакции, данные передаются постепенно, и лаг репликации для длительных транзакций становится значительно меньше. Кроме того, конфликт может быть обнаружен до фиксации, что повышает общую надёжность.

Можно ли реплицировать только некоторые столбцы или строки таблицы?

Да, начиная с PostgreSQL 15. При создании публикации можно указать список столбцов для репликации, а также добавить WHERE-условие для фильтрации строк. Оба механизма настраиваются на стороне мастера и не влияют на структуру целевой таблицы на подписчике.

Как изменение модели прав в PG 15 повлияло на совместимость с Row Level Security?

Кардинально. Раньше apply-процесс обходил RLS, потому что работал от суперпользователя. Теперь он работает с правами владельца подписки, и RLS-политики на целевой таблице применяются в полном объёме. Это потребует пересмотра прав доступа при настройке репликации в защищённые таблицы.

Верно ли, что начиная с 16-й версии можно реплицировать данные не с мастера, а с физической реплики?

Да, это одно из ключевых изменений в PostgreSQL 16. Логическую подписку можно направить на standby-сервер с включённым режимом hot_standby, разгружая тем самым основной узел. Детали настройки слотов и параметров следует уточнять в документации конкретной минорной версии.

Вывод

Логическая репликация в PostgreSQL прошла путь от экспериментального инструмента до зрелого механизма, на котором можно строить архитектуру высокой доступности, бесшовные миграции и сложные интеграционные схемы. Версия 15 дала гранулярный контроль над данными, безопасность и управляемость ошибок. Версия 16 расширила архитектурные возможности, позволив привязываться к standby. Дальнейшие релизы обещают стабилизацию и производительность для enterprise-нагрузок.

Если вы до сих пор воспринимали логическую репликацию как слишком хрупкую для продакшена, самое время пересмотреть это убеждение. Начните с аудита ваших текущих задач — миграции, изоляция данных, распределённые запросы — и примерьте на них новые возможности. Скорее всего, вы найдёте сценарий, который раньше требовал внешних инструментов, а теперь решается штатными средствами.

Что изменилось в логической репликации PostgreSQL 15–18 и почему это важно