Как работает SPG99: поток обработки запросов

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

Пошаговый путь

1. Клиент подключается к Gateway по обычному PostgreSQL DSN и передаёт pg_user / pg_password.
2. Gateway понимает, к какому tenant и какой базе относится подключение.
3. Gateway обращается в Control Plane за lease и проверяет, есть ли уже активный writer.
4. Если база находится в stopped, Control Plane инициирует её запуск через Provisioner.
5. Provisioner поднимает или назначает новый compute‑pod.
6. Compute получает runtime‑контракт: tenant, db, timeline, writer term, профиль compute, адрес Pageserver и список Safekeeper.
7. Compute запрашивает у Pageserver soft basebackup — тонкий startup‑образ для запуска PostgreSQL.
8. Pageserver подготавливает стартовый минимум: системные каталоги, relmap, служебное состояние и sparse placeholders вместо полного локального набора пользовательских relation files.
9. Compute запускает PostgreSQL, а пользовательские relation pages при необходимости подтягиваются лениво через Pageserver на local miss.
10. Перед выходом в ready Compute проверяет критичные storage‑зависимости, в том числе WAL quorum.
11. Gateway получает адрес backend‑а и переключает клиентское соединение на уже поднятый PostgreSQL.

Что происходит дальше

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

• Gateway удерживает lease;
• lease регулярно продлевается;
• Control Plane не считает базу безопасной для idle‑stop.

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

• lease освобождается;
• база становится кандидатом на auto‑stop;
• Control Plane переводит compute в неактивное состояние.

Как здесь участвует автоскейлер

Если платформа решает сменить профиль writer, путь уже другой. Она не меняет живой pod “на месте”, а делает controlled handoff:

prepare candidate -> freeze new checkouts -> drain -> stop old -> promote new -> unfreeze

Это особенно важно для production‑нагрузки:

• данные и writer term остаются согласованными;
• Gateway знает, когда нельзя брать новые checkout'ы;
• long‑lived pinned/session трафик не режется без контроля.

Что важно понимать пользователю

• с точки зрения клиента всё выглядит как обычное подключение к PostgreSQL;
• реальная orchestration‑логика спрятана внутри платформы;
• первое подключение к sleeping‑базе может быть немного медленнее;
• durable‑состояние базы не привязано к жизни одного worker;
• при масштабировании writer меняется поколение compute, а не только одна цифра в UI.

Почему это удобно

Такая цепочка даёт хороший компромисс между стоимостью и скоростью:

• compute не держится включённым без нагрузки;
• пользователь не управляет worker‑ами вручную;
• soft basebackup ускоряет cold start;
• storage‑контур обеспечивает надёжность независимо от конкретного compute‑инстанса.