Что такое read replicas в MySQL, PostgreSQL и как масштабировать чтение

В большинстве веб-приложений нагрузка на базу данных распределяется неравномерно:
операций чтения почти всегда больше, чем операций записи.

Когда база данных начинает упираться в производительность, первое, что делают — вертикально масштабируют сервер. Но у этого подхода есть предел. Более устойчивое решение — масштабировать чтение с помощью read replicas.

В этой статье разберём, что такое read replicas, как они работают в MySQL и PostgreSQL и какие ограничения у этого подхода.

Что такое read replica

Read replica — это копия основной базы данных (primary / master), которая:

• автоматически получает изменения с основной базы,
• используется только для чтения,
• не принимает записи.

Основная база обрабатывает:

• INSERT
• UPDATE
• DELETE

Реплики обрабатывают:

• SELECT

Таким образом, нагрузка на чтение распределяется между несколькими серверами.

Как работает репликация

Репликация основана на передаче изменений с primary-сервера на реплики.

Общая схема

Application
   ├── WRITE → Primary DB
   └── READ  → Read Replicas

Изменения на primary:

• логируются,
• передаются репликам,
• воспроизводятся в том же порядке.

Read replicas в MySQL

В MySQL используется binlog-based replication.

Как это выглядит:

1. Primary пишет изменения в binary log (binlog).
2. Replica читает binlog.
3. Изменения применяются локально.

Особенности MySQL-репликации

• асинхронная по умолчанию;
• возможна задержка (replication lag);
• каждая реплика имеет собственный relay log.

Плюсы

• простая настройка;
• можно иметь много реплик;
• хорошо масштабирует чтение.

Минусы

• данные на реплике могут быть устаревшими;
• нет строгой консистентности.

Read replicas в PostgreSQL

PostgreSQL использует WAL (Write-Ahead Log).

Как работает:

1. Primary пишет изменения в WAL.
2. Реплика получает WAL-сегменты.
3. WAL проигрывается на реплике.

Типы репликации

• Asynchronous — быстрее, но возможен lag.
• Synchronous — запись считается завершённой только после подтверждения реплики.

Особенности PostgreSQL

• read replicas работают в режиме hot standby;
• на репликах доступны SELECT;
• блокировки на primary не мешают чтению на репликах.

Репликация ≠ бэкап

Важный момент:
read replica — это не резервная копия.

Если на primary:

• удалили данные,
• выполнили ошибочный UPDATE,
• удалили таблицу,

то изменения попадут и на реплики.

Для бэкапа нужны:

• snapshots,
• logical dumps,
• point-in-time recovery.

Как масштабируется чтение

На уровне приложения

Самый частый подход:

• отдельные подключения для чтения и записи;
• routing логики в коде.

Пример логики:

• все SELECT → реплики;
• все INSERT/UPDATE → primary.

Через прокси

Используются DB-прокси:

• автоматическое распределение запросов;
• failover;
• health-check реплик.

Проблема replication lag

Задержка репликации — главный подводный камень.

Типичный сценарий:

1. Пользователь делает UPDATE.
2. Сразу делает SELECT.
3. Читает старые данные с реплики.

Как с этим бороться

• читать «свежие» данные с primary;
• использовать sticky-сессии;
• учитывать lag в логике приложения.

Когда read replicas — плохая идея

Read replicas не подойдут, если:

• требуется строгая консистентность;
• большинство операций — записи;
• бизнес-логика чувствительна к задержкам.

В таких случаях лучше смотреть в сторону:

• шардинга,
• очередей,
• кэшей.

Итоги

• Read replicas позволяют эффективно масштабировать чтение.
• MySQL и PostgreSQL используют разные механизмы, но идея одинакова.
• Основные проблемы — задержка и консистентность.
• Реплики не заменяют бэкапы.
• При правильной архитектуре это один из самых простых способов масштабирования базы.