Что такое репликация
Что проверяют
Понимаете ли вы, какой ценой достаётся копия данных на втором сервере и что меняется в коде приложения, когда реплики появляются. Для разработчика на Python это прежде всего вопрос про маршрутизацию чтений и про отставание.
Как отвечать
Репликация это поддержание копии данных на другом узле переносом изменений с основного. Обычная схема: лидер и последователи. Запись идёт в лидера, он пишет журнал (в PostgreSQL это WAL), реплики применяют журнал и обслуживают чтения.
Синхронность это про момент подтверждения коммита клиенту, а не про одновременную запись. Асинхронная репликация отвечает сразу, окно потери данных равно лагу. Синхронная ждёт подтверждения реплики (можно требовать записи в журнал или уже применения), убирает это окно, но добавляет сетевой путь в каждый коммит, а падение единственной синхронной реплики останавливает запись, пока не настроен кворум.
Физическая репликация переносит блоки журнала целиком и даёт побайтовую копию кластера. Логическая переносит построчные изменения, позволяет реплицировать отдельные таблицы и переезжать между мажорными версиями.
В приложении держите два подключения: пишете в лидера, читаете с реплик. И помните, что репликация это не резервная копия: ошибочный DELETE доедет до всех реплик за секунды.
Где спотыкаются
Обещают масштабирование записи. Реплики масштабируют чтение, запись упирается в лидера, и снимается это только шардированием.
Ломают чтение своих же записей. Пользователь сохранил профиль, следующий запрос ушёл на отставшую реплику и вернул старое значение. Лечится чтением с лидера в рамках сессии после записи или ожиданием нужной позиции журнала.
Не следят за лагом и за слотами репликации. Отключённый потребитель с живым слотом копит журнал на лидере, пока не закончится диск, и вместо отказоустойчивости получается остановка основного сервера.