Репликация
Тема дорожной карты · Backend разработчик
Репликация баз данных — процесс непрерывного копирования данных с основного узла базы данных на один или несколько узлов-реплик, обеспечивающий масштабируемость чтения, высокую доступность и географическую избыточность для бэкенд-систем. В PostgreSQL потоковая репликация использует Write-Ahead Log (WAL) для синхронизации standby-серверов с primary; бэкенды REST API с высокой нагрузкой на чтение маршрутизируют SELECT-запросы на реплики через пулеры соединений PgBouncer или разделение чтение/запись на уровне приложения, снимая нагрузку с primary для записей. Репликация баз данных поддерживает несколько топологий: single-primary / multiple-replica (наиболее распространённая), multi-primary для распределения записей (со сложностью разрешения конфликтов) и каскадная репликация, где реплики служат источниками для дальнейших реплик. MySQL реализует репликацию через построчную репликацию на основе binlog, тогда как MongoDB использует replica sets с автоматическим механизмом выбора лидера — всё это должно учитываться при проектировании микросервисов, зависящих от согласованных чтений после записей (используя writeConcern: majority и readPreference: primary там, где это необходимо). Репликация баз данных является ключевым компонентом плана аварийного восстановления: автоматизация переключения (Patroni для PostgreSQL, автоматическое переключение MongoDB Atlas) должна тестироваться в staging-окружениях через CI/CD-пайплайны для проверки корректного переподключения бэкенд-сервиса после события продвижения primary.
Как это работает
Репликация бывает вертикальным (более мощная машина) — до лимитов одной, потом горизонтальным (больше машин за балансировщиком). Stateless-сервисы масштабируются горизонтально тривиально; stateful (БД, очереди) — через primary-replica репликацию, шардинг или оба. Read-реплики поглощают read-нагрузку; write-throughput требует либо больший primary, либо шардинг, либо хитрости (CQRS + eventual-consistency reads). Агрессивно кешируйте на границе (CDN), на app-слое (Redis), внутри процесса.
Когда применять
Сначала вертикально — самое дешёвое и наименее болезненное операционно. Read-реплики — когда primary DB тратит > 50% CPU на чтения. Шардируйте только когда ни один primary не справляется с write rate (эта точка дальше, чем думают — Postgres держит 10k+ writes/sec с тюнингом). CDN — для любого публичного статичного или редко-меняющегося контента; выигрыш в latency обычно 5-10×.
Типичные ошибки
Ловушки Репликация: расчёт, что горизонтальное масштабирование решит всё (нет для stateful); преждевременный шардинг (необратимо без огромных миграций); игнор pooling — 1000 app-pod'ов по 10 соединений валят БД; не нагружаете до решений о масштабе (тюните не тот слой). Сначала меряйте, потом масштабируйте, потом документируйте.