Endpoints
Frontends Postgres à suspension à l'inactivité — types, cycle de vie et sémantique de réveil.
Un endpoint est le processus Postgres qui accepte les connexions client. Les endpoints sont éphémères : ils se suspendent à l'inactivité, se réveillent au premier paquet, et fonctionnent sur la couche de stockage séparée du projet. Ne payez que pour les secondes pendant lesquelles le compute tourne réellement.
Types
| Type | Écritures ? | Quand l'utiliser |
|---|---|---|
rw | Oui | Le défaut — chaque nouvelle branche en reçoit un automatiquement. Trafic app, migrations, tout ce qui mute. Un endpoint rw par branche suffit largement pour les charges de travail typiques. |
ro | Non | Réplicas de lecture. Plusieurs endpoints ro peuvent s'attacher à la même branche et partager le stockage ; leurs caches locaux restent indépendants. À utiliser pour isoler le trafic analytique du trafic app. |
Les deux types s'attachent à exactement une branche. Un endpoint ne peut pas être déplacé vers une autre branche ; créez plutôt un nouvel endpoint sur la branche cible.
Suspension à l'inactivité
Les endpoints se suspendent après une fenêtre configurable sans activité client.
La valeur par défaut est de 300 secondes (5 minutes). Modifiez-la avec
keon endpoints update <endpoint-id> --suspend-timeout <seconds> :
0 signifie ne jamais suspendre ; toute autre valeur doit être comprise entre 60 et 3600.
Via l'API, suspend_after_seconds sur POST /v1/branches/{branchId}/endpoints
la fixe à la création. La nouvelle fenêtre prend effet lors de la prochaine
période d'inactivité de l'endpoint.
Pendant la suspension :
- Le pod de compute a disparu. Aucun CPU, aucune mémoire facturés.
- Le stockage n'est pas affecté — vos données sont durables dans le pageserver.
- L'id d'endpoint et la chaîne de connexion restent valides.
Réveil
Envoyer un paquet à un endpoint suspendu le réveille. Un réveil qui s'attache à un compute préchauffé est généralement prêt en moins de 2 secondes ; le tout premier réveil après une longue inactivité (ou après un projet neuf) peut prendre 10–30 secondes pendant que le cache de pages du pageserver se réchauffe. Les pilotes Postgres standard ne voient pas cela comme un délai dépassé dans les configurations typiques — voir Dépannage si c'est votre cas.
Les réveils de routine sont rapides parce que la plateforme maintient un pool de compute préchauffé en avance sur la demande : un réveil s'attache généralement à un compute déjà en fonctionnement plutôt que de le démarrer de zéro. Vous ne gérez ni ne payez le pool — il n'affecte que la vitesse à laquelle votre endpoint revient.
Machine à états
Un endpoint transite par :
Pending → Starting → Running → Stopping → Stopped → (Failed)- Pending — le plan de contrôle a accepté la requête de création et planifie le pod de compute. Si vous voyez un endpoint bloqué ici pendant plus de quelques secondes, voir Dépannage.
- Starting — le pod de compute est levé ; Postgres s'initialise et rejoue le WAL jusqu'au HEAD de la branche.
- Running — accepte les connexions client.
- Stopping — la fenêtre d'inactivité s'est écoulée ; drainage des connexions et purge de l'état local.
- Stopped — suspendu. En attente du prochain paquet pour se réveiller.
- Failed — erreur terminale. La carte de l'endpoint fait remonter la raison ; rare, mais arrive lorsque la planification échoue ou que l'image de compute ne peut pas démarrer.
URI de connexion
Le format filaire est documenté dans Chaînes de connexion :
postgresql://<role>:<pwd>@<endpoint_id>.<region>.kisenon.com:5432/<database>?sslmode=requireLe nom d'hôte est dérivé de l'id de l'endpoint, pas de l'id du projet — chaque endpoint termine TLS indépendamment. TLS est requis.
Le même endpoint répond aussi sur
<endpoint_id>-pooler.<region>.kisenon.com pour les connexions regroupées
par transaction (activées par défaut) — voir
Chaînes de connexion pour les compromis regroupé-vs-direct.
Créer
Chaque nouvelle branche reçoit automatiquement un endpoint rw. Pour en ajouter un autre :
keon branches add-compute <branch-id>Drapeaux facultatifs :
--type ro|rw—ro(lecture seule) par défaut.rwremplace l'endpoint principal en lecture-écriture de la branche.--min-cu <cu>/--max-cu <cu>— la fenêtre d'autoscaling.--max-cune peut être défini qu'ici ; il est fixe pour toute la vie de l'endpoint.
Pour modifier ensuite la fenêtre de suspension :
keon endpoints update <endpoint-id> --suspend-timeout 600La CLI renvoie l'id de l'endpoint et la chaîne de connexion. L'
endpoint est Running et prêt à accepter des connexions dans les quelques
secondes qui suivent le retour de l'appel.
Supprimer
keon endpoints delete <endpoint-id>Les connexions client ouvertes sont abandonnées. L'id de l'endpoint est retiré et son nom d'hôte DNS cesse de se résoudre. La branche et ses données ne sont pas affectées.
Voir aussi
- Branches — ce à quoi un endpoint s'attache.
- Chaînes de connexion — détail du format filaire.
- Dépannage — états bloqués, délais de démarrage à froid et compagnie.