Skip to main content
ClickHouse Managed Postgres offre des options de mise à l’échelle flexibles pour s’adapter aux exigences de votre charge de travail. Avec plus de 50 types d’instance basés sur NVMe au choix, vous pouvez faire évoluer indépendamment le CPU, la mémoire et le stockage afin d’optimiser les performances et les coûts pour votre use case spécifique.

​
Types d’instance et flexibilité

ClickHouse Managed Postgres offre un large éventail de types d’instance, chacun optimisé pour différents profils de charge de travail :
  • Plus de 50 types d’instance disponibles, avec des configurations optimisées pour la puissance de calcul, la mémoire et le stockage
  • Stockage basé sur NVMe sur tous les types d’instance pour des E/S disque stables et hautes performances
  • Mise à l’échelle indépendante des ressources : choisissez le bon équilibre entre CPU, mémoire et stockage en fonction de votre charge de travail

​
Choisir le bon type d’instance

Différents types de charges de travail tirent parti de configurations de ressources différentes :
Pour des raisons de sécurité, il se peut que vous ne puissiez pas basculer vers des types d’instance dont le stockage est proche de votre capacité de stockage actuellement utilisée. Choisissez toujours des types d’instance offrant une marge de capacité par rapport à votre utilisation actuelle afin d’éviter tout problème.

​
Fonctionnement de la mise à l’échelle

Lorsque vous changez de type d’instance, ClickHouse Managed Postgres effectue une mise à l’échelle verticale qui alloue une nouvelle infrastructure et migre votre base de données avec un minimum d’indisponibilité.

​
Processus de mise à l’échelle

Le workflow de mise à l’échelle met en service une nouvelle instance de secours à partir de sauvegardes et effectue un basculement contrôlé :
  1. Provisionnement de l’instance de secours : une nouvelle instance de secours est créée avec le type d’instance cible (CPU, mémoire et configuration du stockage)
  2. Restauration à partir des sauvegardes S3 : l’instance de secours est initialisée en restaurant la sauvegarde la plus récente stockée dans S3
  3. WAL replay en parallèle : l’instance de secours applique toutes les modifications du Write-Ahead Log (WAL) depuis la sauvegarde à l’aide de mécanismes de restauration parallèles fournis par WAL-G
    • WAL-G permet des restore operations rapides et parallélisées
    • Le créateur de WAL-G fait partie de l’équipe Ubicloud, avec laquelle nous avons noué un partenariat, ce qui garantit une expertise approfondie et une optimisation poussée
  4. Rattrapage de la réplication : l’instance de secours rattrape l’instance primaire en transmettant en continu et en appliquant les modifications WAL en cours
  5. Basculement : une fois l’instance de secours entièrement synchronisée, un basculement contrôlé la promeut au rang de nouvelle instance primaire
    • C’est la seule étape qui entraîne une indisponibilité (~30 secondes)
    • Toutes les connexions actives sont interrompues pendant le basculement
    • Les clients doivent se reconnecter une fois le basculement terminé
  6. Mise hors service de l’ancienne instance : l’instance d’origine est mise hors service une fois le basculement terminé

​
Durée de la mise à l’échelle

Le temps total requis pour la mise à l’échelle dépend principalement de la taille de votre base de données et du volume de données WAL à rejouer à partir des sauvegardes :
  • Restauration de la sauvegarde : temps nécessaire pour restaurer la sauvegarde complète la plus récente depuis S3 vers la nouvelle instance
  • WAL replay : temps nécessaire pour rejouer les modifications WAL incrémentielles depuis la dernière sauvegarde complète
  • Restauration parallèle : les mécanismes de restauration parallèle de WAL-G accélèrent considérablement le processus
Le temps de restauration peut varier de quelques minutes à quelques heures, mais la durée de maintenance ou d’indisponibilité reste très faible (environ 30 secondes seulement).
Indisponibilité minimaleVotre application subira environ 30 secondes d’indisponibilité pendant le basculement, quelle que soit la durée totale du processus de mise à l’échelle. Toutes les opérations de restauration et de rattrapage s’effectuent en arrière-plan sur l’instance de secours.

​
Restauration parallèle avec WAL-G

ClickHouse Managed Postgres utilise WAL-G pour accélérer la restauration des sauvegardes lors des opérations de mise à l’échelle. À noter que le créateur de WAL-G fait partie de l’équipe Ubicloud, avec laquelle nous avons noué un partenariat, apportant une solide expertise au processus de restauration. WAL-G offre :
  • Téléchargement et décompression en parallèle : plusieurs segments de sauvegarde sont récupérés depuis S3 et décompressés simultanément
  • WAL replay efficace : les changements incrémentaux du WAL sont appliqués en parallèle lorsque c’est possible
  • Streaming optimisé : streaming direct depuis le stockage S3, sans copies intermédiaires
  • Restauration rapide : bien que la durée totale dépende du volume de données, l’approche parallélisée rend le processus particulièrement rapide
Ces optimisations réduisent considérablement le temps nécessaire pour mettre en service la nouvelle instance de secours. Plus important encore, la restauration s’effectue entièrement en arrière-plan — votre application ne subit une indisponibilité que pendant la brève fenêtre de basculement d’environ 30 secondes.

​
Démarrer une opération de mise à l’échelle

Pour mettre à l’échelle votre instance ClickHouse Managed Postgres :
  1. Accédez à l’onglet Paramètres de votre instance
  2. Dans la section Mise à l’échelle, faites défiler jusqu’à Taille du service
  3. Sélectionnez le type d’instance cible
  4. Vérifiez les modifications, puis cliquez sur “Appliquer les modifications”

​
Stratégies de mise à l’échelle

​
Mise à l’échelle verticale

