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

# Escalonamento

> Escale verticalmente sua instância do ClickHouse Managed Postgres com tipos de VM flexíveis e escalonamento independente 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>Recurso beta</span>
        </a>;
};

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

O ClickHouse Managed Postgres oferece opções de escalonamento flexível para atender às exigências da sua carga de trabalho. Com mais de 50 tipos de instância com NVMe à disposição, você pode dimensionar CPU, memória e armazenamento de forma independente para otimizar o desempenho e o custo do seu caso de uso específico.

<div id="instance-types">
  ## Tipos de instância e flexibilidade
</div>

O ClickHouse Managed Postgres oferece uma ampla variedade de tipos de instância, cada um otimizado para diferentes características de carga de trabalho:

* **Mais de 50 tipos de instância** disponíveis em configurações otimizadas para compute, memória e armazenamento
* **Armazenamento com NVMe** em todos os tipos de instância para E/S de disco consistente e de alto desempenho
* **Escalonamento independente de recursos**: escolha o equilíbrio ideal entre CPU, memória e armazenamento com base na sua carga de trabalho

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

<div id="choosing-instance">
  ### Como escolher o tipo de instância certo
</div>

Diferentes cargas de trabalho se beneficiam de diferentes configurações de recursos:

| Tipo de carga de trabalho                                                | CPU   | Memória | Armazenamento | Instância recomendada                               |
| ------------------------------------------------------------------------ | ----- | ------- | ------------- | --------------------------------------------------- |
| **Otimizada para compute**                                               | Alta  | Média   | Médio         | Otimizada para compute (alto número de vCPUs)       |
| **Otimizada para memória** (grande conjunto ativo)                       | Média | Alta    | Médio         | Otimizada para memória (alta proporção memória/CPU) |
| **Otimizada para armazenamento** (grandes volumes de dados, E/S intensa) | Média | Média   | Alta          | Otimizada para armazenamento (alta capacidade NVMe) |

<Tip>
  Por motivos de segurança, talvez você não consiga mudar para tipos de instância cujo armazenamento esteja próximo da sua capacidade de armazenamento atualmente em uso. Sempre escolha tipos de instância com margem acima da sua capacidade atualmente em uso para evitar problemas.
</Tip>

<div id="how-scaling-works">
  ## Como o escalonamento funciona
</div>

Quando você altera os tipos de instância, o ClickHouse Managed Postgres realiza uma operação de escalonamento vertical que provisiona uma nova infraestrutura e migra seu banco de dados com o mínimo de indisponibilidade.

<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="Configurações de escalonamento" size="md" border width="2478" height="1742" data-path="images/managed-postgres/scaling-settings.webp" />

<div id="scaling-process">
  ### Processo de escalonamento
</div>

O fluxo de escalonamento cria um novo standby a partir de backups e realiza um failover controlado:

1. **Provisioning do standby**: Uma nova instância standby é criada com o tipo de instância de destino (CPU, memória e configuração de armazenamento)

2. **Restauração a partir de backups no S3**: O standby é inicializado restaurando o backup mais recente armazenado no S3

