Почему выбирают архитектуру репликации PostgreSQL с одним мастером и двумя синхронными репликами

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

Понимаете ли вы, что синхронная репликация покупает сохранность данных, а не доступность, и знаете ли, чем за это платят. Заодно проверяют, откуда в схеме именно две реплики, а не одна.

Как отвечать

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

Две синхронные реплики берут ради кворума. При настройке вида ANY 1 (r1, r2) коммит ждёт подтверждения от любой одной из них, и потеря или отставание второй запись не останавливают. Если синхронная реплика ровно одна, её падение подвешивает коммиты до вмешательства руками: транзакции ждут подтверждения, которого некому дать.

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

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

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

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

Третье: не могут сказать, что делать при потере кворума. Отключить синхронность под нагрузкой значит принять риск потери данных, оставить как есть значит остановить запись. Решение принимают заранее и записывают в регламент.