Vous pouvez surveiller l’utilisation du CPU, de la mémoire, des IOPS et du stockage directement dans la console ClickHouse Cloud, dans l’onglet Monitoring de votre instance Managed Postgres.
De plus, vous pouvez consulter Query Performance Insights pour obtenir une analyse détaillée de vos requêtes dans l’onglet Query Insights.
Sauvegarde et restauration
Quelles options de sauvegarde sont disponibles ?
Infrastructure et automatisation
Extensions et configuration
Quelles extensions sont prises en charge ?
Puis-je personnaliser les paramètres de configuration de PostgreSQL ?
Si vous avez besoin d’un paramètre qui n’est pas disponible pour le moment, contactez le support pour en faire la demande. Pourquoi est-ce que je vois des erreurs prepared statement does not exist avec PgBouncer ?
PREPARE (ou le Parse de la requête étendue). Lorsque l’EXECUTE correspondant est envoyé à un autre backend, vous obtenez des erreurs comme :
ERROR: prepared statement "..." does not exist
ERROR: unnamed prepared statement does not exist
- Des rafales d’erreurs
prepared statement does not exist, en particulier pendant les backfills ou les écritures à forte concurrence
- Des insertions qui semblent « échouer silencieusement » — l’instruction renvoie une erreur, le driver réessaie, et un batch peut se retrouver partiellement appliqué ou abandonné
- Des valeurs renvoyées avec le mauvais type (par exemple, une colonne
BIGINT décodée comme un motif de bits float64) — cela se produit lorsqu’un plan côté client mis en cache réutilise des codes de type/format obsolètes sur un backend qui n’a jamais reçu le Parse correspondant
Correctif : désactivez les prepared statements côté serveur dans votre driver. Le réglage exact dépend de votre bibliothèque cliente :
| Pilote | Paramètre |
|---|
| pgx (Go) | statement_cache_capacity=0 et default_query_exec_mode=exec (ou simple_protocol) |
| psycopg3 (Python) | prepare_threshold=None |
| asyncpg (Python) | statement_cache_size=0 |
| JDBC (Java) | prepareThreshold=0 |
| node-postgres / pg (Node.js) | Ne passez pas de name à query() (les requêtes nommées deviennent alors préparées côté serveur) |
- Postgres
max_connections fixe le nombre maximal de connexions backend à PostgreSQL lui-même. C’est la limite la plus coûteuse : chaque backend consomme de la mémoire et un slot de processus.
- PgBouncer
max_client_conn fixe le nombre maximal de connexions client pouvant être ouvertes simultanément dans le pooler. PgBouncer multiplexe ce grand nombre de connexions client sur un ensemble bien plus réduit de connexions backend.
Une instance Managed Postgres typique est configurée pour que PgBouncer accepte environ 10× plus de connexions client que de backends Postgres (par ex. 5 000 clients / 500 backends). Si vous voyez des erreurs de connexion au niveau du pooler, il est bien plus probable que vous atteigniez une limite backend par pool (default_pool_size) plutôt que la limite client globale.
Fonctionnalités de la base de données
Puis-je créer plusieurs bases de données et schémas ?
Le contrôle d’accès basé sur les rôles (RBAC) est-il pris en charge ?
Des fonctionnalités RBAC avancées avec intégration à la Console sont prévues cette année.
- pg_dump and pg_restore : pour les bases de données de petite taille ou les migrations ponctuelles. Consultez le guide pg_dump and pg_restore.
- réplication logique : pour les bases de données plus volumineuses nécessitant un minimum d’indisponibilité. Consultez le guide réplication logique.
- PeerDB : pour la réplication basée sur le CDC à partir d’autres sources Postgres. Consultez le guide migration avec PeerDB.
Une expérience de migration entièrement gérée sera bientôt disponible.
