MariaDB Galera vs MySQL Group Replication vs PostgreSQL streaming replication: что выбрать для HA в 2026

Высокая доступность базы данных — тема, где легко увлечься красивыми схемами и забыть про реальные ограничения. На бумаге MariaDB Galera, MySQL Group Replication и PostgreSQL streaming replication обещают реплики, меньше простоя и защиту от отказов. На практике они решают разные задачи и по-разному ведут себя при сетевых задержках, падении узла, конфликтующих транзакциях, миграциях схемы и перегруженном диске.

Эта статья — не инструкция по установке кластера с нуля, а практичный разбор для админов, devops-инженеров и вебмастеров, которым нужно выбрать архитектуру database HA на 2026 год. Будем смотреть не только на характеристики, но и на эксплуатацию: что мониторить, какой RPO и RTO реально получить, где нужен внешний failover-менеджер, а где кластер сам принимает часть решений.

Главная мысль: HA базы данных — это не продукт, который включили и забыли. Это договоренность между приложением, сетью, дисками, бэкапами, мониторингом и людьми, которые будут разбирать инциденты.

Коротко: чем отличаются три подхода

MariaDB Galera Cluster — virtually synchronous репликация с сертификацией транзакций. Обычно ее воспринимают как multi-primary-кластер: писать можно в несколько узлов, данные распространяются по группе, а конфликтующие транзакции откатываются на этапе сертификации. Galera хорошо подходит для сценариев, где нужен активный кластер MariaDB в одной близкой сети.

MySQL Group Replication — встроенный механизм групповой репликации MySQL, основанный на взаимодействии узлов, writeset-сертификации и тесной интеграции с MySQL InnoDB Cluster. Он умеет single-primary и multi-primary, но в реальной эксплуатации чаще выбирают single-primary: один узел принимает запись, остальные служат репликами и кандидатами на продвижение.

PostgreSQL streaming replication — физическая репликация WAL от primary к standby. Это классическая модель primary-standby: один основной сервер принимает запись, реплики получают поток WAL и могут обслуживать чтение. В PostgreSQL нет встроенного универсального multi-primary для общего OLTP-сценария, зато streaming replication предсказуема, хорошо документирована и отлично сочетается с внешними инструментами failover.

Если совсем упростить: Galera — про синхронный multi-primary с требованиями к сети и дисциплине запросов; MySQL Group Replication — про управляемый HA-кластер MySQL, чаще single-primary; PostgreSQL streaming replication — про надежную primary-standby-архитектуру, где автоматизация отказов строится отдельным слоем.

Что считать высокой доступностью в 2026 году

В разговорах про HA часто смешивают разные цели. Один проект хочет пережить падение одного VDS без потери транзакций. Другой хочет масштабировать чтение. Третий хочет обновлять сервер без ночного окна. Четвертый мечтает о геораспределенной записи, но не готов платить задержкой. Это разные инженерные задачи.

Для честного сравнения стоит разделить четыре параметра:

• RPO — сколько данных можно потерять при аварии: ноль, секунды, минуты.
• RTO — за сколько времени сервис возвращается в рабочее состояние.
• Консистентность — что видит приложение после коммита и при чтении с реплик.
• Операционная сложность — сколько ручных процедур, исключений, мониторинга и учений нужно поддерживать.

Нулевой RPO обычно требует синхронной фиксации или архитектуры, где commit не считается завершенным до подтверждения другим узлом. Но нулевой RPO почти всегда оплачивается задержкой и риском остановки записи при сетевой проблеме. Низкий RTO требует автоматического failover, но автоматический failover без fencing, quorum и понятной модели владения primary может привести к split brain.

Поэтому в database HA нет бесплатного варианта: мы всегда выбираем компромисс между скоростью записи, допустимой потерей данных, сложностью эксплуатации и поведением приложения при ошибках.

MariaDB Galera: сильная сторона — активный кластер, слабая — цена синхронности

MariaDB Galera использует механизм wsrep и сертификационную репликацию. Узлы обмениваются writeset-ами, а транзакция считается успешной, если она прошла сертификацию в группе. Это не классическая асинхронная master-replica-схема, где реплика может отставать на секунды или минуты. Galera стремится держать узлы в согласованном состоянии и не любит долгие сетевые паузы.

