Почему MariaDB Galera Cluster теряет синхронность под нагрузкой
MariaDB Galera Cluster подтверждает запись не на одном узле, а после того, как транзакцию сертифицировали все участники. Пока узлы успевают одинаково, подтверждение записи и репликация неразделимы: потери данных при отказе одного сервера нет. Схема ломается ровно тогда, когда один узел перестаёт успевать — механизм регулирования потока притормаживает весь кластер до скорости самого медленного участника.
Второй шаг к сбою — выпадение узла. Сервер отвалился по сети или застрял на полной передаче состояния, оставшиеся не набирают большинство, и распад кворума переводит часть кластера в режим без права записи. Приложение получает ошибку о неготовности узла, соединения висят в ожидании, и запись встаёт целиком, хотя диски целы и данные на месте.
Опаснее обратный сценарий: пока кластер разделён, меньшая часть успевает принять и подтвердить транзакции клиенту, а после восстановления связи они не проходят сертификацию и отбрасываются. Так подтверждённая транзакция не доезжает до остальных узлов — это уже не отказоустойчивость базы данных, а расхождение, которое приходится сверять вручную.
На пике такой сбой вероятнее: растут очереди сертификации, дольше удерживаются блокировки записи, а всплеск на одном узле через регулирование потока разгоняет задержки на всех. Любой перезапуск или передача состояния на горячем кластере выбивает кворум особенно легко.
Разбираем, как это закрывается: как считать кворум и вес узлов, чем удержать отставший узел в кластере и как построить схему, при которой отказ узла не приводит к блокировке записи.
Что даёт синхронная репликация с подтверждением записи
Запись считается подтверждённой только тогда, когда её принял кворум узлов, а не один ведущий сервер. Клиент получает ответ уже после фиксации на большинстве — поэтому класс отказов «потеря подтверждённых данных» уходит: если узел выпадает сразу после ответа, транзакция всё равно остаётся на остальных. MariaDB Galera Cluster закрывает это на уровне самой репликации, без доработок в приложении.
При отказе узла кворум пересобирается сам, а маршрутизация трафика за секунды уводит клиентов на живые узлы. Время переключения измеряется единицами секунд и не зависит от объёма базы — переключение не ждёт применения журналов. Приложение видит короткий разрыв соединений, а не простой на минуты.
Вернувшийся узел восстанавливается горячим способом: получает снимок состояния и догоняет поток изменений, пока остальные продолжают принимать запись. Запись при этом не останавливается — снижение простоя достигается за счёт того, что восстановление идёт параллельно с рабочей нагрузкой.
Плата за это — задержка записи определяется самым медленным узлом набора, поэтому сеть между узлами и их число подбираем осознанно: нечётный кворум, без лишних участников. Слабое звено видно по метрикам потока репликации, и это первое, что мы проверяем при настройке.
Режимы репликации MariaDB: сравнение вариантов
Режимы репликации различаются не «полнотой», а тем, кто подтверждает фиксацию изменения и что происходит при расхождении узлов. От этого зависят поведение при сбое, чувствительность к задержке между площадками и то, какой откат вообще возможен.
| Вариант | Когда подходит | Ограничения режима |
|---|---|---|
| Асинхронная репликация | отчётные копии, разнесённые площадки, где потеря последних изменений допустима | основной узел подтверждает фиксацию, не дождавшись копии: при сбое до передачи журнала разница теряется безвозвратно |
| Полусинхронная репликация | нужен баланс между скоростью записи и гарантией, что копия приняла журнал | подтверждение приходит до применения на копии, поэтому при переключении часть изменений ещё догоняет; поведение при недоступности копии задаётся политикой таймаута |
| Синхронное подтверждение (Galera) | критичные данные, где расхождение узлов недопустимо, а узлы стоят в одной сети с малой задержкой | фиксация проходит только на большинстве узлов: потеря кворума останавливает запись, а рост числа узлов увеличивает время отклика на запись |
| Копия с задержкой применения | защита от ошибочного массового изменения | переключение не ускоряет, требует отдельного узла и запаса места под журналы |
Выбор не бинарный: в одной инсталляции синхронный кластер обычно несёт критичные базы, а асинхронная копия — отчётность и аналитику. Так нагрузка чтения уходит с основного контура, а требования к задержке между площадками остаются выполнимыми.
Внедрение отказоустойчивого кластера: этапы работ
Кластер синхронной репликации на MariaDB Galera не собирают «на живую»: порядок работ определяет, будет переключение при отказе предсказуемым или превратится в ручные операции под давлением. Каждый этап заканчиваем артефактом, который проверяем до перехода к следующему.
- Аудит текущей схемы. Топология, размер горячих данных, задержки между узлами, изменения структуры вне регламента, поведение приложения при ошибке записи. Результат — карта узких мест и перечень запросов, недопустимых в кластере: долгие блокирующие транзакции, массовые вставки без разбиения.
- Проектирование топологии. Число узлов, кворум, отдельный арбитр вне основной зоны отказа, режим подтверждения транзакции записью на кворум. Здесь же фиксируем поведение при потере кворума: остановка записи автоматически или по решению дежурного.
- Настройка синхронной записи. Параметры потока репликации, ограничение размера транзакции для догона изменений, поведение узла при отставании, перевод узла в режим без записи. Проверяем, как приложение переживает откат транзакции и переподключение к другому узлу.
- Тесты отказа. Плановый вывод узла, резкая остановка, разрыв сети между зонами, потеря кворума, полная пересборка узла с донора. Фиксируем время восстановления записи и число потерянных подтверждённых транзакций — цель ноль.
- Резервное копирование и восстановление. Снимок с узла-донора, проверка восстановления на отдельном контуре, регламент полной синхронизации, когда догон изменений невозможен.
- Передача в эксплуатацию. Мониторинг состояния узлов и отставания, инструкции дежурному, порядок замены узла и обновления структуры в окно. Дальше — сопровождение, пока команда не проведёт замену узла сама.
Конфигурации, схемы кворума и регламенты переключения
После внедрения у команды заказчика остаётся не только работающий кластер, но и комплект артефактов, по которым его можно эксплуатировать без нас. Ниже — то, что мы передаём в хранилище конфигураций заказчика и разбираем на передаче.
- Файлы конфигурации узлов. Полный набор параметров синхронной репликации: имя кластера, режим подтверждения записи, поведение узла при потере связи с группой, лимиты на поток изменений. Разложены по машинам и продублированы в системе контроля версий.
- Схема размещения узлов. Сколько узлов, в каких зонах доступности, как распределён кворум, какие задержки между площадками закладывали и почему именно такой состав голосующих.
- Регламент переключения. Пошаговый порядок управляемого вывода узла, действия при потере кворума, точка, в которой принимается решение о переводе трафика на резервную площадку.
- Правила доступов. Роли для приложения, служебной диагностики и восстановления, откуда разрешены подключения, кто имеет право менять параметры кластера и как это фиксируется.
- Документация по восстановлению. Сценарии холодного старта группы, подъём одного отставшего узла, порядок работы с резервной копией и сверка состояния после возврата.
- Чек-листы. Проверки перед изменением конфигурации, после аварийного переключения и регулярный контроль расхождения данных между узлами.
- Карта метрик и оповещений. Какие показатели узла и кластера считаются нормой, какие требуют вмешательства дежурного, кому уходит сигнал.
Кейс: кластер интернет-магазина без простоя при отказе узла
Как было до
Магазин работал на одной основной базе и асинхронной реплике. Когда узел уходил, реплика отставала, и часть заказов, оформленных в момент сбоя, пропадала — доля потерянных транзакций доходила до 0.3% суточного потока. О расхождениях узнавали по жалобам покупателей, то есть уже после того, как клиент не получил подтверждение заказа.
Переключение делали руками: дежурный инженер поднимал реплику, менял точку подключения в конфигурации приложения и только потом снимал режим обслуживания. Простой составлял от 4 до 11 минут, а каждый четвёртый отказ заканчивался ручной пересборкой узла из резервной копии.
Что изменили и что стало
Собрали кластер из трёх узлов с синхронной репликацией: запись подтверждается только после того, как её приняло большинство узлов, поэтому потеря заказов при отказе одного узла перестала быть возможной. Отказ отрабатывает автоматика — оставшиеся два узла сохраняют кворум, и кластер продолжает принимать записи без участия дежурного.
Время переключения сократилось с минут до 3-8 секунд, доля потерянных транзакций — с 0.3% до нуля, доля ручных восстановлений — с четверти отказов до одного из десяти, и только когда диск узла недоступен совсем. Разбор инцидента занимает около 20 минут: в журнале видно, какой узел выпал, почему и когда вернулся в строй, — раньше на сверку логов уходили часы.
Настройки мы сверяли с двумя независимыми источниками — документация Galera Cluster и отчёты сообщества по кворуму: они подтверждают, что выбранный режим даёт предсказуемый отказ, а не тихую потерю данных.
Что делать, если уже развёрнут асинхронный кластер?
Переход возможен без длительного окна недоступности: данные на репликах уже есть, меняется только способ их приёма и подтверждения записи. Порядок здесь обратный привычному — сначала вводим в синхронный кластер одну реплику, а текущий мастер продолжает работать как раньше.
Перед этим проверяем текущую конфигурацию. Все таблицы должны быть InnoDB и с первичным ключом: без ключа синхронное применение строк работает неэффективно. Смотрим, не растёт ли лаг реплики, совпадают ли схемы на узлах, нет ли прямых подключений к репликам на чтение — после переключения это уже равноправные участники кластера. Отдельно — длинные транзакции и смена структуры таблиц: они согласуются между узлами и на большой таблице могут затормозить запись.
Обратная совместимость приложений — главный риск. Асинхронная схема терпит конфликты: расхождения копятся и всплывают позже. Синхронная возвращает их сразу ошибкой транзакции, поэтому код должен уметь повторить операцию, а не упасть. Второе — точка подключения: прописанный по имени мастер меняют на адрес кластера, иначе распределение записи не заработает.
План миграции: фиксируем настройки, поднимаем новый узел рядом с репликой и переносим данные физической копией — перелив дампом создаёт то самое длинное окно. Затем переводим приложение, добавляем остальные узлы и следим за кворумом. Само окно недоступности — минуты на смену точки подключения и проверку записи с чтением. Откат простой: вернуть приложение на прежний мастер, он остаётся холодным резервом, пока кластер не отработает под нагрузкой.
Частые технические вопросы перед внедрением кластера
На этапе проектирования важно проверить не саму репликацию, а поведение кластера в нештатных сценариях: обрыв связи между площадками, добавление узла под нагрузкой, отклик записи. Ниже — пять вопросов инженерного уровня с короткими ответами.
Сколько узлов нужно для кворума?
Три — минимальный состав, при котором кластер переживает отказ одного узла и сохраняет кворум. Два узла отказоустойчивы, но без запаса: потеря одного оставляет один голос, и кластер уходит в режим только для чтения. Для двух площадок добавляем лёгкий арбитр без копии данных.
Что происходит при разделении сети?
Меньшая часть теряет кворум и переходит в режим только для чтения — запись на ней останавливается, чтобы версии данных не разошлись. Большая часть продолжает обслуживать транзакции, а после восстановления связи отставшие узлы догоняют состояние сами.
Можно ли добавить узел на ходу?
Да, остановка сервиса не нужна. Новый узел получает копию данных и включается в голосование только после догонки. На время полной передачи копии донором выступает один узел — его нагрузку заранее распределяем, чтобы не просадить отклик.
Замедляет ли синхронная репликация запись?
Отклик записи определяет задержка сети между узлами, а не диск. В пределах площадки это доли миллисекунд, между регионами — заметнее. Групповая фиксация объединяет параллельные транзакции в один раунд согласования, поэтому пропускная способность при массовой нагрузке не проседает.
Как узел восстанавливается после сбоя?
После короткого отсутствия он догоняет изменения из журнала и возвращается в строй без полной копии базы. Если отстал сильнее, чем хранится журнал, запускается полная передача. Расхождение данных между узлами ловится отдельно и требует пересборки узла.
Обсудим задачу и вернёмся с оценкой и планом
Чтобы оценка была по делу, а не «на глаз», для старта нужны исходные данные по инфраструктуре и требования к доступности. Опишите текущую схему репликации, число узлов и площадок, объёмы баз и профиль нагрузки на запись — этого достаточно, чтобы понять, какие режимы кворума и синхронизации подойдут именно вам.
- Схему текущей топологии: сколько узлов, как разнесены по площадкам, где сейчас точки отказа.
- Объёмы и характер нагрузки: размер баз, соотношение чтения и записи, пиковые периоды.
- Требования к доступности: допустимое время простоя при переключении и нужен ли автоматический переход при отказе узла.
- Требования к согласованности: какие транзакции обязаны подтверждаться на большинстве узлов, а где достаточно асинхронной репликации.
- Как устроены резервное копирование и восстановление — чтобы план работ не сломал действующие процедуры.
- Ограничения по окну работ: когда конфигурацию можно менять без влияния на пользователей.
Взамен вернёмся с планом работ по внедрению: поэтапный перевод узлов, состав кластера, порядок проверок и порядок приёмки с измеримыми критериями. Заранее фиксируем, какой отказ кластер обязан переживать и за какое время возвращается в норму после сбоя. Опишите задачу — обсудим детали и вернёмся с оценкой и планом.
