Endpoints

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

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). Définissez suspend_after_seconds à la création pour la remplacer ; 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. La latence de démarrage à froid est typiquement de 300–500 ms une fois que le cluster dispose du cache pageserver chaud ; 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=require

Le 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

keon endpoints create --branch <branch-id> --type rw

Drapeaux facultatifs :

• --suspend-after-seconds <n> pour remplacer la fenêtre de suspension par défaut.
• --type ro pour un endpoint en lecture seule.

La 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.