3. **Reaplicação paralela de WAL**: O standby aplica todas as alterações do Write-Ahead Log (WAL) desde o backup usando mecanismos de restauração paralela com tecnologia [WAL-G](https://github.com/wal-g/wal-g)
   * O WAL-G permite operações de restauração rápidas e paralelizadas
   * O criador do WAL-G faz parte da equipe da Ubicloud, com a qual temos parceria, garantindo ampla expertise e otimização

4. **Sincronização da replicação**: O standby alcança a instância primária transmitindo e aplicando continuamente as alterações de WAL em andamento

5. **Failover**: Assim que o standby estiver totalmente sincronizado, um failover controlado promove o standby à nova instância primária
   * **Esta é a única etapa que causa indisponibilidade** (\~30 segundos)
   * Todas as conexões ativas são interrompidas durante o failover
   * Os clientes precisam se reconectar após a conclusão do failover

6. **Desativação da instância antiga**: A instância original é desativada após a conclusão do failover

<div id="scaling-duration">
  ### Duração do escalonamento
</div>

O tempo total necessário para o escalonamento depende principalmente do tamanho do seu banco de dados e do volume de dados de WAL que precisam ser reaplicados a partir dos backups:

* **Restauração do backup**: Tempo para restaurar o backup completo mais recente do S3 na nova instância
* **Reaplicação do WAL**: Tempo para reaplicar as mudanças incrementais do WAL desde o último backup completo
* **Restauração paralela**: Os mecanismos de restauração paralela do WAL-G aceleram significativamente o processo

O tempo de restauração pode variar de alguns minutos a algumas horas, mas a janela de manutenção/indisponibilidade é muito pequena (apenas \~30 segundos).

<Warning>
  **Indisponibilidade mínima**

  Sua aplicação terá aproximadamente 30 segundos de indisponibilidade durante o failover, independentemente de quanto tempo leve o processo geral de escalonamento. Todo o trabalho de restauração e sincronização acontece em segundo plano na instância standby.
</Warning>

<div id="parallel-restore">
  ### Restauração em paralelo com WAL-G
</div>

O ClickHouse Managed Postgres usa [WAL-G](https://github.com/wal-g/wal-g) para acelerar a restauração de backups durante operações de escalonamento. Vale destacar que o criador do WAL-G faz parte da equipe da Ubicloud, com quem temos parceria, trazendo ampla expertise para o processo de restauração.

O WAL-G oferece:

* **Download e descompressão em paralelo**: vários segmentos de backup são baixados do S3 e descomprimidos simultaneamente
* **Reaplicação eficiente de WAL**: alterações incrementais de WAL são aplicadas em paralelo sempre que possível
* **Streaming otimizado**: streaming direto do armazenamento S3, sem cópias intermediárias
* **Restauração rápida**: embora o tempo total dependa do volume de dados, a abordagem paralelizada torna o processo bastante rápido

Essas otimizações reduzem significativamente o tempo necessário para colocar a nova instância em standby em funcionamento. Mais importante ainda, a restauração acontece totalmente em segundo plano — sua aplicação só fica indisponível durante a breve janela de failover de \~30 segundos.

<div id="initiating-scaling">
  ### Iniciando uma operação de escalonamento
</div>

Para escalar sua instância do ClickHouse Managed Postgres:

1. Acesse a aba **Configurações** da sua instância
2. Na seção **Escalonamento**, vá até **Tamanho do serviço**
3. Selecione o tipo de instância desejado
4. Revise as alterações e clique em "Aplicar alterações"

<div id="scaling-strategies">
  ## Estratégias de escalonamento
</div>

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

O escalonamento vertical (mudança de tipos de instância) é o principal método para ajustar recursos no ClickHouse Managed Postgres. Essa abordagem oferece:

* **Controle granular**: Escolha entre mais de 50 tipos de instância para ajustar com precisão CPU, memória e armazenamento
* **Otimização da carga de trabalho**: Selecione configurações otimizadas para sua carga de trabalho específica (intensiva em computação, memória ou armazenamento)
* **Eficiência de custo**: Pague apenas pelos recursos de que você precisa, sem provisionar recursos em excesso

<div id="read-replicas">
  ### Réplicas de leitura para escalabilidade horizontal
</div>

Para cargas de trabalho com muitas leituras, considere usar [réplicas de leitura](/pt-BR/products/managed-postgres/read-replicas) para escalar horizontalmente a capacidade de leitura:

* Direcione as consultas de leitura para instâncias dedicadas de réplica de leitura
* Cada réplica de leitura é uma instância do Postgres totalmente independente, com sua própria capacidade de processamento e memória
* As réplicas de leitura transmitem alterações de WAL a partir do armazenamento de objetos para garantir uma replicação eficiente

Essa abordagem é ideal para aplicações com alta proporção de leituras em relação a gravações, como painéis de relatórios, consultas analíticas ou endpoints de API com uso intensivo de leitura.

<div id="cdc-scaling">
  ### Escalonamento de CDC para a integração com o ClickHouse
</div>

Se você estiver replicando dados para o ClickHouse usando [ClickPipes](/pt-BR/products/managed-postgres/clickhouse-integration), poderá escalar de forma independente o pipeline de CDC (captura de alterações de dados):

* Escalone os workers de CDC de 1 a 24 núcleos de CPU
* A memória é ajustada automaticamente para 4x o número de núcleos de CPU
* Ajuste o escalonamento por meio da [OpenAPI do ClickPipes](/pt-BR/integrations/clickpipes/postgres/scaling)

Isso permite otimizar a taxa de transferência da replicação separadamente dos recursos da sua instância do Postgres.

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

O ClickHouse Managed Postgres monitora o uso de disco e ajusta o armazenamento automaticamente para evitar que sua instância fique sem espaço:

* **85% de uso de disco**: Você recebe uma [notificação](/pt-BR/products/managed-postgres/monitoring/notifications) pelo console da Cloud e por e-mail.
* **90% de uso de disco**: O escalonamento automático é iniciado. O armazenamento é aumentado para o próximo tamanho disponível para a família da sua instância. A CPU e a memória permanecem inalteradas, a menos que o tamanho atual da instância não ofereça suporte a um disco maior. Nesse caso, o tamanho da instância também é aumentado. As [réplicas de leitura](/pt-BR/products/managed-postgres/read-replicas) são escaladas junto com a primária.
* **95% de uso de disco**: A transição ignora qualquer janela de manutenção configurada e ocorre assim que o novo servidor estiver pronto.

Se a sua instância já estiver na maior configuração disponível, o escalonamento automático não poderá ser ampliado. Libere espaço em disco ou entre em contato com o [suporte](https://clickhouse.com/support/program).

<div id="autoscaling-cutover">
  ### Transição e conexões
</div>

O armazenamento não é redimensionado no local. O escalonamento automático segue o mesmo [processo de scaling](#scaling-process) de uma alteração manual do tipo de instância: um servidor de substituição com mais armazenamento é provisionado, restaurado a partir do backup mais recente, sincroniza o WAL e, em uma transição controlada, é promovido ao novo primário. Instâncias com [alta disponibilidade](/pt-BR/products/managed-postgres/high-availability) recebem standbys de substituição no novo tamanho como parte da mesma operação.

A transição é a única etapa com indisponibilidade, geralmente inferior a um minuto. Se uma [janela de manutenção](/pt-BR/products/managed-postgres/upgrades#maintenance-windows) estiver configurada, a transição aguarda por ela, a menos que o uso do disco atinja 95%. Durante a transição, conexões abertas são encerradas e transações em andamento são revertidas. Sua string de conexão não muda: o DNS é atualizado para apontar para o novo primário, e as aplicações com lógica padrão de reconexão se recuperam automaticamente.

<div id="autoscaling-read-only">
  ### Modo somente leitura
</div>

Se as operações de gravação preencherem o disco mais rapidamente do que o escalonamento automático consegue ser concluído, a instância entra em modo somente leitura para evitar que o disco fique completamente cheio. O acionamento ocorre com base no espaço livre restante:

| Tamanho total do disco | Somente leitura abaixo de | Gravações retomadas acima de |
| ---------------------- | ------------------------- | ---------------------------- |
| Até 64 GB              | 1 GB livre                | 2 GB livres                  |
| Até 128 GB             | 5 GB livres               | 7 GB livres                  |
| Até 512 GB             | 7 GB livres               | 10 GB livres                 |
| Acima de 512 GB        | 2% livre                  | 3% livre                     |

As leituras continuam funcionando, enquanto as operações de gravação falham com o erro padrão do Postgres `cannot execute INSERT in a read-only transaction`. Se o espaço livre continuar diminuindo, as conexões existentes serão encerradas para que cada sessão adote a configuração de somente leitura; as leituras voltarão a funcionar assim que os clientes se reconectarem. O modo somente leitura é desativado automaticamente quando o espaço livre é recuperado, geralmente logo após a conclusão da transição de aumento de escala.

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

Uma instância com 1024 GB de armazenamento executa uma carga de trabalho com muitas gravações:

1. Ao atingir 870 GB usados (85%), você recebe uma notificação de armazenamento.
2. Ao atingir 922 GB usados (90%), o escalonamento automático é iniciado. Um servidor substituto com 2048 GB de armazenamento é provisionado e restaurado a partir do backup mais recente, enquanto sua instância continua atendendo ao tráfego.
3. Quando o substituto estiver atualizado, será feita a transição, dentro da sua janela de manutenção, se houver uma configurada. As conexões são interrompidas por menos de um minuto, sua aplicação se reconecta ao mesmo hostname e o uso volta a cerca de 45%.
4. Se o espaço livre cair abaixo de 2% (cerca de 20 GB) antes da conclusão da transição, a instância ficará no modo somente leitura. As gravações serão retomadas automaticamente assim que a transição para o disco maior for concluída.

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

* [Configurações e configuração](/pt-BR/products/managed-postgres/settings)
* [Réplicas de leitura](/pt-BR/products/managed-postgres/read-replicas)
* [Alta disponibilidade](/pt-BR/products/managed-postgres/high-availability)