Как работает репликация в базах данных? Какие проблемы создаёт асинхронная репликация и как с ними жить?
Короткий ответ
- Лидер принимает записи, реплики проигрывают его журнал
- Синхронная репликация надёжнее, но задерживает коммит
- Асинхронная даёт лаг: реплика отстаёт от лидера
- Read-after-write: пользователь не видит свою только что сделанную запись
- Решения: читать своё с лидера, sticky-сессии, ждать позицию журнала
- Фейловер при асинхронности может потерять последние транзакции
Репликация масштабирует чтение и даёт отказоустойчивость, но асинхронный лаг требует явной работы с согласованностью чтений.
Как сказать вслух
пример ответаКлассическая схема — один лидер принимает записи и шлёт журнал изменений репликам, с которых можно читать. Если репликация синхронная, коммит ждёт подтверждения реплики — надёжно, но медленнее. Если асинхронная — реплики отстают, и возникает типичная проблема: пользователь сохранил данные, следующий запрос ушёл на реплику, и он своих изменений не видит. Лечится тем, что чтения после записи отправляют на лидер или ждут, пока реплика догонит нужную позицию журнала.
Подробный ответ
Основной ответ
В leader-follower репликации записи идут только в лидер, который транслирует WAL (physical) или поток логических изменений (logical replication) репликам. Синхронный режим гарантирует наличие транзакции минимум на одной реплике до ответа клиенту — ценой latency и доступности при падении синхронной реплики (компромиссы вида quorum/semi-sync). Асинхронный режим быстр, но вводит replication lag: чтения с реплик могут быть устаревшими. Классические аномалии: read-your-writes (не видишь свою запись), monotonic reads (данные «прыгают назад» между репликами). Практические решения: маршрутизация чтений пользователя на лидер в течение окна после его записи, прилипание сессии к одной реплике, ожидание достижения репликой LSN записи, версионные токены. При фейловере асинхронной схемы не доехавшие транзакции теряются, а старый лидер при возврате требует отсечения разошедшейся истории; выборы нового лидера и защита от split-brain — отдельная зона (Patroni, консенсус).
Ключевые моменты
- Зачем реплики. Масштабирование чтений, отказоустойчивость, отчёты и бэкапы без нагрузки на лидер; записи всё равно упираются в один лидер.
- Read-your-writes. Самая частая боль: форма сохранилась, список не обновился. Решение — читать критичные данные с лидера или ждать LSN.
- Цена синхронности. Каждая синхронная реплика добавляет сетевой round-trip к коммиту; часто выбирают семисинхронную схему как компромисс.
- Фейловер. Автопереключение должно учитывать лаг кандидата и исключать два лидера одновременно — иначе расхождение данных.
Практический контекст
В проде это выглядит так: ORM или прокси (например, PgBouncer плюс роутинг в приложении) делит трафик на запись в лидер и чтение с реплик, а на критичных сценариях — личный кабинет сразу после сохранения — принудительно читает с лидера. Интервьюер проверяет, знает ли кандидат про лаг не теоретически: вопрос «пользователь сохранил и не видит изменений — почему?» отделяет читавших Kleppmann-а от эксплуатировавших реплики.
Частые ошибки
- Предлагают читать с реплик всё подряд, не оговаривая read-after-write
- Считают синхронную репликацию бесплатной, забывая про latency и доступность
- Не упоминают потерю транзакций и split-brain при фейловере асинхронной схемы