MySQL InnoDB Cluster: автоматический failover с Shell и Router

MySQL InnoDB Cluster: где ломается автоматический failover

MySQL InnoDB Cluster держит запись на одном узле-мастере, остальные получают изменения потоком репликации. Пока все узлы в строю, схема работает незаметно: отказ реплики приложение вообще не замечает, а отказ мастера должен закрываться переключением за секунды. Дыра открывается там, где переключение не запускается — и запись встаёт целиком.

Решение о смене мастера принимает большинство узлов, а не отдельный управляющий процесс. Если узел перестал отвечать из-за сети, зависшего диска или упавшей службы, оставшиеся два сохраняют большинство и выбирают нового мастера — приложение продолжает писать. Но стоит потерять кворум, например при отказе двух узлов из трёх или разрыве связи между площадками, как группа переводит все узлы в режим только для чтения. Автоматический переход не срабатывает не потому, что сломан, а потому что подтвердить его некому.

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

Разбираем, как это закрывается: какие проверки ловят потерю кворума раньше дежурного, как настраивается переключение без ручного вмешательства и что нужно приложению, чтобы переждать смену мастера без простоя.

Что даёт автоматическое переключение: измеримый эффект

Автоматическое переключение внедряют не ради «база сама поднимется», а ради предсказуемого времени простоя и понятного списка инцидентов, которые дежурный вообще не увидит. Ниже — четыре эффекта, которые видно в мониторинге уже через неделю работы кластера InnoDB.

Время восстановления после отказа: минуты ручной работы против секунд

Узлы замечают недоступность ведущего за считанные секунды и передают роль кандидату по консенсусу большинства. Приложение в этот момент переподключается через Router, который держит актуальную карту кластера, — запись возобновляется без участия человека. Ручной сценарий с диагностикой, выбором узла-кандидата и правкой строки подключения занимает от четверти часа и больше.

Доля автоматических переключений

Порядка 90-95% отказов одиночного узла и ведущего закрываются сами: кластер остаётся в рабочем режиме, а команда узнаёт о событии из уведомления. Остаётся узкая группа случаев — потеря кворума и сетевые разделения, где автоматика обязана остановить запись, — и решение там принимает инженер, а не таймер.

Предсказуемость отказов и кворум узлов

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

Окно плановых работ

Обновление и обслуживание идут по узлам поочерёдно: пока один выведен, остальные держат кворум и обслуживают нагрузку. Плановые работы перестают означать остановку записи — приложение продолжает работать в обычном режиме.

Схемы отказоустойчивости MySQL: одна площадка, два ЦОДа, облако

Схема отказоустойчивости MySQL определяется не только режимом репликации, но и тем, как узлы разложены по площадкам. Кластер из трёх узлов в одной стойке спокойно переживает отказ сервера и полностью ложится при потере стойки. Причина — кворум: групповая репликация подтверждает транзакцию на большинстве узлов, и если это большинство живёт в одной точке отказа, схема защищает только от локальных сбоев.

Поэтому варианты размещения сравниваем по трём вопросам: сколько одновременных отказов схема переживает, сколько занимает автоматическое переключение и насколько синхронный режим удорожает запись. Ниже — реальные альтернативы, между которыми выбирают при проектировании MySQL InnoDB Cluster.

На одной площадке разумный предел — отказ узла или обслуживание. Две площадки закрывают аварию ЦОДа, но требуют канала с малой задержкой и третьей точки для кворума. Облачная раскладка по зонам снимает вопрос своего железа, зато добавляет зависимость от межзонального трафика.

Порядок внедрения: от аудита топологии до передачи в эксплуатацию

Порядок работ выстроен так, чтобы ни один шаг не выполнялся «на живом» без пути отката. Начинаем с аудита и заканчиваем передачей в эксплуатацию с обучением дежурной смены — между этими точками каждый этап подтверждается результатом проверки, а не отчётом о выполнении.

1. Аудит топологии. Снимаем карту серверов, версии, состояние репликации, объёмы и профиль нагрузки. Фиксируем текущие точки отказа и выясняем, какие узлы вообще способны принять роль первичного без потери данных.
2. Проектирование схемы кластера. Определяем число узлов и кворум, размещение по зонам доступности, режим согласования записи и поведение при потере связи между площадками. Здесь же решаем, где размещать Router и как распределять читающую нагрузку.
3. Подготовка и перенос данных. Переводим данные в согласованный формат, восстанавливаем на новых узлах, сверяем контрольные суммы по таблицам. Расхождения устраняются до включения кластера, а не после.
4. Настройка переключения. Задаём пороги отказа, приоритеты узлов, таймауты и политику возврата прежнего первичного узла. Отдельно описываем, что происходит с приложением в момент смены лидера.
5. Проверка сценариев отказа. По очереди выводим из строя первичный узел, реплику, Router и целую зону — замеряем время восстановления записи и полноту данных после возврата в строй. Сценарий повторяется, пока результат не станет предсказуемым.
6. Передача в эксплуатацию. Отдаём схемы, политики, регламент резервного копирования и восстановления, чек-лист дежурного. Обучаем смену: как читать состояние кластера, что делать при потере кворума и когда эскалировать.

Конфигурации, схемы и регламенты: комплект при передаче

