Master-Slave репликация (с 2020 года всё чаще называют Primary-Replica) — механизм синхронизации данных между несколькими серверами СУБД, при котором один сервер (Master/Primary) является единственным авторитативным источником данных и принимает операции записи, а один или несколько Slave/Replica-серверов получают копии изменений и используются для чтения.
Как работает
В MySQL/MariaDB репликация работает через binary log (binlog): Master записывает все изменения в binlog в трёх форматах:
- Statement-based — SQL-запросы целиком. Компактно, но может давать расхождения при недетерминированных функциях.
- Row-based — изменённые строки. Надёжно, объёмнее.
- Mixed — автовыбор оптимального формата.
Slave подключается к Master, запускает IO thread (читает binlog) и SQL thread (воспроизводит изменения). Задержка репликации (replication lag) — типично 0-100 мс при нормальной нагрузке.
В PostgreSQL — Streaming Replication через WAL (Write-Ahead Log): реплика непрерывно получает WAL-записи. Поддерживает синхронный режим (Master ждёт подтверждения от реплики — гарантия без потерь) и асинхронный (быстрее, но возможна потеря последних транзакций при отказе).
Использование в архитектуре
Master-Slave решает несколько задач:
- Read scaling — запросы на чтение распределяются между репликами, снижая нагрузку на Master.
- Отказоустойчивость — при отказе Master реплика может быть повышена (promote) до Primary.
- Резервное копирование — mysqldump/pg_dump с реплики без нагрузки на Master.
- Географически распределённые сервисы — реплика в другом регионе снижает задержку чтения для локальных пользователей.
История и терминология
Термины «Master» и «Slave» применялись в вычислительной технике с 1950-х годов. В 2020 году ряд крупных проектов перешёл на нейтральную терминологию: MySQL 8.0 начал называть master → source, slave → replica. PostgreSQL официально перешёл на primary/standby. GitHub, Django, Redis также обновили документацию. Функциональность при этом не изменилась.