Самая привлекательная черта Galera — возможность писать в несколько узлов. Для некоторых приложений это звучит как идеальная схема: балансировщик распределяет запросы, любой узел может принять запись, отказ одного сервера не останавливает весь сервис. Но multi-primary не означает, что приложение может бездумно выполнять конфликтующие операции на разных узлах. Если две транзакции меняют одни и те же строки, одна из них может быть откатана как deadlock или certification failure. Приложение должно уметь повторять такие операции.

Galera хорошо чувствует себя в кластере из трех узлов в одной зоне с низкой задержкой. Три узла дают quorum и позволяют пережить потерю одного. Два узла — плохая идея без арбитра, потому что при сетевом разрыве непонятно, какая сторона должна продолжать запись. Пять узлов возможны, но чем больше участников, тем выше цена координации и тем важнее стабильность сети.

Где Galera особенно уместна

• Проект уже использует MariaDB и не зависит от специфичных возможностей Oracle MySQL или PostgreSQL.
• Нужен active-active внутри одной площадки или одного региона.
• Записи короткие, транзакции компактные, конфликтов по одним и тем же строкам немного.
• Команда готова следить за wsrep-состояниями, flow control, SST и IST.
• Приложение умеет корректно повторять транзакции после конфликтов.

Если хотите глубже разобрать именно этот вариант, пригодится отдельный материал про архитектуру MariaDB Galera Cluster: там проще показать роли узлов, quorum и типовые сценарии восстановления.

Где Galera может больно ударить

Первый типовой риск — длинные транзакции и массовые изменения. Большой writeset тяжелее сертифицировать и передавать. Второй риск — DDL: изменения схемы в кластере требуют дисциплины и тестов, их нельзя воспринимать как локальную операцию на одном сервере. Третий риск — медленный узел. Если один участник не успевает применять изменения, включается flow control, и весь кластер может начать тормозить.

Также Galera не отменяет необходимость бэкапов. Ошибочный DROP TABLE, неудачная миграция приложения или логическая порча данных синхронно разъедутся по узлам. Кластер защищает от отказа узла, но не от человеческой ошибки и не от всех видов повреждения данных.

MySQL Group Replication: хороший компромисс для MySQL, если принять single-primary

MySQL Group Replication в 2026 году стоит рассматривать вместе с InnoDB Cluster, MySQL Router и MySQL Shell. Сам механизм репликации важен, но эксплуатационная ценность появляется именно из связки: кластер знает, кто primary, маршрутизатор направляет соединения, администратор получает штатные команды для проверки и восстановления топологии.

Group Replication поддерживает два режима. В single-primary только один узел принимает запись, остальные работают как secondary. При отказе primary группа выбирает новый узел, а инфраструктура маршрутизации должна перевести запись на него. В multi-primary писать можно в несколько узлов, но ограничения и вероятность конфликтов делают этот режим менее универсальным. Для большинства веб-проектов, интернет-магазинов, CRM, биллингов и SaaS-сервисов single-primary проще и безопаснее.

По ощущениям администрирования MySQL Group Replication ближе к управляемому кластеру MySQL, чем к классической асинхронной репликации. Здесь есть группа, членство, состояние узлов, сертификация writeset-ов, требования к GTID, InnoDB и настройкам совместимости. Это мощнее обычной реплики, но и менее терпимо к случайным изменениям конфигурации.

Где MySQL Group Replication уместна

• Проект уже на MySQL 8.x LTS-линейке или планирует оставаться в экосистеме Oracle MySQL.
• Нужен автоматизированный failover без перехода на MariaDB или PostgreSQL.
• Запись лучше держать на одном primary, а чтение можно распределять на secondary.
• Команда готова использовать MySQL Router или другой осознанный слой маршрутизации.
• Важна интеграция с современными средствами MySQL-администрирования.

Где Group Replication требует осторожности

Главная ловушка — ожидать от него магического active-active без последствий. Multi-primary-режим существует, но приложение все равно должно учитывать конфликты, ограничения изоляции, уникальные ключи и порядок операций. Вторая ловушка — игнорировать сетевую задержку. Чем дальше узлы друг от друга, тем выше задержка фиксации и тем сложнее отличить отказ от временной деградации сети.

Еще один практический момент — совместимость. MySQL Group Replication — это не универсальная репликация между MySQL и MariaDB. Если у вас смешанная среда, старые версии, нестандартные движки таблиц или исторически накопленные настройки, миграция потребует аудита. В идеале все таблицы должны быть InnoDB, схемы — аккуратными, первичные ключи — явными, а приложение — готовым к переподключению при смене primary.

