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

# Escalado

> Escala verticalmente tu instancia de ClickHouse Managed Postgres con tipos de VM flexibles y escalado independiente de recursos

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>Funcionalidad beta</span>
        </a>;
};

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

ClickHouse Managed Postgres ofrece opciones de escalado flexible para adaptarse a las necesidades de su carga de trabajo. Con más de 50 tipos de instancia con almacenamiento NVMe entre los que elegir, puede escalar CPU, memoria y almacenamiento de forma independiente para optimizar el rendimiento y el costo según su caso de uso específico.

<div id="instance-types">
  ## Tipos de instancia y flexibilidad
</div>

ClickHouse Managed Postgres ofrece una amplia variedad de tipos de instancia, cada uno optimizado para distintas cargas de trabajo:

* **Más de 50 tipos de instancia** disponibles en configuraciones optimizadas para cómputo, memoria y almacenamiento
* **Almacenamiento basado en NVMe** en todos los tipos de instancia para ofrecer una E/S de disco uniforme y de alto rendimiento
* **Escalado independiente de recursos**: elige el equilibrio adecuado entre CPU, memoria y almacenamiento según tu carga de trabajo

<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="Tipos de instancia" size="md" border width="1442" height="3288" data-path="images/managed-postgres/instance-types.webp" />

<div id="choosing-instance">
  ### Cómo elegir el tipo de instancia adecuado
</div>

Las distintas cargas de trabajo se benefician de diferentes configuraciones de recursos:

| Tipo de carga de trabajo                                                       | CPU   | Memoria | Almacenamiento | Instancia recomendada                                        |
| ------------------------------------------------------------------------------ | ----- | ------- | -------------- | ------------------------------------------------------------ |
| **Optimizada para cómputo**                                                    | Alta  | Media   | Medio          | Optimizada para cómputo (alto número de vCPU)                |
| **Optimizada para memoria** (conjunto de trabajo grande)                       | Media | Alta    | Medio          | Optimizada para memoria (alta proporción de memoria por CPU) |
| **Optimizada para almacenamiento** (conjuntos de datos grandes, E/S intensiva) | Media | Media   | Alta           | Optimizada para almacenamiento (alta capacidad de NVMe)      |

<Tip>
  Por motivos de seguridad, es posible que no puedas cambiar a tipos de instancia cuyo almacenamiento se aproxime a tu capacidad de almacenamiento actualmente utilizada. Elige siempre tipos de instancia con holgura respecto a tu capacidad utilizada actual para evitar problemas.
</Tip>

<div id="how-scaling-works">
  ## Cómo funciona el escalado
</div>

Cuando cambias de tipo de instancia, ClickHouse Managed Postgres realiza una operación de escalado vertical que aprovisiona nueva infraestructura y migra tu base de datos con un tiempo de inactividad mínimo.

<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="Configuración del escalado" size="md" border width="2478" height="1742" data-path="images/managed-postgres/scaling-settings.webp" />

<div id="scaling-process">
  ### Proceso de escalado
</div>

El flujo de escalado aprovisiona una nueva instancia standby a partir de backups y realiza un failover controlado:

1. **Aprovisionamiento de la instancia standby**: Se crea una nueva instancia standby con el tipo de instancia de destino (CPU, memoria y configuración de almacenamiento)

2. **Restauración desde backups de S3**: La instancia standby se inicializa restaurando el backup más reciente almacenado en S3

