Skip to main content
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.

​
Tipos de instância e flexibilidade

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

​
Como escolher o tipo de instância certo

Diferentes cargas de trabalho se beneficiam de diferentes configurações de recursos:
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.

​
Como o escalonamento funciona

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.

​
Processo de escalonamento

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
    • 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

​
Duração do escalonamento

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).
Indisponibilidade mínimaSua 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.

​
Restauração em paralelo com WAL-G

O ClickHouse Managed Postgres usa 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.

​
Iniciando uma operação de escalonamento

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”

​
Estratégias de escalonamento

​
Escalonamento vertical

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

​
Réplicas de leitura para escalabilidade horizontal

Para cargas de trabalho com muitas leituras, considere usar réplicas de leitura 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.

​
Escalonamento de CDC para a integração com o ClickHouse

Se você estiver replicando dados para o ClickHouse usando ClickPipes, 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
Isso permite otimizar a taxa de transferência da replicação separadamente dos recursos da sua instância do Postgres.

​
Escalonamento automático

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

​
Transição e conexões

O armazenamento não é redimensionado no local. O escalonamento automático segue o mesmo processo de scaling 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 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 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.

​
Modo somente leitura

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

​
Exemplo

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.

​
Recursos adicionais

Última modificação em 14 de agosto de 2026