PostgreSQL streaming replication: предсказуемость primary-standby и сильная экосистема

PostgreSQL streaming replication устроена проще концептуально: primary генерирует WAL, standby получает и применяет его. Реплика может быть асинхронной или синхронной. В асинхронном режиме primary не ждет подтверждения от standby, поэтому запись быстрая, но при аварии возможна потеря последних транзакций. В синхронном режиме primary ждет подтверждения от выбранной реплики, что снижает RPO, но добавляет задержку и зависимость от состояния standby.

Большая сила PostgreSQL — прозрачность и зрелость этой модели. Администратор понимает, где лежит WAL, как работают replication slots, почему растет лаг, что будет при задержке архивации и как восстановиться через PITR. Реплики можно использовать для чтения, аналитических запросов, резервного копирования и отчетов, но нужно помнить: тяжелые SELECT на standby могут конфликтовать с применением WAL и задерживать репликацию.

В PostgreSQL автоматический failover обычно строится внешними инструментами: Patroni, repmgr, pg_auto_failover, связкой с etcd или Consul, балансировщиком HAProxy, keepalived или DNS-переключением. Это не недостаток, а архитектурная особенность. PostgreSQL дает надежную репликацию, а решение о продвижении standby в primary выносится в отдельный слой, где можно реализовать fencing, health checks и правила конкретного проекта.

Где PostgreSQL streaming replication уместна

• Проект уже использует PostgreSQL или нуждается в его возможностях: JSONB, расширениях, сложных запросах, транзакционности и индексах.
• Нужна понятная primary-standby-модель с контролируемым RPO.
• Команда готова отдельно проектировать failover, маршрутизацию и fencing.
• Реплики нужны для чтения, отчетности, бэкапов или географически удаленного standby.
• Важны PITR, архивирование WAL и зрелые инструменты резервного копирования.

Где PostgreSQL не заменяет multi-primary

Если бизнес-требование звучит как несколько равноправных узлов принимают запись одновременно в разных регионах, PostgreSQL streaming replication сама по себе это не решит. Можно рассматривать logical replication, шардинг, специализированные расширения или изменение архитектуры приложения, но это уже другая категория решений. Для большинства классических веб-проектов primary-standby проще и надежнее, чем попытка получить универсальный multi-primary.

Сравнение по RPO, RTO и консистентности

У Galera потенциально очень низкий RPO внутри исправного quorum: транзакция подтверждается после согласования с группой. Но если сеть нестабильна, часть узлов может быть исключена, а запись продолжит только primary component. RTO при потере одного узла обычно низкий, если приложение подключается через корректный балансировщик и умеет повторять запросы. Главный риск — деградация всего кластера из-за медленного участника или сетевых проблем.

У MySQL Group Replication в single-primary RPO тоже может быть очень низким, но зависит от настроек согласованности и поведения группы. RTO при штатной интеграции с Router обычно комфортный: primary переизбирается, маршрутизация обновляется. Однако приложение должно пережить разрыв соединения и повторить транзакцию. В multi-primary появляются риски конфликтов, похожие по смыслу на Galera, хотя реализация отличается.

У PostgreSQL streaming replication RPO настраивается выбором между asynchronous и synchronous replication. Асинхронный standby быстрее и проще, но допускает потерю последних WAL-записей при внезапной гибели primary. Синхронный standby снижает или почти обнуляет потерю данных, но если синхронная реплика недоступна, запись может зависнуть или остановиться в зависимости от конфигурации. RTO определяется не самой streaming replication, а failover-слоем: насколько быстро он обнаружит отказ, продвинет standby и переключит клиентов.

Если вам обещают одновременно нулевой RPO, мгновенный RTO, запись в любой регион и отсутствие задержек — попросите показать, где именно нарушаются законы физики.

Сеть и задержки: почему один регион почти всегда проще

Все три решения чувствительны к сети, но по-разному. Синхронные и групповые механизмы особенно не любят высокую latency между узлами. Если узлы находятся в разных дата-центрах или регионах, commit может стать заметно медленнее. Для пользователя это проявится не как красивая отказоустойчивость, а как периодические тормоза при оформлении заказа, сохранении формы или записи сессии.

