Если вы администрируете MySQL в продакшене, рано или поздно упираетесь в выбор: оставить классическую асинхронную репликацию (включая semi-sync) и строить отказоустойчивость вокруг неё, или перейти на MySQL Group Replication (GR), получив встроенную «групповую» согласованность и более автоматизированный failover. На бумаге GR выглядит как очевидный шаг вперёд, но на практике цена за удобство — это latency, сложность эксплуатации и более жёсткие требования к сети и дисциплине изменений.
Ниже — практичное сравнение: как модели ведут себя при авариях, где рождается split brain, какую роль играют GTID, и что это означает для ежедневных operations (обновления, бэкапы, миграции, обслуживание).
Базовые модели: что происходит при записи
Async replication в MySQL — это модель «один пишет, остальные догоняют». Транзакция коммитится на первичном узле, а затем изменения уходят на реплики через binlog. Если primary умирает, реплики могут отставать: вы получаете RPO > 0 (потеря последних транзакций возможна).
Semi-sync — компромисс: primary ждёт подтверждения хотя бы от одной реплики, что она получила (а в зависимости от режима — и записала) событие. Это снижает вероятность потерь, но не делает репликацию строго синхронной: при сбоях всё равно остаются сценарии, где часть транзакций не успела разойтись на все узлы.
MySQL Group Replication — это «группа», где узлы согласуют транзакции внутри кворума. В режиме single-primary группа выбирает один primary, остальные применяют изменения. В multi-primary несколько узлов могут принимать записи, но это резко повышает требования к приложению и контролю конфликтов.
Консистентность и RPO/RTO: что реально получите
Практически важный вопрос: что будет с данными и сколько времени займёт восстановление.
Async replication
RPO зависит от репликационного лага и от того, успела ли транзакция попасть на реплики. Даже при небольшом лаге потеря последних секунд или минут возможна. RTO (время восстановления) зависит от вашей схемы failover: ручной выбор реплики, промоут, переподключение приложения, переуказание реплик и т. д.
Сильная сторона async — предсказуемость деградации: если сеть «шалит», primary обычно продолжает принимать записи, а реплики просто отстают. Это удобно, когда важнее доступность записи, чем строгая консистентность.
Semi-sync
Здесь вы снижаете вероятность потери транзакций при падении primary, но увеличиваете latency записи: commit начинает зависеть от сети и скорости подтверждения реплики. Плюс semi-sync может «откатиться» в async, если подтверждений нет — и это важно учитывать в SLO: в плохой сети вы можете незаметно вернуться к RPO > 0.
Group Replication
GR в нормальном состоянии ближе к RPO ≈ 0 (при наличии кворума и корректной конфигурации), а failover может быть быстрее и менее ручным. Но плата — зависимость от кворума и сети: если кворум недоступен, запись должна останавливаться, иначе вы рискуете split brain на уровне данных.
Если вам критично «лучше остановиться, чем записать в два места по-разному», Group Replication по философии ближе к этому. Async чаще выбирают, когда «лучше писать хоть как-то, а потом разрулим».
На практике это означает простой выбор при проектировании SLO:
- Если вы ставите во главу угла доступность записи — чаще выигрывает async (или semi-sync как компромисс).
- Если во главе угла консистентность и предсказуемый failover — чаще выигрывает GR при хорошей сети.
Если вы планируете HA на уровне базы и хотите, чтобы параметры CPU/RAM/диска и сеть были максимально предсказуемыми, обычно удобнее держать узлы MySQL на VDS, а не «вслепую» на shared-среде.
Перед внедрением GR проверьте требования к RTT и потерям пакетов: в отличие от async, здесь сеть становится частью критического пути коммита.
Split brain: где он появляется и как проявляется
Split brain — ситуация, когда из-за сетевого разделения (partition) у вас одновременно активны два источника записей. Итог — расхождение данных и сложное восстановление.
Async replication
В классической топологии split brain обычно возникает не «сам по себе», а из-за неверного failover: вы промоутили реплику, но старый primary не был надёжно остановлен, или приложение продолжило писать в него из-за кеша DNS, балансировщика или долгоживущих соединений. Async не защищает от этого на уровне протокола — защиту строит инфраструктура: fencing, STONITH, выключение узла, блокировка сети, дисциплина переключения.
Если вы строите HA вокруг async/semi-sync, полезно иметь формализованный промоут и понятный источник истины «кто primary сейчас». Для старта можно опереться на разбор в статье Безопасный промоут реплики и сохранение топологии.
Group Replication
GR проектировался так, чтобы минимизировать split brain через кворум и членство в группе. Но split brain не исчезает «магически»: он превращается в задачу правильной топологии и «гигиены сети».
- Если у вас чётное число узлов или нет арбитра (witness), при разделении сети можно получить остановку записи на обеих сторонах.
- Если сеть нестабильна и возникают постоянные переголосования, вы получаете флаппинг primary и «дрожащий» failover.
- Если вы пытаетесь делать multi-primary без готовности приложения к конфликтам, появится «логический split brain» (конфликты записей) даже без сетевых проблем.
Вывод: GR снижает риск split brain из-за человеческого фактора в failover, но повышает важность сети и корректного кворума.
Latency: что будет с задержками и почему
Задержка записи — ключевой критерий выбора между «репликацией» и «кластерностью».
Async
Commit на primary локальный. Репликация догоняет потом. Поэтому write latency минимальна, а read на репликах зависит от lag. Если чтения допускают «слегка устаревшие» данные, это часто идеальная модель.
Semi-sync
Commit начинает ждать подтверждение. Чем дальше реплика (география, маршрутизация, перегрузка), тем заметнее рост задержек. Обычно semi-sync настраивают так, чтобы подтверждение требовалось от одной реплики, а не от всех: это баланс между latency и снижением риска потерь.
Group Replication
GR добавляет сетевые раунды согласования транзакций внутри группы. Даже в single-primary вы платите latency за групповую коммуникацию, особенно на пике нагрузки, при паузах GC и всплесках сетевой задержки. Практический «sweet spot» для GR — узлы в одной площадке или зоне с очень стабильной сетью и предсказуемым RTT.
GTID: почему без него современные failover-операции — боль
GTID — фундамент для безопасных переключений. В async без GTID вы часто вынуждены работать с позициями binlog, искать точки синхронизации и осторожно пересобирать цепочки реплик. С GTID проще безопасно промоутить реплики и подключать отставшие узлы.
В контексте сравнения:
- Для async/semi-sync GTID — практически обязательная база, если вы хотите автоматизировать failover и не собирать пазл из координат binlog.
- Для Group Replication GTID — часть модели идентификации транзакций и согласования.
Если вы ещё не включили GTID, лучше не пытаться «в один заход» менять и модель репликации, и идентичность транзакций, и схему failover. Разделяйте риски и изменения на этапы; как обычно выглядит переход и что проверять — в материале GTID и semi-sync: как подготовить безопасный failover.
Failover: автоматизация против контроля
Async/semi-sync
Failover обычно решается внешним инструментом и процессом: вы выбираете «лучшую» реплику, убеждаетесь, что она применяла максимум транзакций, продвигаете её в primary, перенастраиваете остальные реплики, переключаете приложение.
Типовые проблемные места:
- Выбор кандидата: кто на самом деле самый актуальный.
- Fencing: как гарантированно прекратить запись в старый primary.
- Каскад: если реплики реплицируются друг от друга, нужно не разрушить цепочку.
Зато у вас высокий уровень контроля и возможность принимать «неидеальные, но практичные» решения: поднять запись быстро с небольшой потерей данных (если бизнес готов), а затем аккуратно разбирать хвост.
Group Replication
GR даёт более «встроенный» failover: группа выбирает primary, узлы знают членство. Но вопросы уровня инфраструктуры всё равно остаются:
- Как приложение узнаёт, кто сейчас primary (маршрутизация)?
- Что делать при деградации сети (не падение, а именно деградация)?
- Как обслуживать узлы без каскадных переголосований и потери кворума?
Failover становится менее ручным, но operations — более «кластерными»: меньше героики, больше строгих процедур и наблюдаемости.
Если речь про продакшен с публичным трафиком, не забывайте про шифрование соединений: для MySQL-клиентов и внутренних сервисов часто проще централизованно выпустить и регулярно обновлять SSL-сертификаты, чем поддерживать разрозненные самоподписанные схемы.
Перед любыми работами с переключениями и кластерными сценариями договоритесь, где «истина» о primary (ProxySQL/Orchestrator/сервис-дискавери), и как быстро приложение переподключается.
Operations: ежедневная эксплуатация и скрытая стоимость
Под operations в этой теме обычно подразумевают не только «поднять/уронить», а рутину: обновления, изменения схемы, бэкапы, тесты восстановлений, масштабирование, расследование инцидентов.
Async/semi-sync: проще дебажить, проще объяснять
Плюсы:
- Понятная модель: primary пишет, реплики читают.
- Проще отлаживать: lag виден, binlog — линейный журнал событий.
- Проще планировать обслуживание: можно вывести реплику, обновить, вернуть.
Минусы:
- Failover — дисциплина и автоматизация снаружи MySQL.
- Риск человеческих ошибок при переключении.
- Сложнее гарантировать RPO≈0 без роста latency и без дополнительных механизмов.
Group Replication: больше автоматики, но выше сложность системы
Плюсы:
- Более строгая консистентность при правильной топологии и кворуме.
- Встроенная логика членства и выбора primary (в single-primary).
- Меньше ручных действий при штатных авариях одного узла.
Минусы:
- Чувствительность к сети и задержкам: проблемы превращаются в «кластерные».
- Сложнее обновления и обслуживание: нужно избегать потери кворума и флаппинга.
- Multi-primary часто приводит к конфликтам на уровне данных, уникальных ключей и логики приложения.
Сценарии выбора: чеклист по здравому смыслу
Ориентиры, которые обычно хорошо работают в реальных проектах.
Когда чаще выбирают async replication (или semi-sync)
- Вам важна минимальная write latency на primary.
- Вы согласны на небольшой RPO или готовы принимать решения «по ситуации» при аварии.
- У вас сильные практики эксплуатации: fencing, мониторинг lag, runbook на failover, регулярные тесты восстановления.
- Топология простая: 1 primary + N replicas, чтения с реплик.
Когда имеет смысл смотреть в сторону MySQL Group Replication
- Нужен предсказуемый failover и более строгая консистентность (RPO ближе к нулю).
- Есть стабильная сеть с низкой и предсказуемой RTT между узлами.
- Вы готовы инвестировать в observability и процедурность operations (обновления, обслуживание, реакция на деградации).
- Вы готовы начинать с single-primary, а multi-primary рассматривать только при доказанной необходимости.
Типичные ошибки, которые дорого обходятся
1) Смешать цели: «хочу и низкую latency, и RPO≈0, и простой failover»
Так почти не бывает. Если вы улучшаете консистентность, вы часто платите latency и усложняете систему. Если хотите «максимальную доступность записи всегда», придётся жить с риском расхождений и более сложным восстановлением.
2) Делать multi-primary без подготовки приложения
Multi-primary — это другой класс задач: конфликты, конкуренция за уникальные ключи, особенности автоинкремента, ретраи транзакций, идемпотентность. Если приложение к этому не готово, вы получите нестабильность и неожиданные ошибки.
3) Недооценить роль сети
Для GR сеть — часть базы данных. Потеря пакетов, джиттер, странные маршруты, перегруженные виртуальные свичи — всё это превращается в проблемы кворума и «неочевидные» остановки записи.
Итог: честное сравнение в одной фразе
Async replication (и semi-sync как компромисс) — простая и быстрая модель, где доступность записи часто выше, но failover и защита от split brain лежат на ваших operations.
MySQL Group Replication — шаг к кластерной модели: больше встроенной согласованности и потенциально более аккуратный failover, но дороже по latency и требовательнее к инфраструктуре и дисциплине эксплуатации.
Если выбираете для продакшена, начните не с технологии, а с трёх вопросов: какой допустим RPO, какой допустим рост latency на запись, и кто и как будет выполнять failover в 3 часа ночи. После этого выбор обычно становится заметно проще.
