Репликация базы: почему чтение с реплики — не всегда актуальные данные

Вопрос звучит просто: «как масштабировать чтение в системе с высокой нагрузкой». Ответ «добавим read-реплики» засчитывают только наполовину — дальше спрашивают, что произойдёт с пользователем, который только что сделал запись и сразу читает.

Схема: primary принимает все write-запросы, replicas обслуживают read. Репликация асинхронная в большинстве случаев — primary не ждёт подтверждения от реплики перед коммитом. Отсюда replication lag: промежуток времени, за который изменение добирается от primary до реплики.

Если пользователь обновил профиль и тут же читает его с реплики, которая ещё не догнала primary — он увидит старые данные. Это нормальное поведение eventual consistency, а не баг, но архитектор обязан явно решить, что делать с этим окном.

• read-after-write для своего же пользователя — читать с primary сразу после записи • для остальных читателей — смириться с лагом в десятки-сотни миллисекунд • синхронная репликация убирает лаг, но замедляет каждую запись — trade-off, а не бесплатное решение

Следующий вопрос почти всегда: «а что если реплика отстала на 10 секунд из-за долгого запроса на ней самой — как это обнаружить?» Ответ — мониторинг replication lag как отдельной метрики, а не предположение, что лаг всегда маленький.

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

senior·base — что спрашивают на самом деле

В этом посте были ссылки, но мы их удалили по правилам Сетки