Работали ли вы с репликацией таблиц

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

Понимаете ли вы, как репликация меняет код приложения, а не только команды администратора базы. Для разработчика на Go вопрос сводится к трём вещам: куда отправлять запрос, что делать с отставанием реплики и как пережить переключение мастера.

Как отвечать

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

Со стороны Go это два пула соединений: один на мастер, другой на реплики, и явный выбор по типу операции. Отставание надо уметь померить и учесть:

select now() - pg_last_xact_replay_timestamp() as lag;

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

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

Читают с реплики сразу после записи. Асинхронная репликация не даёт гарантии read-your-writes, пользователь не видит собственное изменение и жмёт кнопку второй раз. Локально это не воспроизводится: лаг на одной машине почти нулевой. Свежее чтение после записи направляют на мастер.

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

Ждут от логической репликации переноса схемы. Она возит данные, а не DDL: новая колонка на мастере у подписчика не появится сама, и поток встанет ровно тогда, когда об этом забудут.