Жизненный цикл БД и auto-start

В SPG99 база данных живёт в serverless‑модели: логическая БД и durable storage существуют постоянно, а compute запускается только тогда, когда он действительно нужен.

Что происходит сразу после создания

Новая база создаётся как запись в каталоге и как storage‑сущность для timeline. При этом постоянно работающий writer не поднимается автоматически.

Это даёт два преимущества:

• база создаётся быстрее;
• платформа не тратит compute без реальной нагрузки.

Первое подключение

Когда клиент впервые подключается к остановленной базе:

1. клиент приходит в Gateway;
2. Gateway обращается в Control Plane за lease;
3. если база ещё не активна, Control Plane координирует запуск через Provisioner;
4. Compute получает soft basebackup от Pageserver и поднимает PostgreSQL;
5. Gateway маршрутизирует клиентское соединение на уже готовый backend.

Поэтому первое подключение к sleeping‑базе обычно медленнее, чем к уже прогретой. Это нормальный cold start.

Активная работа

Пока база используется:

• Gateway удерживает lease;
• lease продлевается;
• Control Plane видит, что база активна, и не останавливает её.

Idle и auto-stop

Когда активность заканчивается:

• активные lease завершаются;
• база становится кандидатом на auto‑stop;
• Control Plane останавливает writer.

Важно: это нормальное рабочее поведение, а не ошибка. Durable‑состояние базы не теряется, потому что надёжность SPG99 опирается на storage‑цепочку, а не на локальный диск compute.

Новый autoscaler в жизненном цикле базы

Теперь Control Plane отвечает не только за create/start/stop/delete, но и за profile handoff активного writer.

Это выглядит так:

• определяется необходимость перехода между профилями;
• создаётся candidate writer generation;
• Gateway получает freeze_new_checkouts;
• система ждёт drain активной нагрузки;
• старый writer останавливается;
• новый writer получает promote;
• каталог и control state переключаются на новое поколение;
• включается cooldown.

Важный момент: это не live resize уже работающего pod, а безопасная смена поколения writer.

Что ограничивает бесшовный handoff

Платформа не должна делать агрессивное переключение, если есть session‑heavy трафик:

• pinned sessions;
• долгие транзакции;
• idle in transaction;
• другие признаки, что старый writer ещё нельзя безопасно снять.

Поэтому handoff может быть отложен до более безопасного окна.

Состояния базы

На практике чаще всего встречаются такие значения state:

• creating — каталог и storage ещё подготавливаются;
• booting — writer стартует;
• ready — база готова принимать подключения;
• stopping — идёт остановка writer;
• stopped — writer выключен, следующее подключение может снова разбудить базу;
• deleting — идёт удаление;
• error — произошла ошибка, нужен разбор логов и мониторинга.

Дополнительно теперь полезно смотреть scale_state, если вы хотите понять, идёт ли autoscale‑handoff.

Что означают current_scale и target_scale

В текущей writer‑модели SPG99 эти поля по сути бинарные:

• 0 — writer остановлен;
• 1 — writer запущен.

Для профиля writer стали важнее другие поля:

• current_profile
• target_profile
• candidate_profile
• scale_state
• freeze_new_checkouts

Важный нюанс: ручной start/stop/scale отключён

В коде Control Plane есть маршруты start, stop и scale, но в текущем публичном пользовательском сценарии они намеренно отключены. Практический вывод очень простой:

создать базу -> подключиться -> платформа сама её поднимет -> после простоя сама остановит

А если нужен другой профиль writer, платформа теперь сама выполняет controlled handoff между поколениями compute.