Compute: обзор

Compute — это рабочий исполнительный слой PostgreSQL в SPG99. Именно он поднимает PostgreSQL, принимает клиентские подключения через Gateway и исполняет SQL‑запросы.

Главное в текущей модели сервиса: Compute — это не “вечный pod с полным набором пользовательских файлов на локальном диске”. В SPG99 он выступает как управляемый вычислительный слой над отказоустойчивым storage‑контуром.

Что входит в Compute

Внутри Compute находятся:

• PostgreSQL 17;
• расширение spg99;
• агент управления, который подготавливает bootstrap, TLS, managed‑config, readiness и связь с control plane.

Что изменилось в новой модели

Раньше пользователю было проще думать о compute как о worker, который при старте подтягивает “почти всю базу”. Теперь контракт точнее:

• PGDATA на compute — ephemeral;
• локальный диск — write‑back cache;
• durable‑состояние живёт в Pageserver + Safekeeper + object storage;
• запуск идёт через soft basebackup;
• локально остаётся только стартовый минимум для быстрого запуска PostgreSQL.

Это значит, что на поде теперь нет лишнего пользовательского дискового слоя “на всякий случай”. База стартует быстрее, а локальный диск работает именно как быстрый operational cache.

Роль Compute в цепочке SPG99

Упрощённо рабочий путь выглядит так:

Приложение / psql
    -> Gateway
    -> Control Plane
    -> Provisioner
    -> Compute
    -> Pageserver + 3 Safekeeper

Роли сервисов в этой цепочке такие:

• Console — показывает статусы БД, DSN, логи, метрики и доступные действия.
• Gateway — единая PostgreSQL‑точка входа и встроенный pooler.
• Control Plane — управляет lifecycle и autoscaler‑состоянием.
• Provisioner — поднимает compute‑pod.
• Compute — запускает PostgreSQL, обслуживает SQL, использует local cache, пишет WAL в Safekeeper и читает данные через Pageserver.
• Pageserver — источник soft basebackup и remote read‑through.
• Safekeeper — контур надёжности WAL.

Как проходит обычный запуск

Жизненный цикл Compute в нормальном сценарии выглядит так:

1. Пользователь создаёт БД или подключается к уже созданной БД.
2. Control Plane понимает, что для БД нужен активный writer.
3. Provisioner поднимает или назначает compute‑воркер.
4. Compute получает soft basebackup и конфигурацию.
5. PostgreSQL выходит в ready.
6. Gateway передаёт клиентское соединение в готовый backend.

Как Compute участвует в autoscaler

В новой модели profile autoscaler не делает live resize уже работающего writer. Вместо этого:

• запускается candidate generation под новый профиль;
• candidate может быть подготовлен в prepare_only режиме;
• платформа ждёт безопасное окно;
• Gateway замораживает новые checkout'ы и помогает выполнить drain;
• writer handoff завершается только после promote нового поколения.

Для пользователя это означает:

• профиль writer меняется безопасно;
• система не рискует session‑state и WAL‑корректностью ради “горячего resize”;
• важнее смотреть на current_profile, target_profile и scale_state, чем на старое понимание “scale как число pod’ов”.

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

• Состояние stopped — это нормальная часть serverless‑модели, а не авария.
• Первое подключение после простоя может занять больше времени из‑за cold start.
• Локальный диск Compute нужен для скорости, но не является единственным источником надёжности.
• Правильная точка входа для приложения — Gateway, а не прямой адрес worker/pod.
• При переходе между профилями writer платформа создаёт новое поколение compute, а не “растягивает” старое.