Репликация в PostgreSQL: синхронная, асинхронная и логическая

PostgreSQL предлагает три мощных механизма репликации, каждый из которых решает свои задачи: асинхронная для скорости, синхронная для надёжности и логическая для гибкости. Разберём их особенности, trade-offs и лучшие сценарии применения в production-средах.

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

🔁 Асинхронная (по умолчанию)

• Работает быстро, потому что мастер не ждёт реплику
• Но есть шанс потери данных, если мастер умрёт до отправки WAL
• Хороша для read-only реплик, бэкапов, CI

primary_conninfo = 'host=... application_name=replica'

📌 Используй, если можешь пережить потерю 1–2 секунд данных.

🧷 Синхронная

• Мастер ждёт подтверждения от реплики
• Гарантирует, что коммит записан минимум в 2 местах
• Замедляет INSERT/UPDATE, особенно по сети

ALTER SYSTEM SET synchronous_standby_names = 'replica1';

📌 Используй для критичных данных, но внимательно следи за latency.

🧬 Логическая

• Вместо побитовой копии — изменения на уровне строк
• Можно фильтровать таблицы, передавать между разными версиями PostgreSQL
• Подходит для ETL, миграций, шардирования

CREATE PUBLICATION my_pub FOR TABLE users;

📌 Используй для гибких сценариев и миграций, когда streaming не подходит.

⚖️ Таблица сравнения

🔚 Вывод

Выбор зависит от задач:

• Нужно быстро и просто → асинхронная
• Нужно безопасно и строго → синхронная
• Нужно гибко и кросс-системно → логическая