La mise à l’échelle verticale (changement de type d’instance) est la principale méthode pour ajuster les ressources de ClickHouse Managed Postgres. Cette approche offre :
  • Contrôle précis : choisissez parmi plus de 50 types d’instance pour ajuster finement le CPU, la mémoire et le stockage
  • Optimisation de la charge de travail : sélectionnez des configurations optimisées pour votre charge de travail spécifique (à forte intensité de calcul, de mémoire ou de stockage)
  • Maîtrise des coûts : payez uniquement pour les ressources dont vous avez besoin, sans surprovisionnement

​
Répliques de lecture pour la mise à l’échelle horizontale

Pour les charges de travail à forte dominante de lecture, envisagez d’utiliser des répliques de lecture afin d’augmenter horizontalement la capacité de lecture :
  • Déchargez les requêtes de lecture sur des instances de réplique de lecture dédiées
  • Chaque réplique de lecture est une instance Postgres entièrement indépendante, avec ses propres ressources de calcul et sa propre mémoire
  • Les répliques de lecture transmettent les modifications du WAL depuis le stockage objet pour assurer une réplication efficace
Cette approche est idéale pour les applications présentant un ratio lecture/écriture élevé, comme les tableaux de bord de reporting, les requêtes analytiques ou les points de terminaison de l’API à forte intensité de lecture.

​
Mise à l’échelle du CDC pour l’intégration ClickHouse

Si vous répliquez des données vers ClickHouse à l’aide de ClickPipes, vous pouvez mettre à l’échelle le pipeline CDC (capture des changements de données) indépendamment :
  • Mise à l’échelle des workers CDC de 1 à 24 cœurs CPU
  • La mémoire est automatiquement dimensionnée à 4x le nombre de cœurs CPU
  • Réglez la mise à l’échelle via l’API OpenAPI de ClickPipes
Cela vous permet d’optimiser le débit de réplication indépendamment des ressources de votre instance Postgres.

​
Mise à l’échelle automatique

ClickHouse Managed Postgres surveille l’utilisation du disque et augmente automatiquement la capacité de stockage afin que votre instance ne manque pas d’espace :
  • 85 % d’utilisation du disque : vous recevez une notification dans la console Cloud et par e-mail.
  • 90 % d’utilisation du disque : la mise à l’échelle automatique démarre. La capacité de stockage passe à la taille immédiatement supérieure disponible pour votre famille d’instances. Le CPU et la mémoire restent inchangés, sauf si la taille actuelle de l’instance ne prend pas en charge un disque plus grand, auquel cas la taille de l’instance est également augmentée. Les répliques de lecture sont mises à l’échelle en même temps que l’instance primaire.
  • 95 % d’utilisation du disque : le basculement ne tient pas compte de toute fenêtre de maintenance configurée et s’effectue dès que le nouveau serveur est prêt.
Si votre instance utilise déjà la plus grande configuration disponible, la mise à l’échelle automatique ne peut pas aller plus loin. Libérez de l’espace disque ou contactez le support.

​
Basculement et connexions

Le stockage ne peut pas être redimensionné sur place. La mise à l’échelle automatique suit le même processus de mise à l’échelle qu’un changement manuel de type d’instance : un serveur de remplacement disposant de davantage de stockage est provisionné, restauré à partir de la dernière sauvegarde, rattrape le WAL, puis est promu nouvelle instance primaire lors d’un basculement contrôlé. Les instances dotées de la haute disponibilité reçoivent, dans le cadre de la même opération, des instances de secours de remplacement de la nouvelle taille. Le basculement est la seule étape entraînant une interruption de service, généralement inférieure à une minute. Si une fenêtre de maintenance est configurée, le basculement attend cette fenêtre, sauf si l’utilisation du disque atteint 95 %. Pendant le basculement, les connexions ouvertes sont interrompues et les transactions en cours sont annulées. Votre chaîne de connexion ne change pas : le DNS est mis à jour pour pointer vers la nouvelle instance primaire, et les applications disposant d’une logique de reconnexion standard se reconnectent automatiquement.

​
Mode lecture seule

Si les écritures remplissent le disque plus rapidement que la mise à l’échelle automatique ne peut s’effectuer, l’instance passe en mode lecture seule pour éviter de saturer complètement le disque. Le seuil de déclenchement dépend de l’espace libre restant : Les lectures continuent de fonctionner, tandis que les écritures échouent avec l’erreur Postgres standard cannot execute INSERT in a read-only transaction. Si l’espace libre continue de diminuer, les connexions existantes sont interrompues afin que chaque session prenne en compte le paramètre de lecture seule ; les lectures fonctionnent de nouveau une fois les clients reconnectés. Le mode lecture seule est automatiquement désactivé dès que l’espace libre se rétablit, généralement juste après la fin du basculement de scale-up.

​
Exemple

Une instance disposant de 1024 Go de stockage exécute une charge de travail intensive en écritures :
  1. Lorsque 870 Go sont utilisés (85 %), vous recevez une notification concernant le stockage.
  2. Lorsque 922 Go sont utilisés (90 %), la mise à l’échelle automatique démarre. Un serveur de remplacement disposant de 2048 Go de stockage est provisionné et restauré à partir de la dernière sauvegarde, tandis que votre instance continue de traiter le trafic.
  3. Une fois le serveur de remplacement synchronisé, le basculement est effectué, pendant votre fenêtre de maintenance si elle est configurée. Les connexions sont interrompues pendant moins d’une minute, votre application se reconnecte au même nom d’hôte et l’utilisation retombe à environ 45 %.
  4. Si l’espace libre tombe sous 2 % (environ 20 Go) avant la fin du basculement, l’instance passe en lecture seule. Les écritures reprennent automatiquement une fois le basculement vers le disque plus grand terminé.

​
Ressources supplémentaires

Dernière modification le 14 août 2026