Что такое репликация в базах данных и какую проблему она решает
Что проверяют
Отличаете ли вы репликацию от шардирования и понимаете ли проблему задержки.
Как отвечать
Репликация это поддержание копий одних и тех же данных на нескольких узлах. Сразу разведите с соседним понятием: шардирование делит данные между узлами, репликация их дублирует. Обычно применяют вместе.
Какие задачи решает:
- отказоустойчивость: падение основного узла не означает потерю данных и простой, реплика становится основной;
- масштабирование чтения: запросы на чтение распределяются по репликам, снимая нагрузку с основного узла. Запись при этом всё равно идёт в один узел, поэтому её так масштабировать нельзя;
- изоляция тяжёлых запросов: аналитика и выгрузки выполняются на отдельной реплике и не мешают работе приложения;
- географическая близость: реплика рядом с пользователями сокращает задержку;
- резервное копирование без нагрузки на основной узел.
Виды по способу подтверждения:
- синхронная: основной узел ждёт подтверждения от реплики. Данные точно не потеряются, но каждая запись становится медленнее, а падение реплики останавливает запись;
- асинхронная: запись подтверждается сразу. Быстро, но при падении основного узла последние транзакции могут пропасть.
Главная практическая проблема, о которой надо сказать обязательно, это задержка репликации. Реплика отстаёт, и чтение с неё возвращает устаревшие данные. Отсюда классический дефект: пользователь сохранил профиль, страница перезагрузилась и показала старое значение, потому что чтение ушло на отстающую реплику.
Способы бороться: критичные чтения после записи направлять на основной узел, привязывать сессию пользователя к одному узлу на время, либо отслеживать позицию в журнале и ждать, пока реплика её догонит. Отставание обязательно мониторить.
Где спотыкаются
Путают репликацию и шардирование.
Считают, что реплики масштабируют и запись.
Читают сразу после записи с реплики и получают устаревшие данные.
Не следят за отставанием и узнают о нём от пользователей.