3. **Reproducción paralela del WAL**: La instancia standby aplica todos los cambios del Write-Ahead Log (WAL) desde el backup mediante mecanismos de restauración en paralelo impulsados por [WAL-G](https://github.com/wal-g/wal-g)
   * WAL-G permite operaciones de restauración rápidas y paralelas
   * El creador de WAL-G forma parte del equipo de Ubicloud, con el que nos hemos asociado, lo que garantiza un alto nivel de experiencia y optimización

4. **Sincronización de la replicación**: La instancia standby se sincroniza con la instancia primaria transmitiendo y aplicando los cambios continuos del WAL

5. **Failover**: Una vez que la instancia standby está completamente sincronizada, un failover controlado la promueve a la nueva primaria
   * **Este es el único paso que causa tiempo de inactividad** (\~30 segundos)
   * Todas las conexiones activas se interrumpen durante el failover
   * Los clientes deben volver a conectarse una vez finalizado el failover

6. **Retirada de la instancia antigua**: La instancia original se retira una vez finalizado el failover

<div id="scaling-duration">
  ### Duración del escalado
</div>

El tiempo total necesario para el escalado depende principalmente del tamaño de su base de datos y de la cantidad de datos de WAL que deban reproducirse desde los backups:

* **Restauración del backup**: Tiempo necesario para restaurar el full backup más reciente desde S3 en la nueva instancia
* **Reproducción de WAL**: Tiempo necesario para reproducir los cambios incrementales de WAL desde el último full backup
* **Restauración en paralelo**: Los mecanismos de restauración en paralelo de WAL-G aceleran significativamente el proceso

El tiempo de restauración puede variar de unos minutos a varias horas, pero el mantenimiento/tiempo de inactividad es muy bajo (solo \~30 segundos).

<Warning>
  **Tiempo de inactividad mínimo**

  Su aplicación experimentará aproximadamente 30 segundos de tiempo de inactividad durante el failover, independientemente de cuánto dure el proceso general de escalado. Todo el trabajo de restauración y puesta al día se realiza en segundo plano en la instancia standby.
</Warning>

<div id="parallel-restore">
  ### Restauración en paralelo con WAL-G
</div>

ClickHouse Managed Postgres usa [WAL-G](https://github.com/wal-g/wal-g) para acelerar la restauración de backups durante las operaciones de escalado. Cabe destacar que el creador de WAL-G forma parte del equipo de Ubicloud, con el que nos hemos asociado, lo que aporta una gran experiencia al proceso de restauración.

WAL-G proporciona:

* **Descarga y descompresión en paralelo**: varios segmentos del backup se recuperan de S3 y se descomprimen simultáneamente
* **Reproducción eficiente de WAL**: los cambios incrementales del WAL se aplican en paralelo cuando es posible
* **Streaming optimizado**: streaming directo desde el almacenamiento S3 sin copias intermedias
* **Restauración rápida**: aunque el tiempo total depende del tamaño de los datos, el enfoque en paralelo hace que el proceso sea bastante rápido

Estas optimizaciones reducen significativamente el tiempo necesario para poner en marcha la nueva instancia standby. Y, lo más importante, la restauración se realiza por completo en segundo plano: la aplicación solo experimenta tiempo de inactividad durante la breve ventana de failover de \~30 segundos.

<div id="initiating-scaling">
  ### Iniciar una operación de escalado
</div>

Para escalar su instancia de ClickHouse Managed Postgres:

1. Vaya a la pestaña **Configuración** de su instancia
2. En la sección **Escalado**, desplácese hasta **Tamaño del servicio**
3. Seleccione el tipo de instancia de destino
4. Revise los cambios y haga clic en "Aplicar cambios"

<div id="scaling-strategies">
  ## Estrategias de escalado
</div>

<div id="vertical-scaling">
  ### Escalado vertical
</div>

El escalado vertical (cambiar los tipos de instancia) es el método principal para ajustar los recursos en ClickHouse Managed Postgres. Este enfoque ofrece:

* **Control granular**: Elija entre más de 50 tipos de instancia para ajustar con precisión la CPU, la memoria y el almacenamiento
* **Optimización de la carga de trabajo**: Seleccione configuraciones optimizadas para su carga de trabajo específica (intensiva en cómputo, memoria o almacenamiento)
* **Eficiencia de costos**: Pague solo por los recursos que necesita, sin sobredimensionar

<div id="read-replicas">
  ### Réplicas de lectura para el escalado horizontal
</div>

Para cargas de trabajo con muchas lecturas, considere usar [réplicas de lectura](/es/products/managed-postgres/read-replicas) para escalar horizontalmente la capacidad de lectura:

* Desvíe las consultas de lectura a instancias de réplica de lectura dedicadas
* Cada réplica de lectura es una instancia de Postgres totalmente independiente con su propia capacidad de cómputo y memoria
* Las réplicas de lectura obtienen en streaming los cambios del WAL desde el almacenamiento de objetos para una replicación eficiente

Este enfoque es ideal para aplicaciones con una alta proporción de lecturas frente a escrituras, como paneles de informes, consultas analíticas o endpoints de API con uso intensivo de lectura.

<div id="cdc-scaling">
  ### Escalado de CDC para la integración de ClickHouse
</div>

Si estás replicando datos a ClickHouse mediante [ClickPipes](/es/products/managed-postgres/clickhouse-integration), puedes escalar de forma independiente el pipeline de CDC (captura de datos modificados):

* Escala los workers de CDC de 1 a 24 núcleos de CPU
* La memoria se escala automáticamente a 4 veces la cantidad de núcleos de CPU
* Ajusta el escalado mediante la [OpenAPI de ClickPipes](/es/integrations/clickpipes/postgres/scaling)

Esto te permite optimizar el rendimiento de la replicación por separado de los recursos de tu instancia de Postgres.

<div id="autoscaling">
  ## Escalado automático
</div>

ClickHouse Managed Postgres supervisa el uso de disco y escala el almacenamiento automáticamente para evitar que su instancia se quede sin espacio:

* **85 % de uso de disco**: Recibe una [notificación](/es/products/managed-postgres/monitoring/notifications) a través de la consola de Cloud y por correo electrónico.
* **90 % de uso de disco**: Se inicia el escalado automático. El almacenamiento aumenta al siguiente tamaño disponible para la familia de instancias correspondiente. La CPU y la memoria se mantienen igual, salvo que el tamaño actual de la instancia no admita un disco más grande; en ese caso, también se aumenta el tamaño de la instancia. Las [réplicas de lectura](/es/products/managed-postgres/read-replicas) se escalan junto con la instancia primaria.
* **95 % de uso de disco**: La conmutación omite cualquier ventana de mantenimiento configurada y se realiza en cuanto el nuevo servidor está listo.

Si su instancia ya cuenta con la configuración más grande disponible, el escalado automático no puede ampliarla más. Libere espacio en disco o póngase en contacto con [soporte](https://clickhouse.com/support/program).

<div id="autoscaling-cutover">
  ### Conmutación y conexiones
</div>

El almacenamiento no se redimensiona in situ. El escalado automático sigue el mismo [proceso de escalado](#scaling-process) que un cambio manual del tipo de instancia: se aprovisiona un servidor de reemplazo con más almacenamiento, se restaura a partir del backup más reciente, se pone al día con el WAL y una conmutación controlada lo promueve a servidor primario. Las instancias con [alta disponibilidad](/es/products/managed-postgres/high-availability) obtienen instancias standby de reemplazo con el nuevo tamaño como parte de la misma operación.

La conmutación es el único paso que implica tiempo de inactividad, normalmente de menos de un minuto. Si se configura una [ventana de mantenimiento](/es/products/managed-postgres/upgrades#maintenance-windows), la conmutación espera hasta esa ventana, a menos que el uso de disco alcance el 95 %. Durante la conmutación, se cierran las conexiones abiertas y se revierten las transacciones en curso. La cadena de conexión no cambia: se actualiza el DNS para que apunte al nuevo servidor primario y las aplicaciones con lógica de reconexión estándar se recuperan automáticamente.

<div id="autoscaling-read-only">
  ### Modo de solo lectura
</div>

Si las operaciones de escritura llenan el disco más rápido de lo que tarda en completarse el escalado automático, la instancia pasa a modo de solo lectura para evitar que el disco se llene por completo. El desencadenante es el espacio libre restante:

| Tamaño total del disco | Solo lectura por debajo de | Las escrituras se reanudan por encima de |
| ---------------------- | -------------------------- | ---------------------------------------- |
| Hasta 64 GB            | 1 GB libre                 | 2 GB libres                              |
| Hasta 128 GB           | 5 GB libres                | 7 GB libres                              |
| Hasta 512 GB           | 7 GB libres                | 10 GB libres                             |
| Más de 512 GB          | 2 % libre                  | 3 % libre                                |

Las lecturas siguen funcionando, mientras que las operaciones de escritura generan el error estándar de Postgres `cannot execute INSERT in a read-only transaction`. Si el espacio libre sigue reduciéndose, se cierran las conexiones existentes para que cada sesión aplique la configuración de solo lectura; las lecturas vuelven a funcionar cuando los clientes se reconectan. El modo de solo lectura se desactiva automáticamente cuando se recupera el espacio libre, normalmente justo después de completarse la transición del scale-up.

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

Una instancia con 1024 GB de almacenamiento ejecuta una carga de trabajo con un uso intensivo de escritura:

1. Cuando se utilizan 870 GB (85 %), recibe una notificación de almacenamiento.
2. Cuando se utilizan 922 GB (90 %), se inicia el escalado automático. Se aprovisiona un servidor de reemplazo con 2048 GB de almacenamiento y se restaura a partir del backup más reciente mientras la instancia sigue atendiendo tráfico.
3. Cuando el reemplazo se ha puesto al día, se realiza la conmutación, dentro de la ventana de mantenimiento si hay una configurada. Las conexiones se interrumpen durante menos de un minuto, la aplicación se vuelve a conectar al mismo hostname y el uso vuelve a situarse en torno al 45 %.
4. Si el espacio libre cae por debajo del 2 % (unos 20 GB) antes de que se complete la conmutación, la instancia pasa a modo de solo lectura. Las escrituras se reanudan automáticamente cuando finaliza la conmutación al disco más grande.

<div id="resources">
  ## Recursos adicionales
</div>

* [Configuración y ajustes](/es/products/managed-postgres/settings)
* [Réplicas de lectura](/es/products/managed-postgres/read-replicas)
* [Alta disponibilidad](/es/products/managed-postgres/high-availability)