Кластер остаётся работоспособным только тогда, когда его обслуживает команда, понимающая логику выбора первичного узла. Поэтому вместе с работающей инсталляцией мы отдаём комплект документов и настроек, по которому ваш дежурный инженер сможет поднять кластер с нуля, ввести узел обратно после сбоя и подтвердить переключение — без обращения к нам за каждым шагом.

• Конфигурация кластера — файлы настроек каждого узла с пояснениями: параметры репликации, пороги срабатывания при потере связи, приоритет узлов при выборах нового первичного и почему выбраны именно эти значения.
• Схема сети и портов — какие порты обслуживают групповую репликацию и MySQL Router, как разведены адреса между узлами и клиентами, где узкие места и единые точки отказа.
• Политики доступа и роли — разделение привилегий между администратором и сервисной учётной записью Router, порядок выдачи и смены паролей, что запрещено делать напрямую на первичном узле.
• Регламент переключения — пошаговый сценарий на случай отказа первичного узла: как проверить статус группы, когда ждать автоматического выбора нового лидера, а когда переключение делается вручную и кто его подтверждает.
• Инструкция по восстановлению — возврат узла после сбоя, пересборка из резервной копии, проверка отставания и консистентности перед вводом обратно в кластер.
• Регламент дежурства — какие события и метрики считать инцидентом, кому эскалировать, что делать в первые минуты и в каком порядке.
• Карта размещения — на каком сервере живёт какой узел, где Router, какие зоны отказа переживает схема при потере одного размещения.

Кейс: переключение без потери транзакций на трёх узлах

Ситуация до: ручное восстановление и потеря транзакций

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

Что изменили

Включили групповую репликацию с подтверждением на большинстве узлов и развели роли: запись идёт только через первичный узел, выбранный большинством, чтение распределяется по репликам. Маршрутизацию отдали Router с политикой «только первичный узел», оркестрацию — Shell: повышение узла, выход из разделения сети и принудительное переключение при потере кворума идут по регламенту, а не по памяти дежурного.

Метрики до и после

• Автоматическое переключение: 20–40 секунд вместо 30–60 минут ручного восстановления.
• Потеря подтверждённых транзакций: ноль вместо части незавершённых операций при каждом сбое.
• Разделение сети: меньшинство узлов перестаёт принимать запись, двойной первичный узел исключён.
• Учения: плановое отключение узла, дежурный видит результат переключения, а не ищет его в логах.

Отказоустойчивость выросла без расширения парка серверов: те же три узла теперь переживают потерю одного из них без остановки записи.

Что делать, если база уже развёрнута, а переключение делают вручную?

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

Технически порядок такой: на действующем сервере включают GTID и построчный формат журнала, готовят две-три реплики с идентичной конфигурацией, сверяют контрольные суммы, и только затем переводят их в режим групповой репликации. Обязательное условие — первичные ключи на всех таблицах: без них построчное копирование упирается в полные сканирования, а отставание реплик растёт и не отыгрывается. Заодно становятся явными роли узлов: один принимает запись, остальные отдают чтение и служат кандидатами на повышение.

Дальше приложение перестаёт ходить на конкретный хост и подключается через Router к группе целиком. Этот шаг и убирает ручные операции дежурного — переключение при отказе, поиск актуального узла записи, правку строки подключения после аварии. Новый лидер выбирается автоматически по большинству голосов, а Router за считаные секунды перенаправляет трафик на него.

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

Частые технические сомнения: отвечаем по существу

Сомнения инженеров редко касаются самого переключения — оно работает. Вопросы обычно про нештатные режимы: как считается кворум, что произойдёт при потере связи между площадками и выдержит ли приложение смену ведущего узла. Разбираем по существу.

Как кластер ведёт себя при потере связи между площадками?

Запись продолжает принимать только та сторона, где сохранилось большинство; меньшая часть блокирует запись и не пытается «договориться». При восстановлении канала отставшие узлы не сливаются вручную — они догоняют журнал изменений или пересобираются из полного снапшота. Поэтому узлы размещают по площадкам так, чтобы большинство не зависело от одного канала связи.

Нужно ли переделывать приложение?

Да, но точечно. Подключение идёт через MySQL InnoDB Cluster в связке с Router — приложение не знает адресов конкретных узлов и должно корректно переподключаться при смене ведущего. Запись направляется только на ведущий узел, чтение — на вторичные; собственные схемы репликации в коде убираем. Отдельно проверяем долгие транзакции, которые удерживают соединение и мешают переключению.

Как совместить резервное копирование и плановое обслуживание?

Копии снимаем с вторичного узла — ведущий не получает лишней нагрузки, а восстановление обязательно проверяем на отдельном стенде, иначе копия остаётся непроверенной. Плановые работы идут через ручное переключение роли: узел выводят из группы, обновляют и возвращают, после чего он сам догоняет изменения.

Обсудим вашу задачу: что уточнить перед стартом

Чтобы оценка была предметной, а план — выполнимым, нам нужно понять текущий контур базы и требования к отказоустойчивости. Опишите задачу в свободной форме, а мы вернёмся с оценкой и планом работ: составом этапов, сроками и перечнем проверок, которые подтвердят, что автоматическое переключение действительно работает. Для точной оценки обычно достаточно ответов на несколько вопросов.

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

Если часть данных пока неизвестна, это не блокирует старт: обсудим задачу, зафиксируем допущения и уточним их на этапе обследования. Возвращаемся с оценкой и планом работ, где явно указаны состав, сроки и точки контроля результата.