Репликация (Replication)

Репликация — это практика поддержания синхронизированных копий базы данных на нескольких серверах, чтобы данные не были единой точкой отказа и чтобы трафик чтения можно было распределить более чем на одну машину. Там, где шардирование разбивает данные горизонтально (разные серверы хранят разные подмножества строк), репликация делает обратное — каждая реплика хранит полную копию тех же данных, синхронизируемую с первичным (также называемым «лидер» или «мастер») сервером. Почему это важно для разработчиков AI/SaaS: репликация лежит в основе двух вещей, необходимых каждому промышленному SaaS, — доступности (если первичный сервер базы данных выходит из строя, реплика может быть повышена и взять на себя нагрузку, минимизируя простой) и масштабирования чтения (аналитические запросы, панели отчётности и AI-функции, интенсивно читающие из базы данных — например, извлечение контекста для RAG — могут направляться на реплики для чтения вместо конкуренции с первичным сервером за ресурсы, которые должны оставаться быстрыми для транзакционной записи). Как это работает: стандартный паттерн — репликация первичный-реплика (или лидер-последователь) — все записи идут в первичный сервер, который передаёт журнал изменений (в Postgres — write-ahead log/WAL) одной или нескольким репликам, применяющим эти изменения для поддержания синхронности. Репликация может быть синхронной (первичный сервер ждёт подтверждения от реплики о получении записи, прежде чем подтвердить запись как завершённую — безопаснее, но добавляет задержку) или асинхронной (первичный сервер подтверждает запись немедленно, а реплики догоняют чуть позже — быстрее, но вносит задержку репликации — короткое окно, в течение которого данные реплики устарели относительно первичного сервера). Задержка репликации имеет конкретное значение в проектировании приложений: распространённая ошибка — записать данные, а затем сразу же прочитать их обратно из реплики для чтения до того, как репликация догнала, и получить устаревший или отсутствующий результат — классическая проблема согласованности «прочитать собственную запись» (read-your-own-writes), к которой особенно склонны AI-функции (например, пользователь загружает документ, приложение пытается встроить его, читая из реплики, ещё не получившей новую строку). Управляемые сервисы баз данных (AWS RDS, Google Cloud SQL, Neon, PlanetScale) обычно предлагают создание реплики для чтения в один клик. Практический пример: AI-сервис отчётности выполняет дорогие ночные агрегирующие запросы по всем данным клиентов для генерации сводных отчётов, написанных AI. Выполнение этих запросов к первичной production-базе конкурировало бы с трафиком живых пользователей и рисковало бы замедлить приложение для всех; вместо этого задание отчётности настроено на запрос к выделенной реплике для чтения, изолируя тяжёлую аналитическую нагрузку от транзакционной нагрузки, которая должна оставаться быстрой для реальных пользователей с реальными запросами.