2026: приёмка репликации PostgreSQL 18 между основным и резервным узлами: чек-лист переключения

Согласно официальной политике версий PostgreSQL, для каждой основной версии предусмотрено пять лет поддержки. Поэтому приёмка PostgreSQL 18 не должна сводиться к тому, что резервный узел подключён или задержка репликации выглядит небольшой: отдельно проверьте получение и применение WAL, плановое повышение резерва, восстановление записи в приложении, состояние логических слотов и готовность отката. При асинхронной репликации транзакции, ещё не дошедшие до резерва, могут отсутствовать после переключения; репликация не заменяет резервные копии, хранящиеся вне сервера.

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

Сначала зафиксируйте критерии приёмки

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

Достаточно ли нормальной задержки, чтобы переключать базу? Нет. Показатель задержки описывает только часть состояния репликации и не доказывает, что WAL полностью получен и применён, что резерв можно повысить или что приложение правильно перенаправит запись. Для решения сопоставьте позиции WAL, фактическую роль узлов и результаты прикладной проверки.

До начала работ зафиксируйте исходное состояние:

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

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

Проверка WAL и состояния физических узлов

Для проверки PostgreSQL streaming replication сопоставьте данные на обоих концах соединения. На основном узле представление pg_stat_replication показывает состояние подключённых отправителей и позиции WAL, отправленные резервному узлу, записанные, сброшенные на диск и воспроизведённые. На резервном узле pg_stat_wal_receiver позволяет проверить состояние приёмника и последнюю полученную позицию. Описание этих полей и наблюдения за потоком приведены в документации PostgreSQL 18 по резервным узлам и потоковой репликации.

Пример проверки на основном узле:

SELECT
    application_name,
    state,
    sync_state,
    sent_lsn,
    write_lsn,
    flush_lsn,
    replay_lsn,
    write_lag,
    flush_lag,
    replay_lag
FROM pg_stat_replication;

На резервном узле проверьте, что соединение с источником действительно установлено, а позиции получения и воспроизведения обновляются:

SELECT
    status,
    received_lsn,
    latest_end_lsn,
    last_msg_receipt_time
FROM pg_stat_wal_receiver;

SELECT
    pg_is_in_recovery() AS is_standby,
    pg_last_wal_replay_lsn() AS replay_lsn;

Здесь важны не отдельные цифры, а согласованная картина. Наличие строки в представлении на основном узле подтверждает подключение отправителя, но не означает, что все необходимые записи уже применены на резервном. Сравните отправленную и воспроизведённую позиции, выясните, изменяются ли они при тестовой нагрузке, и проверьте журналы PostgreSQL на ошибки соединения, записи или воспроизведения WAL. Для команд и функций администратора используйте официальную документацию PostgreSQL 18 по административным функциям.

Как определить, что резервный узел действительно готов к повышению? Убедитесь, что он принимает WAL от ожидаемого основного узла, позиции получения и воспроизведения не противоречат друг другу, а pg_is_in_recovery() подтверждает режим восстановления до начала испытания. Затем проведите контролируемое повышение и проверьте фактическую роль узла после него. Один лишь доступ к порту или успешное подключение клиента готовность к повышению не подтверждают.

Отдельно проверьте replication slots. Слот может удерживать WAL, необходимый потребителю, но при остановившемся потребителе это также способно привести к накоплению WAL на основном сервере. Сверьте состояние слотов с перечнем физических и логических потребителей, а также с параметрами репликации, которые действуют в вашей конфигурации. В описании представления pg_replication_slots для PostgreSQL 18 перечислены поля, помогающие оценить состояние слотов и удержание WAL; параметры отправки и хранения рассматриваются в документации по конфигурации репликации.

Чек-лист DBA:

