Автоскейлер и политики масштабирования

В SPG99 слово scale теперь важно понимать правильно. Для обычного пользователя это не ручной autoscaling в стиле “подними ещё один writer” и не горячее изменение ресурсов уже работающего pod.

Что означает масштабирование сейчас

У БД есть две разные оси runtime‑состояния.

1. Запущен writer или нет

Это отражают поля:

• current_scale
• target_scale

В текущем контракте они по сути бинарные:

• 0 — writer не запущен;
• 1 — writer запущен.

2. На каком профиле работает writer

Это отражают поля:

• current_profile
• target_profile
• candidate_profile
• scale_state

Именно здесь живёт новый autoscaler.

Как работает writer autoscaler

Текущая активная схема — это generation handoff, а не live resize.

Упрощённо она выглядит так:

current writer
  -> prepare candidate writer под новый профиль
  -> freeze new checkouts
  -> drain
  -> stop old writer
  -> promote new writer
  -> switch state
  -> cooldown

Практический смысл:

• активный writer не меняется “на месте”;
• новый профиль получает новое поколение writer;
• Gateway помогает выполнить безопасный cutover;
• WAL и session correctness сохраняются.

Что означают autoscaler‑поля

scale_state

Показывает стадию перехода. Основные значения:

• STEADY — база в обычном устойчивом состоянии;
• PREPARING — платформа готовит candidate writer;
• FREEZING — новые checkout'ы временно замораживаются;
• DRAINING — система ждёт завершения активной нагрузки;
• STOPPING_OLD — старый writer останавливается;
• STARTING_NEW — новое поколение запускается или доводится до готовности;
• SWITCHING — платформа переключает control state на новый writer;
• COOLDOWN — защитная пауза после завершения handoff;
• FAILED — переход сорвался и требует анализа.

freeze_new_checkouts

Показывает, что Gateway уже не должен выдавать новые checkout'ы на старый writer. Это нормальная часть controlled cutover.

candidate_worker_id и candidate_writer_term

Это диагностические поля подготовленного нового поколения writer.

scale_failure_reason

Если handoff не удался, именно это поле даёт лучший короткий диагноз.

Почему платформа не делает live resize

У live resize было бы слишком много рисков:

• session‑state на активных соединениях;
• гонки при смене ресурса живого writer;
• сложность correctness на write path;
• более высокий риск для production‑нагрузки.

Generation handoff медленнее на бумаге, но в реальной эксплуатации надёжнее, прозрачнее и проще диагностируется.

Что блокирует бесшовный cutover

Самый важный ограничитель — pinned/session traffic.

Если workload держит:

• named prepared statements;
• temp tables;
• LISTEN/UNLISTEN;
• SET/session‑state;
• долгие session‑зависимые соединения,

то платформа не должна делать агрессивный handoff “через голову” такого трафика. В этом случае cutover откладывается или отменяется до безопасного окна.

Что делать пользователю

• Для обычной работы используйте Gateway как единую точку входа.
• Смотрите не только на state, но и на scale_state.
• Не стройте workflow вокруг ручного POST /scale.
• Для гладкого autoscale‑handoff минимизируйте без необходимости session‑heavy паттерны.
• Помните, что текущий active handoff‑контракт работает для профилей L1/L2.

Практический вывод

В SPG99 масштабирование writer — это уже не “крутилка 0/1”, а управляемый безопасный handoff между поколениями compute. Для пользователя это означает более надёжное поведение под нагрузкой, лучшую предсказуемость и понятную диагностику.