Как организовать чтение с реплики (read replica) в приложении и какие проблемы это создаёт из-за replication lag?

Короткий ответ

Запросы на чтение (отчёты, листинги) направляют на отдельное read-only соединение к реплике, а запросы на запись и критичные к свежести чтения — на primary; главная проблема — replication lag, когда реплика ещё не применила недавние изменения с primary, и пользователь может не увидеть собственное только что сохранённое изменение.

Как это работает подробнее

Физическая/логическая репликация PostgreSQL асинхронно передаёт WAL с primary на реплику; величина задержки зависит от нагрузки и сети (синхронная репликация устраняет эту проблему ценой задержки записи на primary).

Пример кода

example.pyКопировать

def get_order_for_display(order_id):
    return Order.objects.using("replica").get(id=order_id)  # для обычного просмотра
def create_order_and_show(data):
    order = Order.objects.using("default").create(**data)  # запись на primary
    return Order.objects.using("default").get(id=order.id)  # читаем тоже с primary, чтобы не попасть в лаг

Что использовать на практике

• Практика. Типичный паттерн — маршрутизация запросов по признаку «это SELECT без требования строгой консистентности»; для сценария «показать сразу после записи» читают с primary в течение короткого окна.

Подводные камни

• Ошибка. Отправляют на реплику запрос сразу после записи в рамках того же пользовательского действия, получая «заказ не найден» из-за лага; не мониторят сам лаг (pg_stat_replication), из-за чего деградация реплики остаётся незамеченной.