Как установить и настроить репликацию PostgreSQL на VPS

MAATRIX

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

Зачем нужна репликация и что она даёт

Потоковая репликация PostgreSQL непрерывно передаёт журнал изменений (WAL) с мастера на реплику, и реплика применяет его, оставаясь почти точной копией мастера с задержкой в доли секунды. Это решает сразу несколько задач. Отказоустойчивость: если мастер умирает, реплику можно за минуты повысить до нового мастера и продолжить работу. Масштабирование чтения: тяжёлые SELECT-запросы и отчёты можно направить на реплику, разгрузив мастер. Резервная копия: с реплики удобно снимать бэкапы, не нагружая основной сервер.

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

Идеально держать мастер и реплику на разных физических серверах, а лучше в разных локациях: тогда падение одного дата-центра не уносит обе копии. Для этого удобно взять два VPS, например мастер в RU для минимального пинга к приложению и реплику в другой локации как географический резерв.

Подготовка мастера

На мастере нужно разрешить репликацию и настроить журнал WAL. Откройте postgresql.conf:

sudo nano /etc/postgresql/17/main/postgresql.conf

listen_addresses = 'localhost,10.0.0.5'
wal_level = replica
max_wal_senders = 10
wal_keep_size = 512MB

wal_level = replica включает нужный объём информации в журнале, max_wal_senders задаёт число процессов-отправителей. Теперь создайте отдельную роль для репликации с соответствующим правом:

sudo -u postgres psql -c "CREATE ROLE replicator WITH REPLICATION LOGIN PASSWORD 'слоЖный_Пароль_2026';"

Разрешите реплике подключаться в pg_hba.conf, указав её адрес и специальную базу replication:

host    replication   replicator   10.0.0.6/32   scram-sha-256

Перезапустите мастер: sudo systemctl restart postgresql. Теперь он готов отдавать журнал реплике.

Слот репликации: страховка от потери WAL

Прежде чем поднимать реплику, создайте на мастере слот репликации. Слот гарантирует, что мастер не удалит сегменты WAL, пока реплика их не получит, даже если реплика ненадолго отключилась:

sudo -u postgres psql -c "SELECT pg_create_physical_replication_slot('replica1');"

Без слота при долгом отключении реплики мастер может удалить нужные ей сегменты журнала, и реплику придётся пересоздавать с нуля. Со слотом мастер держит WAL до тех пор, пока реплика не подтвердит получение. У этого есть обратная сторона, о которой важно помнить: если реплика умерла навсегда, а слот остался, мастер будет копить WAL бесконечно и рано или поздно забьёт диск. Поэтому мёртвые слоты нужно удалять — это одна из самых частых причин внезапного переполнения диска на мастере.

Создание реплики

На втором сервере установите ту же мажорную версию PostgreSQL, остановите службу и очистите каталог данных. Затем снимите базовую копию с мастера утилитой pg_basebackup — она заберёт полную копию данных и настроит подключение к слоту:

sudo systemctl stop postgresql
sudo -u postgres rm -rf /var/lib/postgresql/17/main/*
sudo -u postgres pg_basebackup -h 10.0.0.5 -U replicator -D /var/lib/postgresql/17/main \
  -S replica1 -R -P

Флаг -R автоматически создаёт файл настроек подключения (standby.signal и параметры в конфиге), -S replica1 привязывает реплику к слоту, -P показывает прогресс. После копирования запустите реплику:

sudo systemctl start postgresql

Реплика поднимется в режиме hot standby — она принимает запросы на чтение и одновременно применяет журнал с мастера. Убедитесь, что в postgresql.conf реплики стоит hot_standby = on (по умолчанию так и есть), иначе к ней нельзя будет подключаться на чтение.

Один важный момент про версии и архитектуру. Мастер и реплика должны работать на одной мажорной версии PostgreSQL и на совместимой архитектуре процессора — потоковая репликация передаёт физический журнал WAL, а он привязан к формату конкретной версии. Нельзя реплицировать с PostgreSQL 16 на 17 потоковым способом, для перехода между версиями существует логическая репликация. Поэтому, планируя пару серверов, ставьте на оба одинаковую версию из одного репозитория PGDG. Если приложение направляет часть чтения на реплику, заранее продумайте в коде обработку небольшого отставания: данные, только что записанные на мастер, могут появиться на реплике с задержкой в доли секунды, и запрос сразу после записи иногда вернёт ещё старое значение.

Проверка работы и отставания

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

sudo -u postgres psql -c "SELECT client_addr, state, sync_state FROM pg_stat_replication;"

Строка с адресом реплики и состоянием streaming означает, что журнал передаётся. На самой реплике проверьте, что она в режиме восстановления и измерьте отставание:

sudo -u postgres psql -c "SELECT pg_is_in_recovery(), now() - pg_last_xact_replay_timestamp() AS lag;"

Значение lag показывает, насколько реплика отстаёт от мастера. В нормальной работе это доли секунды. Если отставание растёт — реплика не успевает применять журнал: причиной может быть слабый диск на реплике, сетевая задержка между серверами или тяжёлые долгие запросы на реплике, которые блокируют применение WAL. Регулярно следите за отставанием — это главный индикатор здоровья репликации.

Переключение при аварии

Если мастер вышел из строя, реплику повышают до нового мастера командой промоута:

sudo -u postgres pg_ctlcluster 17 main promote

После промоута бывшая реплика становится полноценным мастером, принимает запись, и приложение переключают на неё. Важно понимать: это ручное переключение, и для автоматического failover нужны отдельные инструменты (Patroni, repmgr), которые следят за мастером и повышают реплику сами. Для многих проектов ручного переключения достаточно, если есть мониторинг и понятная процедура. Главное — не допустить ситуации «split-brain», когда старый мастер ожил и оба сервера принимают запись: старый мастер после аварии выводят из работы или пересоздают как реплику нового.

Отказоустойчивая схема требует минимум двух серверов, желательно в разных локациях. В MAATRIX можно арендовать VPS под мастер и реплику PostgreSQL в России, США или Великобритании и оплатить картой РФ, по СБП, криптой или токеном MAAT — иностранная карта не нужна.

Частые вопросы