• [ ] На основном узле виден ожидаемый резервный процесс, а его состояние не расходится с конфигурацией команды.
• [ ] На резервном узле подтверждено получение WAL от правильного источника.
• [ ] Отправленная, записанная, сброшенная и воспроизведённая позиции проверены в контексте активности базы, а не как одиночный снимок.
• [ ] В журналах нет необъяснённых ошибок, а ответственные знают, как обнаружить отставание или прекращение потока.
• [ ] Каждый слот сопоставлен с реальным потребителем; для неиспользуемых слотов определено безопасное действие.
• [ ] Для асинхронной репликации документировано, что ещё не переданные резерву транзакции могут быть потеряны при аварийном переключении.

Последний пункт принципиален: асинхронная схема не обещает, что резерв содержит каждую подтверждённую основным узлом транзакцию к моменту аварии. В приёмочном документе нужно зафиксировать этот риск и определить, как команда оценивает допустимый разрыв по данным. Не подменяйте эту оценку формулировкой «задержка обычно небольшая»: без измерений в вашей среде это не подтверждённое свойство.

Сетевая и аппаратная готовность

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

Проверьте условия на обоих серверах: доступный объём памяти, свободное пространство на NVMe, состояние файловой системы, системную нагрузку, журналирование и возможность подключиться к узлу при отказе приложения. Важно оценивать не только штатную нагрузку, но и поведение при догоняющем применении WAL и одновременных фоновых задачах. Если эти процессы конкурируют за ресурсы, измерения и наблюдения следует проводить на тестовой нагрузке, сопоставимой с ожидаемым рабочим сценарием. Без реальных результатов тестирования нельзя приписывать конфигурации конкретные значения задержки или производительности.

Сверьте распределение данных, журналов и копий с планом защиты. Прямое подключение накопителей не означает наличия аппаратного RAID: если требуется локальная отказоустойчивость дисков, команда должна отдельно спроектировать программное зеркало или другой подход и проверить его поведение. Ни программный RAID, ни репликация на второй сервер не заменяют внешнюю копию и проверку восстановления. Документация PostgreSQL отдельно описывает варианты резервного копирования и восстановления; архитектуру копий следует оценивать независимо от готовности физического резерва.

Перед испытанием сопоставьте серверы с действующим продуктовым предложением: фактически доступные конфигурации, накопители, системы, способы доступа, условия оплаты и расположение площадки. Эти параметры нельзя переносить на все предложения без проверки. В каталоге конфигураций и условий аренды SFP Cloud следует сверить доступную комплектацию для каждого узла; аренда сервера сама по себе не означает, что поставщик создаёт кластер, проектирует репликацию или выполняет переключение за команду.

Плановое повышение резервного узла

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

До выполнения действий:

• [ ] Зафиксируйте текущие роли, состояние соединения и позиции WAL на обоих узлах.
• [ ] Проверьте, что команда понимает последствия асинхронной репликации и критерий допустимости возможного расхождения.
• [ ] Согласуйте окно, участников, канал координации и способ остановить испытание до начала записи.
• [ ] Определите, каким способом будет исключено появление двух одновременно активных узлов, принимающих запись.
• [ ] Убедитесь, что доступна проверенная копия данных вне тестируемых серверов и известна процедура её восстановления.

Во время процедуры выполняйте действия по заранее утверждённому сценарию и записывайте время, исполнителя, вывод команд, изменение роли и принятое решение. Для запланированного теста не имитируйте аварийное исчезновение основного узла, если это не предусмотрено безопасным планом: сначала установите, кто и как гарантирует его изоляцию. Затем используйте предусмотренный документацией механизм продвижения резервного узла. PostgreSQL предоставляет функцию pg_promote() для инициирования выхода из режима восстановления; точный порядок и ограничения нужно сверять с руководством PostgreSQL 18 по переключению резервного сервера.

После повышения проверьте, что прежний резерв больше не находится в режиме восстановления и что новый основной узел может принимать допустимую тестовую запись. Запись должна быть безопасной для проверки, иметь однозначный результат и не затрагивать данные клиентов. Передавайте подтверждение результата по цепочке: состояние узла, проверка транзакции и согласие ответственного DBA. Не считайте завершение команды продвижения доказательством того, что весь прикладной путь работает.

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

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