Для MariaDB Galera обычно разумно держать основные voting-узлы близко друг к другу. Географически удаленный узел может быть полезен для аварийного сценария, но превращать WAN в постоянный синхронный контур записи стоит только после тестов под реальной нагрузкой. Galera особенно чувствительна к jitter: средняя задержка может быть приемлемой, но редкие всплески будут влиять на весь кластер.

MySQL Group Replication тоже лучше проектировать с учетом близкой сети между участниками группы. Для распределенных сценариев иногда используют отдельные кластеры и асинхронную репликацию между ними, но это уже не простая схема «один кластер на все случаи».

PostgreSQL дает больше гибкости: можно иметь локальную синхронную реплику для низкого RPO и удаленную асинхронную реплику для disaster recovery. Так вы не заставляете каждую запись ждать удаленный регион, но получаете копию данных за пределами основной площадки. Для сценариев с переключением пользователей между площадками полезно отдельно продумать GeoDNS, weighted routing и failover, потому что база данных — только часть общей картины.

Запись, чтение и балансировщики: что должно знать приложение

Ни один из рассматриваемых вариантов не освобождает приложение от ответственности. При failover соединения рвутся. Транзакции могут быть отменены. Старые prepared statements становятся невалидными. Реплики могут отставать. Чтение после записи с другой ноды может увидеть старое состояние, если архитектура допускает eventual consistency.

Для Galera часто используют балансировщик перед несколькими узлами, но запись во все узлы стоит включать только если приложение к этому готово. Более консервативный вариант — писать в один выбранный узел, а остальные держать как горячие участники кластера. Это снижает число конфликтов и упрощает разбор инцидентов.

Для MySQL Group Replication типовая схема — MySQL Router или аналогичный слой, который разделяет read-write и read-only подключения. Приложение получает стабильные endpoints, а кластер внутри меняет primary при необходимости. Важно, чтобы пул соединений не держал мертвые подключения бесконечно и умел быстро переподключаться.

Для PostgreSQL часто применяют HAProxy, PgBouncer, keepalived, DNS с коротким TTL или сервис-дискавери. Но PgBouncer не является failover-менеджером сам по себе: он помогает с пулами соединений, а решение о том, кто primary, должен принимать отдельный контроллер или оператор.

Операционная сложность: где больше рутины

MariaDB Galera требует внимания к состоянию кластера. Нужно мониторить размер компонента, статус wsrep_cluster_status, wsrep_local_state_comment, flow control, очереди apply и recv, SST/IST, расхождение нагрузки между узлами. После аварии важно правильно выбрать donor, не потерять актуальный узел и не запустить кластер из старой копии данных.

MySQL Group Replication требует дисциплины версий и конфигурации. Нужно следить за состоянием членов группы, ролью primary, ошибками сертификации, лагом применения, Router-слоем, GTID и совместимостью параметров. Плюс — много штатной логики уже есть в экосистеме MySQL, минус — кластер становится менее прозрачным для тех, кто привык к обычной асинхронной репликации.

PostgreSQL streaming replication на первый взгляд проще, но вся сложность переезжает в failover и бэкапы. Нужно следить за replication slots, WAL-архивом, задержкой реплик, конфликтами hot standby, состоянием timeline после failover, корректностью rewind старого primary, работой DCS и балансировщика. Если failover автоматизирован плохо, PostgreSQL не спасет от split brain.

Бэкапы, PITR и тест восстановления важнее, чем тип репликации

Кластер — не бэкап. Это стоит повторять в каждой статье про HA. Репликация отлично размножает не только полезные изменения, но и ошибки. Удалили таблицу — удаление уехало на реплики. Приложение записало битые данные — они стали высокодоступными битыми данными. Злоумышленник получил права на запись — кластер честно сохранит его действия.

Для MariaDB и MySQL нужны регулярные физические или логические бэкапы, проверка восстановления, хранение binlog для point-in-time recovery, контроль срока жизни бинарных логов. Для PostgreSQL — базовые бэкапы, архивирование WAL, проверка восстановления до конкретного времени, отдельное хранение конфигурации и ролей. В 2026 году нормальная практика — не просто делать backup, а регулярно поднимать restore-среду и прогонять минимальный чек-лист приложения.

Если бюджет позволяет только один дополнительный сервер, часто полезнее сначала построить качественные бэкапы и одну понятную реплику, чем сразу собирать сложный кластер из трех узлов без восстановления. HA сокращает простой, но восстановление данных после логической аварии обеспечивает именно backup/PITR.

