> ## Documentation Index
> Fetch the complete documentation index at: https://private-7c7dfe99-revert-104359-revert-104251-parquet-single.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Mise à l’échelle

> Redimensionnez verticalement votre instance ClickHouse Managed Postgres grâce à des types de VM flexibles et à une mise à l’échelle indépendante des ressources

export const Image = ({img, alt, size = "lg"}) => {
  const normalizedSize = ["sm", "md", "lg"].includes(size) ? size : "lg";
  return <div className={`ch-image-${normalizedSize}`}>
      <Frame>
        <img src={img} alt={alt} />
      </Frame>
    </div>;
};

export const BetaBadge = ({link, galaxyTrack, galaxyEvent}) => {
  if (link) {
    return <a href={link} target="_blank" rel="noopener noreferrer" className="betaBadge" onClick={galaxyTrack && galaxyEvent ? galaxyOnClick(galaxyEvent) : undefined}>
                <span>Beta</span>
            </a>;
  }
  return <a href="https://clickhouse.com/docs/reference/settings/beta-and-experimental-features#beta-features" className="betaBadge">
            <span>Fonctionnalité en bêta</span>
        </a>;
};

<BetaBadge link="https://clickhouse.com/cloud/postgres" galaxyTrack={true} galaxyEvent="docs.managed-postgres.scaling-beta" />

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.

<div id="instance-types">
  ## Types d’instance et flexibilité
</div>

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

<Image img="https://mintcdn.com/private-7c7dfe99-revert-104359-revert-104251-parquet-single/PFv6BUx0ibY7rkJm/images/managed-postgres/instance-types.webp?fit=max&auto=format&n=PFv6BUx0ibY7rkJm&q=85&s=33e3cbf0fcbe1cca68840f9b3a3de85c" alt="Types d’instance" size="md" border width="1442" height="3288" data-path="images/managed-postgres/instance-types.webp" />

<div id="choosing-instance">
  ### Choisir le bon type d’instance
</div>

Différents types de charges de travail tirent parti de configurations de ressources différentes :

| Type de charge de travail                                               | CPU   | Mémoire | Stockage | Instance recommandée                                |
| ----------------------------------------------------------------------- | ----- | ------- | -------- | --------------------------------------------------- |
| **Optimisée pour le calcul**                                            | Élevé | Moyen   | Moyen    | Optimisée pour le calcul (nombre élevé de vCPU)     |
| **Optimisée pour la mémoire** (ensemble de travail important)           | Moyen | Élevé   | Moyen    | Optimisée pour la mémoire (ratio mémoire/CPU élevé) |
| **Optimisée pour le stockage** (grands jeux de données, E/S intensives) | Moyen | Moyen   | Élevé    | Optimisée pour le stockage (capacité NVMe élevée)   |

<Tip>
  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.
</Tip>

<div id="how-scaling-works">
  ## Fonctionnement de la mise à l’échelle
</div>

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

<Image img="https://mintcdn.com/private-7c7dfe99-revert-104359-revert-104251-parquet-single/g8hpkImHjWTMvqC-/images/managed-postgres/scaling-settings.webp?fit=max&auto=format&n=g8hpkImHjWTMvqC-&q=85&s=a88447e9dfe61b472853d73087ad2ef7" alt="Paramètres de mise à l’échelle" size="md" border width="2478" height="1742" data-path="images/managed-postgres/scaling-settings.webp" />

<div id="scaling-process">
  ### Processus de mise à l’échelle
</div>

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](https://github.com/wal-g/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é

<div id="scaling-duration">
  ### Durée de la mise à l’échelle
</div>

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

<Warning>
  **Indisponibilité minimale**

  Votre 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.
</Warning>

<div id="parallel-restore">
  ### Restauration parallèle avec WAL-G
</div>

ClickHouse Managed Postgres utilise [WAL-G](https://github.com/wal-g/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.

<div id="initiating-scaling">
  ### Démarrer une opération de mise à l'échelle
</div>

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"

<div id="scaling-strategies">
  ## Stratégies de mise à l’échelle
</div>

<div id="vertical-scaling">
  ### Mise à l’échelle verticale
</div>

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

<div id="read-replicas">
  ### Répliques de lecture pour la mise à l’échelle horizontale
</div>

Pour les charges de travail à forte dominante de lecture, envisagez d’utiliser des [répliques de lecture](/fr/products/managed-postgres/read-replicas) 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.

<div id="cdc-scaling">
  ### Mise à l’échelle du CDC pour l’intégration ClickHouse
</div>

Si vous répliquez des données vers ClickHouse à l’aide de [ClickPipes](/fr/products/managed-postgres/clickhouse-integration), 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](/fr/integrations/clickpipes/postgres/scaling)

Cela vous permet d’optimiser le débit de réplication indépendamment des ressources de votre instance Postgres.

<div id="autoscaling">
  ## Mise à l’échelle automatique
</div>

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](/fr/products/managed-postgres/monitoring/notifications) 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](/fr/products/managed-postgres/read-replicas) 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](https://clickhouse.com/support/program).

<div id="autoscaling-cutover">
  ### Basculement et connexions
</div>

Le stockage ne peut pas être redimensionné sur place. La mise à l’échelle automatique suit le même [processus de mise à l'échelle](#scaling-process) 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é](/fr/products/managed-postgres/high-availability) 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](/fr/products/managed-postgres/upgrades#maintenance-windows) 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.

<div id="autoscaling-read-only">
  ### Mode lecture seule
</div>

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 :

| Taille totale du disque | Passage en mode lecture seule en dessous de | Reprise des écritures au-dessus de |
| ----------------------- | ------------------------------------------- | ---------------------------------- |
| Jusqu’à 64 Go           | 1 Go libre                                  | 2 Go libres                        |
| Jusqu’à 128 Go          | 5 Go libres                                 | 7 Go libres                        |
| Jusqu’à 512 Go          | 7 Go libres                                 | 10 Go libres                       |
| Plus de 512 Go          | 2 % libres                                  | 3 % libres                         |

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.

<div id="autoscaling-example">
  ### Exemple
</div>

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

<div id="resources">
  ## Ressources supplémentaires
</div>

* [Paramètres et configuration](/fr/products/managed-postgres/settings)
* [Répliques de lecture](/fr/products/managed-postgres/read-replicas)
* [Haute disponibilité](/fr/products/managed-postgres/high-availability)