Что такое мастер-слейв репликация в PostgreSQL

Что проверяют

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

Как отвечать

Начните с терминологии: в документации PostgreSQL это primary и standby, мастер и слейв разговорное наследие. Физическая потоковая репликация передаёт на standby поток журнала WAL, тот применяет его байт в байт и остаётся точной копией кластера; в режиме hot standby с него можно читать, писать нельзя. Логическая репликация работает иначе: декодирует WAL в набор изменений строк и публикует выбранные таблицы, поэтому годится для выборочной выгрузки и переезда между мажорными версиями.

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

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

Где спотыкаются

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

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

Обещают автоматическое переключение из коробки. PostgreSQL сам новый primary не выбирает: нужен внешний арбитр с кворумом и отключением старого узла, иначе получите два primary и разъехавшиеся данные.