Проверки приложения и логических потребителей

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

Пройдите сценарий на контролируемой операции:

• [ ] Приложение прекращает использовать соединения, ведущие к прежнему основному узлу.
• [ ] После изменения маршрута оно устанавливает соединение с новым основным узлом.
• [ ] Чтение и безопасная тестовая запись направляются на ожидаемый узел.
• [ ] Обработчик ошибок не повторяет операцию без проверки её результата.
• [ ] Идемпотентность и защита от повторной отправки проверены для тех операций, где клиент не может знать, успел ли сервер подтвердить транзакцию.
• [ ] Ответственный фиксирует не только момент подключения, но и подтверждённое восстановление целевой бизнес-операции.

Что проверять в приложении после переключения PostgreSQL? Переподключение пула — не единственный критерий. Проверьте чтение, запись, обработку незавершённой транзакции и поведение повторного запроса после разрыва соединения. Если клиент получил ошибку или не получил подтверждение, команда должна установить, была ли операция зафиксирована, прежде чем отправлять её снова. Иначе возможны как потеря ожидаемого результата, так и дублирование действия.

Для CDC, логических подписок и других потребителей WAL требуется отдельная проверка. Физическая потоковая репликация и логическая репликация решают разные задачи, поэтому статус физического резервного узла не доказывает, что логический потребитель продолжит работу после смены основного сервера. Сначала составьте перечень подписок, слотов и систем, которые их используют; если таких зависимостей нет, зафиксируйте «не применяется» и не добавляйте формальный шаг ради отметки в документе.

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

Сохраняются ли логические слоты после смены основного узла? Это зависит от конфигурации логической репликации и синхронизации необходимых слотов; считать их автоматически готовыми нельзя. Проверьте каждый используемый слот, подтвердите, что он доступен на узле, который стал основным, и установите, может ли конкретный потребитель продолжить обработку без пропуска или повторной передачи данных. В протоколе проверки перечислите потребителей и результат для каждого.

Условия допуска, остановки и возврата

Результат приёмки должен быть пригоден для дежурной смены, а не только для специалистов, проводивших тест. Вместо общей отметки «репликация работает» приложите наблюдения по WAL, подтверждение повышения, результат прикладного сценария, состояние логических слотов либо обоснование неприменимости и процедуру обработки старого основного узла.

До начала испытания также назначьте человека, который вправе остановить процедуру. Критерии остановки должны быть конкретными: например, обнаружено, что роли узлов неясны; часть требуемого WAL не подтверждена; приложение продолжает писать в старый адрес; логический потребитель теряет ожидаемый слот; изоляция прежнего основного не подтверждена. После остановки действия выполняются по согласованной процедуре, а не по предположению, что повторный запуск команды устранит проблему.

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

Выбор серверной схемы и завершение приёмки

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

При сравнении учитывайте не только ежемесячную стоимость. В расчёт входят время DBA и дежурных, хранение внешних копий, проверка восстановления, наблюдение за слотами, обслуживание ОС и последствия неудачного переключения. Выделенный сервер не избавляет от этих задач и не создаёт резервный узел автоматически: физическую топологию, сетевую доступность, порядок продвижения и защиту от одновременной записи проектирует и проверяет команда.

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

Если выбранная архитектура требует независимых ресурсов и контроля над серверной средой, имеет смысл сверить фактические варианты аренды выделенных серверов SFP Cloud: объём памяти, доступные NVMe, операционную систему и период оплаты следует оценивать по актуальному предложению. При этом топология репликации, программное резервирование дисков, внешнее копирование и автоматизация переключения остаются отдельными решениями команды; одна арендуемая машина не является готовым кластером. До допуска PostgreSQL 18 к рабочей записи следует завершить репетицию повышения, проверить приложение и логических потребителей, а восстановление из копии подтвердить отдельно.