MySQL master-slave — как нотариус и его помощники: оригинал хранит нотариус, копии — у помощников. Копии всегда чуть отстают, но если нотариус заболел, помощник возьмет его дела. На практике это значит: основной сервер пишет данные, реплики синхронно или с задержкой их копируют. Отчеты гоняются на копии, бэкап снимается без блокировок продакшена, а при падении master-узла одна из реплик быстро поднимается на его место. В статье разберем, как устроена репликация в MySQL 8 и MariaDB, чем отличаются асинхронный и semi-sync режимы, какие требования к серверу и сети действительно критичны, и в каких сценариях вместо master-slave стоит сразу смотреть на InnoDB Cluster или Galera.
Что такое master-slave репликация MySQL
Это базовая схема резервирования и горизонтального масштабирования чтения. Один сервер — источник правды, остальные — догоняющие копии.
Master пишет, slave догоняет — общая схема
Все клиентские запросы на запись (INSERT, UPDATE, DELETE) идут на основной сервер. Он применяет изменения к своим таблицам InnoDB (или, реже, MyISAM — на legacy-инсталляциях) и параллельно пишет операцию в бинарный журнал (binlog). MyISAM не поддерживает транзакций и crash recovery, поэтому для нагруженной репликации с гарантиями durability используют InnoDB. Реплика подключается к master по сети, читает binlog поточно, складывает события в локальный relay log и применяет их к своей копии данных. Получается отложенный, но связный поток изменений: реплика всегда отстает на доли секунды или больше, но содержит ту же структуру данных.
Терминология MySQL 8 vs 5.7 — source/replica вместо master/slave
С MySQL 8.0.22 официально переименовали роли: master стал source, slave — replica. Команды SHOW REPLICA STATUS, RESET REPLICA, CHANGE REPLICATION SOURCE TO — стандартный синтаксис. Старые команды (SHOW SLAVE STATUS и так далее) остаются как алиасы для совместимости. В админке и документации сейчас встречаются оба варианта — это нужно держать в голове при работе со скриптами и старыми инструкциями.
Чем отличается от master-master и group replication
Master-master — две инстанции пишут друг в друга через перекрестную синхронизацию. На бумаге звучит хорошо, на практике порождает конфликты записей и конфликты auto_increment (решаются через auto_increment_increment/auto_increment_offset). Group replication (InnoDB Cluster) — несколько узлов с консенсус-протоколом Paxos: запись принимается всеми и потом фиксируется. Это уже не master-slave, а полноценный кластер с автоматическим failover. Классическая схема с одним источником проще и стабильнее, поэтому в 80% продакшен-инсталляций используется именно она.
Зачем бизнесу нужна репликация MySQL
Не «модная фича для админа», а несколько конкретных задач, которые без репликации решаются хуже или вообще никак.
Горячий резерв на случай отказа master-узла
Главный сценарий — отказоустойчивость на уровне всей базы. Если основной сервер ушел в недоступность — отказали диски, упал гипервизор, сгорела материнская плата — одна из реплик за минуты переключается на роль источника. Клиенты направляются на нее через ProxySQL или Orchestrator, простой ограничивается одним переключением, а не часами восстановления из бэкапа. На уровне инфраструктуры это и есть отказоустойчивость БД для большинства веб-проектов.
Распределение read-нагрузки между репликами
В большинстве веб-приложений соотношение запросов чтения к записи — 10:1 или 20:1. Если read-трафик уперся в потолок одного сервера, добавление реплик решает проблему линейно: 3 реплики тянут в 3 раза больше SELECT-запросов. На уровне приложения роуты «писать на master, читать с replicas» настраиваются через ProxySQL или библиотечный read replica balancer.
Снятие тяжелых отчетов и BI без блокировок
Аналитические запросы с JOIN на десяток таблиц и агрегатами по миллионам строк могут идти минутами, держа блокировки и мешая обычным транзакциям. Если их вынести на отдельную реплику, продакшен-нагрузка перестает страдать. BI-инструменты (Metabase, Power BI, Tableau, российский Visiology) подключаются к репликам и спокойно гоняют свои отчеты.
Бэкап с реплики без нагрузки на боевую базу
mysqldump или Percona XtraBackup на больших базах создает заметную нагрузку на IOPS и CPU. Если снимать бэкап с реплики, продакшен этого не замечает. Заодно репликационный лаг на момент снятия копии служит точкой согласованности: бэкап получается из конкретного состояния, без живых транзакций посередине. Связка master-slave с бэкап-копиями реплик — стандартная система резервного копирования для нагруженных MySQL-баз.
Геораспределение — реплика в другом ЦОД для DR
Если основной ЦОД сгорит, потоп зальет серверную или прервется канал связи, реплика в географически разнесенной площадке поднимется как новый источник. RPO измеряется секундами или минутами лага репликации, RTO — временем переключения DNS или балансировщика. Это базовая DR-схема для финтеха, ритейла и e-commerce.
Типы репликации MySQL
Четыре варианта, которые встречаются на практике. Выбор зависит от компромисса между производительностью записи, durability и сложностью эксплуатации.
Асинхронная — простая, но возможна потеря данных
Master фиксирует транзакцию и не ждет подтверждения от реплик. Если основной сервер умер сразу после COMMIT, но до того, как изменения уехали в binlog реплик, последние транзакции потеряны. Для большинства задач (отчеты, кэширование, поиск, контент) это допустимо. Для финансовых операций — нет.
Полусинхронная (semi-sync) — подтверждение хотя бы одной реплики
Master ждет ACK от как минимум одной реплики, прежде чем подтвердить транзакцию клиенту. Latency на запись возрастает на 1–5 мс в зависимости от сети, зато гарантия сильнее: при падении основного сервера хотя бы одна копия точно содержит все подтвержденные транзакции. Включается через плагин rpl_semi_sync_master и rpl_semi_sync_slave (для MySQL 8.0.23+ имена переименованы в rpl_semi_sync_source и rpl_semi_sync_replica, старые работают как алиасы).
GTID-репликация — упрощает failover и пересоздание реплик
С MySQL 5.6 появился механизм Global Transaction ID — каждая транзакция получает уникальный ID, который перетекает в binlog и далее в relay log реплик. Это драматически упрощает два сценария: failover (новый источник правильно определяет позицию для подключения новых реплик) и пересоздание выбившейся реплики (не нужно вручную подбирать файл и offset). Для современных установок включают GTID_MODE=ON по умолчанию.
Row-based vs statement-based vs mixed binlog
Три формата записи в журнал. Statement-based: пишется сам SQL-запрос, реплика выполняет его повторно. Row-based: пишутся изменения на уровне отдельных строк. Mixed: смешанный режим, MySQL выбирает формат по контексту. Современная рекомендация — binlog_format=ROW: предсказуемее, безопаснее, не зависит от детерминированности функций. Накладные расходы по объему journals чуть выше, но в 95% случаев это не критично.
Требования к master-серверу MySQL
Источник несет всю запись и обслуживает часть чтений. Здесь нельзя экономить.
CPU — 8–32 ядра в зависимости от TPS
База данных под умеренной нагрузкой (до 500 TPS (по опыту продакшен-инсталляций)) уверенно работает на 8–12 ядрах Xeon Silver или EPYC. От 1000 TPS — 16–24 ядра. Высоконагруженные системы (e-commerce, биллинг, аналитика на крупных датасетах) — 24–32 ядра и больше. Подобрать подходящий сервер баз данных под конкретный TPS-профиль стоит на этапе проектирования, а не докупать ядра по факту.
RAM — 64–256 ГБ под innodb_buffer_pool_size
Главный параметр производительности InnoDB — buffer pool, кэш горячих страниц данных и индексов. Типовая рекомендация: 70–75% от RAM сервера БД. Если рабочий dataset помещается в buffer pool, чтения не идут на диск, и latency меряется микросекундами. 64 ГБ RAM — старт для средних баз; 128–256 ГБ — стандарт для крупных систем; терабайт и выше — high-end сценарии.
NVMe enterprise для data и binlog на отдельных дисках
Дисковая подсистема — частое узкое место. NVMe enterprise-серии (с PLP — Power Loss Protection и высокой выносливостью на запись) обязательны. Data-файлы InnoDB, redo log и binlog стоит разнести на разные физические носители: писатель в binlog не должен конкурировать с прикладной записью на data-томе. Для критичных систем — RAID 10 из 4–8 NVMe-дисков под data и отдельная пара под binlog.
ECC-память и RAID 10 для надежности
Сервер БД — не место для бытовой памяти. ECC обязательна, иначе случайные битовые ошибки приводят к молчаливой порче таблиц. RAID 10 (зеркала + страйп) дает запас по производительности записи и переживает выход диска без деградации скорости. RAID 5 на нагруженной БД не используют — ребилд в случае отказа создает дополнительную нагрузку и затягивается на сутки.
Требования к slave-серверу MySQL
Реплика выполняет тот же поток изменений, что и источник, плюс обслуживает read-трафик. Здесь есть нюансы.
Не обязательно идентичный master, но рядом по производительности
Распространенное заблуждение: «реплика может быть слабее, она же только читает». На самом деле она применяет все транзакции источника — единственный поток (или несколько в MTR-режиме) выполняет ту же запись. Если реплика по IOPS или CPU заметно слабее, она копит лаг и в итоге догоняет с большой задержкой. Стандарт — slave такой же или максимум на 25% слабее по производительности.
IO single-thread vs multi-thread replication (MTR)
В старых версиях MySQL реплика применяла изменения одним потоком — это часто становилось бутылочным горлом. С 5.6+ появилась multi-threaded replication: slave_parallel_workers параллелит выполнение по базам или таблицам. На современных версиях MySQL 8 и MariaDB 10 MTR настроен по умолчанию, но проверять параметр slave_parallel_workers все равно стоит — он реально снижает лаг под пиковой нагрузкой.
Достаточный объем диска под relay log и базу
Relay log хранит непримененные события из binlog источника. На большой записи он может расти десятками гигабайт в час. Закладывайте на slave-диск минимум 1,5× от размера базы — это покрывает relay log, данные, временные таблицы и точку для бэкапа. NVMe такой же выносливости, как у источника — иначе на slow disk все упрется.
Отдельный сетевой интерфейс для репликационного трафика
На high-load инсталляциях репликационный трафик идет через выделенный VLAN или физический интерфейс. Это решает две задачи: репликация не конкурирует с клиентским трафиком на пропускной канал, и админ может изолировать репликационную сеть на уровне firewall, оставив только нужные порты и протоколы. Подобрать корректное сетевое оборудование с поддержкой VLAN-сегментации — задача того же уровня важности, что и выбор дисков.
Сеть между master и slave
Канал между источником и репликой — отдельная инженерная задача, особенно при геораспределении.
Bandwidth — пиковый трафик binlog
Объем репликационного трафика равен объему записи в binlog. На средней OLTP-нагрузке это 5–50 Мбит/с, на крупных e-commerce во время распродаж — 200–500 Мбит/с. Гигабитный канал покрывает большинство сценариев в одном ЦОД. Между разнесенными площадками часто берут 10 Гбит/с с запасом.
Латентность как ограничитель semi-sync
В асинхронном режиме сеть с латентностью 5–50 мс не критична — задержка просто увеличивает лаг. В semi-sync режиме каждая транзакция ждет ACK от реплики, и сетевая задержка напрямую добавляется к latency на запись. Если semi-sync включен между ЦОД с RTT 30 мс, время коммита вырастет ровно на эти 30 мс. Поэтому semi-sync обычно живет в пределах одного ЦОД, а между регионами идет асинхронная репликация.
Защита канала — VPN, IPsec, шифрование SSL/TLS
Поток binlog содержит все изменения базы — пароли, токены, персональные данные. Между ЦОД канал обязательно шифруется: IPsec, WireGuard, MySQL SSL/TLS replication. Внутри одного ЦОД часто хватает изолированного VLAN с правилами на коммутаторе. Репликационный пользователь должен иметь минимум прав — только REPLICATION SLAVE и REPLICATION CLIENT.
Эксплуатация — мониторинг и устранение лага
Главная боль live-репликации — replica lag. Его нужно постоянно отслеживать.
Метрика Seconds_Behind_Master и ее ловушки
SHOW REPLICA STATUS выдает поле Seconds_Behind_Master — типовая первая метрика отслеживания лага. Но она обманчива: считается как разница между текущим временем и timestamp последнего примененного события. Если репликация на минуту встала, метрика покажет 60. Если канал между master и slave разорван — Seconds_Behind_Master показывает NULL, а реальное отставание не известно. Использовать ее как основной показатель — заблуждение.
pt-heartbeat, mha, orchestrator
pt-heartbeat от Percona Toolkit — стандарт измерения реального лага. На источник раз в секунду пишется специальная строка с текущим временем, на реплике сравнивается с локальным временем — разница и есть фактический лаг. Точность — миллисекунды. Orchestrator (от Github / Vitess) автоматизирует topology management и failover. MHA (Master High Availability Manager) — более старый инструмент, но все еще встречается на legacy-инсталляциях.
Типичные причины лага — длинные транзакции, slow disk, MTR не настроен
Три самые частые причины. Первая: одна длинная транзакция на источнике (например, ALTER TABLE на большой таблице) забивает binlog огромным событием, реплика 10 минут ее применяет. Решение — pt-online-schema-change или gh-ost для миграций без блокировок. Вторая: медленные диски на slave — реплика просто не успевает писать. Третья: MTR не включен или slave_parallel_workers=1, и весь поток идет в одно ядро.
Когда master-slave не подходит
Классическая репликация подходит не для каждого сценария. В трех сценариях разумнее сразу смотреть на другие топологии.
Сценарии с активной записью на оба узла
Если бизнес-логика требует, чтобы оба узла принимали запись одновременно (распределенная транзакционная нагрузка, multi-master с разрешением конфликтов), master-slave не подходит — он по определению однонаправленный. Здесь нужны Galera Cluster (Percona XtraDB Cluster или MariaDB Galera) или InnoDB Cluster.
Очень частая запись и read-after-write consistency
Если приложение пишет и сразу же читает только что записанные данные (типичный сценарий в чатах, real-time биржах), асинхронная репликация даст «исчезающие» записи: пользователь сделал коммит, обновил страницу, прочел с реплики и не увидел свою запись. Решения — semi-sync с гарантией, sticky-сессии на источник, или переход на синхронный кластер.
Когда стоит смотреть на InnoDB Cluster, Galera, Percona XtraDB Cluster
Если требования к HA жесткие (RPO=0, автоматический failover за секунды без участия админа), классический master-slave с ручным переключением — слабое решение. InnoDB Cluster дает группу из 3+ узлов с кворум-голосованием и автоматической перенастройкой топологии. Galera-кластеры (Percona XtraDB Cluster, MariaDB Galera Cluster) — synchronous multi-master с конфликт-резолюцией. Для критичных систем разумнее сразу планировать кластер из 3 узлов, а не master-slave с одним standby.
Планируете развернуть MySQL master-slave под высоконагруженный проект, отчетность или геораспределенную инфраструктуру? Наши инженеры подберут серверы под источник и реплику, настроят NVMe-диски под binlog и data, спроектируют сеть и мониторинг лага. Закажите подбор сервера под задачу — после расчета будет понятна реальная стоимость инфраструктуры.
Заключение
MySQL master-slave — надёжный и проверенный инструмент большинства веб-проектов и корпоративных систем на 2026 год. Она решает четыре главные задачи: горячий резерв с быстрым failover, масштабирование чтения, выделение нагрузки под отчеты и бэкап без блокировок продакшена. Главные параметры — это не «какой версии MySQL», а профиль железа: NVMe enterprise с отдельными томами под data и binlog, 64–256 ГБ RAM под buffer pool, 8–32 ядра CPU под TPS, защищенная сеть между источником и репликой. Semi-sync включают там, где потеря последней транзакции недопустима — за это платят 1–5 мс латентности на коммит. GTID-режим обязателен на современных инсталляциях — он спасает время на failover и восстановлении выбившейся реплики. Если требования к HA жестче (RPO=0, автоматическое переключение), master-slave уже не справится — там нужны Galera или InnoDB Cluster с тремя и более узлами. Главное в эксплуатации — мониторинг реального лага через pt-heartbeat, а не Seconds_Behind_Master.
Ответы на частые вопросы
Зачем нужна master-slave репликация MySQL?
Четыре главные задачи. Горячий резерв при отказе основного сервера. Распределение читающей нагрузки между несколькими репликами. Снятие тяжелых отчетов и BI без блокировок продакшена. Бэкап с реплики без нагрузки на боевую базу. Плюс DR-сценарий с геораспределенной репликой.
Чем отличается асинхронная и полусинхронная репликация?
В асинхронном режиме источник фиксирует транзакцию и не ждет реплики — возможна потеря последних транзакций при отказе. В полусинхронном (semi-sync) источник ждет подтверждения хотя бы от одной реплики перед коммитом. Latency на запись в semi-sync вырастает на 1–5 мс, зато гарантируется durability на двух серверах.
Сколько slave-серверов можно подключить к одному master?
Технически — десятки. Практически в одной топологии живут 3–8 реплик. Дальше начинает упираться сетевой канал источника и его CPU на отдачу binlog. Если нужно больше, делают каскадную репликацию: master → промежуточная реплика → набор финальных реплик.
Можно ли использовать slave для записи?
В классической master-slave — нет. Любая запись на реплике создает конфликт с потоком binlog от источника и ломает консистентность. Если нужна запись на нескольких узлах — переходи на Galera Cluster или InnoDB Cluster. Иногда временно делают read_only=OFF на реплике для разовых задач — но это всегда риск.
Что такое replica lag и как его уменьшить?
Replica lag — отставание реплики от источника по времени применения транзакций. Уменьшается тремя путями. Включить multi-threaded replication (slave_parallel_workers ≥ 4). Поставить на реплику NVMe такой же выносливости, как у источника. Избегать длинных транзакций и DDL без онлайн-инструментов (pt-online-schema-change, gh-ost). Реальный лаг точнее меряется pt-heartbeat, а не Seconds_Behind_Master.
Нужен ли slave такой же мощный, как master?
Не обязательно идентичный, но близко по производительности. Реплика применяет тот же поток изменений и обычно еще обслуживает read-нагрузку. Если slave заметно слабее, он начинает копить лаг под пиковой нагрузкой. Стандарт — slave не более чем на 20–25% слабее источника по IOPS и CPU.
Какие требования к сети между master и slave?
Bandwidth должен покрывать пиковый трафик binlog (5–500 Мбит/с в зависимости от TPS) плюс запас. Латентность критична только в semi-sync режиме — она напрямую увеличивает время коммита. Между ЦОД канал обязательно шифруется (SSL/TLS, IPsec, VPN). Внутри одного ЦОД — выделенный VLAN с минимальными правами для репликационного пользователя.
Подходит ли master-slave для MariaDB и Percona?
Да, полностью. MariaDB и Percona Server совместимы с протоколом репликации MySQL и поддерживают тот же набор режимов (асинхронный, semi-sync, GTID, MTR). У MariaDB есть собственная реализация parallel replication с большим набором стратегий. Percona Server поставляется с Percona Toolkit (включая pt-heartbeat и pt-online-schema-change), что упрощает эксплуатацию.
