O 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
- Mais de 50 tipos de instância disponíveis em configurações otimizadas para compute, memória e armazenamento
- Armazenamento baseado em 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
| 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) |
Como o escalonamento funciona
Processo de escalonamento
-
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)
-
Restauração a partir de backups no S3: O standby é inicializado restaurando o backup mais recente armazenado no S3
-
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
-
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
-
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
-
Desativação da instância antiga: A instância original é desativada após a conclusão do failover
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.
- 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
- Acesse a aba Configurações da sua instância
- Na seção Escalonamento, vá até Tamanho do serviço
- Selecione o tipo de instância desejado
- Revise as alterações e clique em “Aplicar alterações”
Estratégias de escalonamento
- 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
- 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.
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.
Quando o uso do disco atingir 90%, o tipo da sua instância será ajustado para um tipo de instância maior.
