Отказ главного узла базы роняет сервис: Stolon в Kubernetes
Классическая схема с одним главным узлом PostgreSQL держится на одном допущении — что этот узел жив. Пока он отвечает, запись идёт, реплики догоняют поток. Отказ главного узла базы данных останавливает не только запись: часть чтения тоже повисает, приложение ждёт ответа, таймауты складываются, соединения копятся и упираются в лимит пула. Простой из-за базы данных измеряется в этом случае не временем падения узла, а временем, за которое кто-то успеет отреагировать.
Дальше включается ручное восстановление кластера СУБД. Дежурный поднимает узел, выясняет, какая из реплик наиболее свежая, меняет роли, правит точку входа и строку подключения, возвращает отставшую реплику в строй. Каждый шаг — решение человека под давлением, и на этом окне недоступности ошибка обходится дороже самой аварии. Если приложение успело записать данные, а новый главный стартовал с другой реплики, расхождение снимают вручную, сверяя журналы.
Именно здесь и находится точка отказа PostgreSQL в одноузловой конфигурации: вопрос не в том, упадёт ли узел, а в том, сколько мы будем подниматься и что потеряем по пути. Пока переключение делает человек, окно недоступности предсказуемо растягивается, а объём потерянных записей зависит от того, как быстро среагировал дежурный и насколько свежей оказалась выбранная реплика.
Stolon в Kubernetes снимает эту работу с людей: он держит несколько узлов базы, следит за состоянием главного, выбирает нового по свежести данных и переводит трафик через отдельную точку доступа. Приложение переподключается по тому же адресу, не дожидаясь, пока инженер вручную вернёт кластер в строй. Ниже разбираем, как это закрывается и что остаётся за пределами автоматизации.
Что даёт отказоустойчивый кластер: измеримый эффект
Отказоустойчивость начинается с честного замера того, что происходит сейчас. Один экземпляр базы с ручным подъёмом реплики даёт окно недоступности в десятки минут: инженер замечает сбой, подтверждает, что дело не в сети, поднимает узел из резервной копии, переключает трафик. Каждое такое переключение — операция под давлением, и именно на ней чаще всего ломается целостность: два узла считают себя главными, часть записи уходит в устаревшую копию.
Stolon убирает ручной шаг из этого сценария. Кластер держит кворум управляющих компонентов, состояние ролей хранится в распределённом хранилище конфигурации, а слой маршрутизации направляет подключения только на подтверждённый главный узел. Потеря ведущего узла запускает автоматическое переключение ролей: реплика повышается, маршрутизация перестраивается, приложение переподключается по тому же адресу.
В измеримых величинах эффект выглядит так: окно недоступности базы данных сокращается с десятков минут до единиц секунд, доля автоматических переключений стремится к ста процентам — и для планового обслуживания, и для внезапного отказа, а число ручных вмешательств инженера падает до нуля на типовых сценариях. Заодно уходит целый класс отказов: расхождение реплик и запись в отставший узел больше не зависят от того, успел ли кто-то нажать нужную кнопку ночью.
Доступность сервиса перестаёт быть обещанием и становится проверяемой величиной. Мы закладываем в регламент контрольные учения — управляемое отключение узла в рабочее время, — чтобы измерять время восстановления на живой системе, а не верить в расчётную оценку.
Режимы развёртывания кластера: сравнение подходов
Отказоустойчивость базы — не бинарный выбор «кластер или не кластер», а спектр схем с разной ценой внедрения и разным поведением при сбое. Ниже — варианты, между которыми реально выбирают на старте проекта, и их ограничения.
| Вариант | Когда подходит | Ограничения |
|---|---|---|
| Холодный резерв: регулярные дампы и восстановление на отдельном узле | Небольшая нагрузка, простой в несколько часов допустим | Восстановление считается часами, последние транзакции теряются безвозвратно |
| Потоковая репликация с ручным переключением | Предсказуемая нагрузка, есть дежурный инженер | Переключение зависит от человека, окно простоя растягивается на реакцию дежурного |
| Кластер под управлением Stolon в Kubernetes | Нужен автоматический отказ и самовосстановление ролей | Требует корректного кворума и дисциплины в обновлениях, отладка сложнее, чем у одиночного узла |
| Управляемый кластер СУБД у провайдера | Своей команды эксплуатации нет | Меньше контроля над версиями, расширениями и параметрами ядра, привязка к площадке |
Главное отличие — кто принимает решение о переключении. В первых двух схемах это человек, в кластере под управлением автоматики — сам сервис: он следит за состоянием узлов и меняет роли без участия оператора. Ограничения репликации при этом общие для всех вариантов: потоковая передача по умолчанию асинхронна, поэтому часть последних подтверждённых записей может не дойти до резерва, а задержка резерва напрямую влияет на время восстановления.
Выбор сводится к двум вопросам: сколько простоя вы готовы выдержать и сколько последних записей допустимо потерять. Ответы на них и определяют, нужен ли вообще автоматический отказ или достаточно холодного резерва с понятным регламентом восстановления.
Внедрение Stolon в Kubernetes: этапы инженерной работы
Отказоустойчивость кластера СУБД в Kubernetes нельзя дописать после запуска — её проектируют вместе с топологией, хранилищем и схемой подключения приложений. Ниже — последовательность работ по внедрению Stolon в Kubernetes: от аудита текущей схемы до передачи кластера в эксплуатацию с протоколом проверок.
- Аудит схемы и нагрузки. Разбираем, как приложение подключается к базе — через прокси, пул соединений или напрямую, какой профиль запросов и объёмы, где сейчас единственная точка отказа.
- Проектирование отказоустойчивой схемы. Определяем число реплик, раскладку по зонам доступности, кворум для выбора лидера, режим синхронной репликации и целевое время переключения.
- Сборка конфигурации. Разворачиваем keeper-узлы как набор с постоянными томами, sentinel для контроля состояния и перевыборов лидера, раздельные адреса для записи и чтения.
- Хранилище и резервные копии. Подбираем классы дисков, настраиваем регулярные копии в объектное хранилище и проверяем восстановление на отдельном стенде.
- Проверка отказами. Убиваем лидера, отключаем зону доступности, рвём связь с хранилищем состояния кластера — фиксируем время переключения и убеждаемся, что приложения переподключаются без ручных действий.
- Передача в эксплуатацию. Регламент дежурства, оповещения об отсутствии лидера и отставании реплик, сценарии планового обслуживания, обучение команды заказчика.
На выходе — предсказуемое время восстановления после отказа узла или зоны, отсутствие ручных переключений и понятный набор действий для дежурной смены.
Что передаём на руки: конфигурации, схемы, регламенты
Кластер, который работает, но понятен только тем, кто его собирал, — это отложенный простой. Поэтому передача на руки — не архив файлов, а комплект, по которому ваш инженер сам поднимет реплику, проведёт плановое переключение и вернётся к предыдущему состоянию без нашей помощи.
- Схема отказоустойчивости — топология и роли узлов, точки отказа, поведение кластера при потере мастера или зоны, порядок выбора нового лидера.
- Конфигурации кластера — манифесты и параметры окружений в репозитории, ресурсы и лимиты, правила размещения подов, отдельные профили для боевого и тестового контуров.
- Политики доступа к базе — роли приложений, администраторов и служебных сервисов, владение схемами, порядок выдачи и отзыва прав, ротация учётных данных, хранение секретов.
- Регламент резервного копирования — расписание полных и инкрементальных копий, глубина хранения, выгрузка за пределы кластера, проверка восстановления по расписанию.
- Документация на кластер СУБД — пошаговые сценарии на плановые операции и аварийные ситуации, порядок ручного вмешательства, границы ответственности.
- Мониторинг и оповещения — какие метрики смотрим, при каких порогах поднимается тревога и что делать в первые минуты по каждому сигналу.
Отдаём не ссылкой на репозиторий, а разбором на тестовом контуре: показываем отказ узла, переключение и восстановление из копии, затем ваши инженеры повторяют это сами. После этого у команды остаётся один источник правды по кластеру, и обращаться к нам нужно только на изменение архитектуры или расширение.
Кейс: как кластер пережил отказ узла без ручных действий
До внедрения кластер держался на одном узле-мастере: при его отказе приложение ловило ошибки подключения, а реплику поднимали вручную — инженер подключался, проверял отставание и переводил трафик. Это занимало от двадцати минут до получаса, и каждый раз оставался риск вывести в мастер реплику с незакрытым отставанием и потерять последние транзакции.
Мы развернули Stolon поверх Kubernetes: на каждом узле работает хранитель состояния, отдельные наблюдатели следят за здоровьем мастера, а точка входа для приложений перенаправляет трафик по решению кворума. Промоушен запускается сам, как только мастер перестаёт отвечать, — человек в схеме больше не участвует.
Что подтверждают метрики
Переключение укладывается в десятки секунд, ручных вмешательств за квартал — ноль, отставание реплик удерживается в границах, при которых подтверждённые транзакции не теряются. Простой при отказе узла сократился с получаса до времени, которое приложение спокойно переживает на повторах запросов.
Перед выводом в боевой контур мы прогнали сценарии в нагрузочном контуре: гасили узел с мастером, узел с наблюдателями, разрывали связь с хранилищем состояния и замеряли, сколько держится простой. Каждый прогон давал понятный предел отказоустойчивости — сколько узлов кластер переживает без потери данных и на каком сценарии всё-таки нужно вмешательство.
Что делать, если база уже развёрнута на одном узле?
Развёрнутый одиночный узел не нужно сносить и поднимать кластер с нуля — переход делается на живом сервисе. Сначала рядом поднимается реплика, которая догоняет основной узел по потоку изменений, и только после этого меняются роли. Остановка требуется лишь на момент смены точки входа, а не на всю миграцию: окно измеряется минутами, а не часами простоя.
Порядок перехода такой: снять согласованный снимок состояния и зафиксировать текущие параметры, развернуть реплику и дождаться нулевого отставания, перевести её в режим основного узла, убедиться, что прежний узел остаётся читаемым и синхронным. Последний шаг — перевод приложения на имя сервиса вместо прямого адреса конкретного пода. Такой план перехода фиксируется до начала работ, чтобы каждый шаг был проверяемым и прерываемым.
Ключевое условие бесшовности — приложение уже обращается к базе по имени сервиса, а не по прямой ссылке на узел. Тогда смена роли в Stolon в Kubernetes — это переключение на другую копию за секунды, без правок конфигурации сервиса и без его перезапуска. Если приложение всё ещё держит прямой адрес, этот момент закрывается первым — до того, как мы начнём трогать роли.
Обратный откат проектируется заранее: прежний узел остаётся в строю как резерв, снимок состояния хранится до конца периода наблюдения, а правила возврата описаны пошагово для дежурного. Если после переключения всплывают расхождения, сервис возвращается на прежний узел тем же способом — сменой роли и адреса. Мы разбираем конкретную конфигурацию и предлагаем план перехода под ваш режим работы.
Инженерные сомнения, которые снимаем до старта
Перед стартом звучит один и тот же набор вопросов: что будет с записью при расщеплении кластера, какая репликация нужна этой базе, как обновлять её без простоя, встроится ли решение в текущий контур и кто отвечает за инцидент. Отвечаем прямо, до начала работ.
Как Stolon защищает от расщепления кластера?
Мастер выбирается через консенсус-хранилище, а не «кто ответил первым». Узел, потерявший с ним связь, перестаёт быть мастером и закрывает приём записи — двух конкурирующих мастеров не возникает.
Синхронная или асинхронная репликация?
Синхронная исключает потерю подтверждённых транзакций, но привязывает запись к числу живых реплик. Асинхронная спокойнее переносит потерю узлов, зато на переключении теряются последние подтверждения. Выбор фиксируем по профилю нагрузки и допустимому окну потери.
Что с совместимостью с текущим контуром?
Сверяем версию и расширения базы, класс хранилища, сетевые доступы, мониторинг и резервное копирование. Если что-то в контуре не переживает смену роли мастера — говорим сразу, а не на выкате.
Как обслуживать кластер СУБД без остановки?
Плановое переключение, обновление мажорной версии и накат параметров идут волной: сначала реплики, затем мастер. База принимает запись всю процедуру.
Кто отвечает за поддержку после запуска?
На нашей стороне — конфигурация, автоматика переключений и схема резервирования; на стороне заказчика — доступы, ресурсы платформы и изменения приложений. Границу фиксируем письменно до старта.
Обсудим задачу: что нужно от вас и что делаем мы
Чтобы вернуться с оценкой и планом работ, а не с общими формулировками, нам нужен срез вашей инфраструктуры. По нему мы считаем состав кластера, точки отказа и сроки внедрения — и отдаём это одним документом, который можно защищать перед командой.
- текущая схема: один узел или репликация вручную, где живёт мастер, как приложения переключаются при сбое;
- состав кластера: число экземпляров базы, объём данных, суточный прирост и соотношение чтения к записи;
- платформа: версия Kubernetes, наличие нескольких зон доступности, как выдаются постоянные тома;
- сеть и доступы: как приложения находят актуальный мастер, есть ли прокси-слой, какие политики сети действуют;
- требования к отказоустойчивости: допустимое время недоступности записи и чтения, нужен ли автоматический откат;
- окна работ: когда можно переключать промышленный контур, есть ли тестовый контур и набор данных, близкий к реальному;
- наблюдаемость: куда собираются метрики и логи, какие оповещения уже настроены.
Этого достаточно, чтобы предложить конкретную схему: сколько экземпляров базы, где размещать мастер и реплики, как приложения находят новый мастер после переключения. Дальше разворачиваем Stolon и описываем порядок переноса данных без длительной остановки записи.
План работ разбит на этапы: подготовка контуров, развёртывание, перенос, отработка переключения и вывод в промышленную эксплуатацию. Для каждого этапа фиксируем, что делаем мы и что нужно от вашей команды, — и только после этого называем сроки внедрения. Опишите задачу — вернёмся с оценкой и планом.