Облачный VDS-сервер

Виртуальные серверы с быстрым запуском и гибкой конфигурацией от 390₽ / мес

Доступные локации

Россия Нидерланды

Смотреть тарифы

Как выбирать: практические сценарии

Небольшой интернет-магазин или корпоративный сайт на MariaDB

Если проект уже на MariaDB, нагрузка умеренная, а основная цель — пережить отказ одного узла, Galera может быть хорошим вариантом. Но я бы не начинал с multi-primary-записи во все стороны. Практичнее развернуть три узла, настроить балансировщик, выбрать консервативную схему записи и протестировать отказы: остановка mysqld, потеря сети, перезапуск узла, медленный диск, восстановление из SST.

Если приложение старое, активно использует MyISAM, длинные транзакции, миграции без окон обслуживания и не умеет повторять ошибки deadlock, Galera может создать больше проблем, чем решит.

SaaS или backend на MySQL 8 с требованием автоматического failover

Для MySQL-проектов, которым нужен современный HA без перехода на другую СУБД, MySQL Group Replication в single-primary-режиме выглядит логичным выбором. Он хорошо ложится на модель один writer, несколько readers, автоматическое переизбрание и маршрутизация через Router. Особенно если команда готова использовать MySQL Shell и поддерживать единообразные версии.

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

Продукт на PostgreSQL с важными транзакциями и аналитическими запросами

PostgreSQL streaming replication обычно лучший старт для PostgreSQL HA. Primary принимает запись, одна локальная standby может быть синхронной, еще одна удаленная — асинхронной для disaster recovery. Failover можно автоматизировать Patroni или аналогом, перед ним поставить HAProxy или другой слой маршрутизации. Для чтения тяжелых отчетов лучше выделить отдельную реплику, чтобы аналитика не мешала apply WAL на критичной standby.

Если нужно нулевое или почти нулевое RPO, проверяйте не только параметр синхронной репликации, но и поведение приложения при зависшей синхронной standby. Иногда бизнес предпочтет потерять пару секунд данных, но не останавливать прием заказов. Это решение нужно принимать не на уровне DBA в одиночку, а вместе с владельцем продукта.

Минимальный чек-лист перед внедрением HA

• Опишите допустимый RPO и RTO человеческим языком: секунды, минуты, ручное подтверждение, автоматическое переключение.
• Проверьте, умеет ли приложение повторять транзакции после deadlock, failover и разрыва соединения.
• Решите, где будет единственная точка записи, если выбран single-primary-подход.
• Настройте мониторинг лага, ролей, quorum, состояния реплик, диска, сети и ошибок репликации.
• Проведите учения: выключите primary, оборвите сеть, заполните диск WAL или binlog, восстановите узел из бэкапа.
• Зафиксируйте процедуру ручного восстановления, потому что автоматический failover не покрывает все аварии.
• Проверьте бэкапы восстановлением, а не только успешным кодом завершения backup job.

Итоговая рекомендация

Если вам нужен MariaDB-кластер с активными узлами в одной низколатентной сети, а приложение готово к конфликтам и повторам транзакций, выбирайте MariaDB Galera. Это сильное решение, но оно требует дисциплины: короткие транзакции, аккуратные DDL, мониторинг flow control и понимание quorum.

Если вы остаетесь на MySQL и хотите штатную HA-архитектуру с автоматическим failover, начинайте с MySQL Group Replication в single-primary-режиме. Он дает хороший баланс между доступностью и понятностью, особенно в связке с MySQL Router. Multi-primary оставьте для случаев, где его необходимость доказана тестами, а не желанием использовать все узлы на запись.

Если ваш стек — PostgreSQL, а требования можно уложить в модель primary-standby, выбирайте PostgreSQL streaming replication и проектируйте вокруг нее failover, маршрутизацию, WAL-архив и PITR. Это не самая эффектная схема на презентации, зато одна из самых предсказуемых в эксплуатации.

В 2026 году лучший выбор для database HA редко определяется названием технологии. Он определяется тем, как ваше приложение пишет данные, сколько потерь допустит бизнес, насколько стабильна сеть между узлами и готова ли команда регулярно тестировать аварии. Galera, Group Replication и streaming replication могут быть надежной основой, если не ждать от них магии и строить HA как инженерную систему, а не как галочку в конфиге.