Определение простыми словами
Репликация — это автоматическое копирование изменений с одного сервера на один или несколько других. Если основной (master, primary) узел выходит из строя, реплики (replica, secondary, standby) продолжают обслуживать запросы. От обычного бэкапа репликация отличается тем, что выполняется непрерывно: задержка между записью на мастер и появлением данных на реплике обычно измеряется миллисекундами или секундами, а не часами.
Репликация решает две независимые задачи. Первая — отказоустойчивость: при падении мастера можно автоматически промоутить реплику в новый мастер (failover). Вторая — масштабирование чтения: запросы SELECT можно равномерно распределять между репликами, разгружая мастер. Важно понимать: репликация не заменяет бэкап. Случайно удалённая строка моментально пропадёт и на мастере, и на всех репликах.
Сравнение (таблица)
| Тип | Когда подтверждается коммит | Риск потери данных | Применение |
|---|---|---|---|
| Синхронная | После записи на мастере и хотя бы одной реплике | Низкий | Финансы, биллинг |
| Асинхронная | Сразу после записи на мастере | Возможна потеря последних транзакций | Веб-приложения, аналитика |
| Полусинхронная | После записи на мастере и подтверждения от реплики (без applied) | Средний | Компромисс скорости и надёжности |
| Логическая | Передаются строки/события | Зависит от режима | Миграции версий, частичная репликация |
| Физическая (бинарная) | Передаётся WAL/binlog побайтно | Зависит от режима | Hot standby, идентичные копии |
Кейсы использования
- PostgreSQL streaming replication: мастер шлёт WAL-сегменты репликам через protocol-уровень.
- MySQL/MariaDB binlog replication для read-replicas в облаках Yandex Cloud, Selectel.
- Redis Sentinel: автоматический failover между мастером и репликами для кэшей и очередей.
- Файловая репликация через rsync или rclone по cron — для статики и медиа.
- DRBD: блочная репликация на уровне устройства для кластеров высокой доступности.
- Негативный сценарий: рассчитывать на репликацию как на единственный механизм защиты данных. Удаление таблицы DROP TABLE мгновенно прилетит на все реплики. Репликация защищает от падения железа, но не от человеческих и логических ошибок — нужен независимый бэкап с retention.
Технические детали
# PostgreSQL: создание реплики через pg_basebackup
pg_basebackup -h primary.example.com -D /var/lib/postgresql/16/main
-U replicator -P -R -X stream
# Проверка статуса репликации на мастере
psql -c "SELECT client_addr, state, sync_state, replay_lag FROM pg_stat_replication;"
# MySQL: настройка реплики
CHANGE MASTER TO
MASTER_HOST='primary.example.com',
MASTER_USER='repl',
MASTER_PASSWORD='secret',
MASTER_AUTO_POSITION=1;
START SLAVE;
SHOW SLAVE STATUSG
# Redis Sentinel: проверка состояния
redis-cli -p 26379 sentinel master mymaster
# Файловая репликация по расписанию
rsync -avz --delete /var/www/ backup.example.com:/backup/www/
Контролируйте показатель replication lag: для PostgreSQL это pg_last_wal_replay_lsn, для MySQL — Seconds_Behind_Master. Значения выше нескольких секунд под нагрузкой — повод проверить сеть и нагрузку на реплику.
🔥 Где это применяется
Частые вопросы
Чем репликация отличается от бэкапа?
Репликация даёт актуальную копию здесь и сейчас, но повторяет все ошибки мастера, включая удаления. Бэкап хранит снимок на момент времени и позволяет откатиться. Эти инструменты дополняют друг друга, а не заменяют.
Что такое split-brain?
Ситуация, когда из-за разрыва сети мастер и реплика одновременно считают себя primary и принимают записи. После восстановления связи данные расходятся. Защита — кворум через арбитра (например, etcd, Consul, Zookeeper).
Можно ли реплицировать только часть базы?
Да, через логическую репликацию. В PostgreSQL — публикации и подписки, в MySQL — replicate-do-db и replicate-wild-do-table. Физическая репликация копирует базу целиком.