Benefícios do Banco de Dados do Azure para PostgreSQL com Cluster Elástico

Os Clusters Elásticos do Banco de Dados do Azure para PostgreSQL são a próxima evolução da oferta distribuída do PostgreSQL do Azure, criado no Servidor Flexível do Banco de Dados do Azure para PostgreSQL com a extensão Citus. Para clientes que executam o Azure Cosmos DB para PostgreSQL hoje, os Clusters Elásticos oferecem paridade de recursos para cargas de trabalho distribuídas do Postgres, fornecendo um caminho mais integrado, flexível e econômico.

• Um roteiro claro para o futuro: os Clusters Elásticos são o caminho estratégico para o PostgreSQL distribuído no Azure, com investimentos contínuos (por exemplo, melhorias planejadas, como failovers planejados, expansão automática de armazenamento e retenção de longo prazo). O Azure Cosmos DB para PostgreSQL está em processo de desativação com suporte limitado durante este período.

• Modelo de custo mais baixo e mais simples (sem sobretaxa de coordenador dedicado): os Clusters Elásticos não exigem um nó exclusivo de coordenador com cobrança separada, o que pode reduzir os custos básicos e torna a previsão dos preços mais fácil à medida que você escala horizontalmente.

• Opções de desempenho mais flexíveis: escolha entre as camadas Com Capacidade de Intermitência, Uso Geral e Otimizado para Memória e as séries de computação mais recentes para o custo e o desempenho de tamanho certo por nó conforme as cargas de trabalho aumentam.

• Execute consultas direto de qualquer nó: os Clusters Elásticos permitem acessar as consultas por meio de qualquer nó, melhorando a flexibilidade operacional para ferramentaria, a solução de problemas e os padrões de carga de trabalho que se beneficiam de vários pontos de ingresso.

• Funcionalidades modernas do PostgreSQL mais cedo: a adoção mais rápida de versões mais recentes do PostgreSQL (incluindo suporte ao PostgreSQL 17) ajuda os clientes a acessar atualizações de segurança, melhorias de desempenho e novos recursos de linguagem anteriormente.

• Baseado no Azure Database for PostgreSQL Flexible Server: os Clusters Elásticos herdam o modelo operacional que os clientes já usam para o Servidor Flexível — backups, monitoramento/métricas, controles de manutenção e integração de plataforma — reduzindo a complexidade das operações de segundo dia.

• Integração de identidade e segurança mais forte: o suporte à identidade gerenciada e à autenticação de ID do Microsoft Entra ajuda a simplificar o gerenciamento de segredos e alinhar o acesso ao banco de dados com controles de identidade da empresa.

Comparação de funcionalidades

¹ Está disponível a remoção do nó por meio do reequilíbrio para mover os dados de um nó, mas o próprio nó não é desprovisionado automaticamente.

Ferramenta de migração

Uma ferramenta de migração dedicada é fornecida para facilitar a transição perfeita do Azure Cosmos DB para PostgreSQL para o Cluster Elástico do Banco de Dados do Azure para PostgreSQL. Essa ferramenta automatiza o esquema e a migração de dados, minimiza o tempo de inatividade e garante a integridade dos dados.

A abordagem de migração centra-se na criação de um novo disco de dados no Flex tirando um instantâneo de um cluster CPG e montando-o como o disco de dados primário do EC (Cluster Elástico de destino), reduzindo drasticamente o tempo de migração e garantindo a fidelidade de dados sem ser afetado pela qualidade da rede. Em seguida, copiaremos os arquivos delta (extensões, configurações de extensão PG, certificados, logs de arquivo, etc.) do /datadrive do Flex original para o novo disco.

A ferramenta juntamente com o lembrete pop-up estará disponível por meio da guia Migração no Azure Cosmos DB para PostgreSQL a partir de 13^de abril.

A partir daí, a migração pode ser iniciada fornecendo detalhes simples para o servidor de destino

Mapeamento de SKU

O Azure Cosmos DB para PostgreSQL será alinhado com o Banco de Dados do Azure de destino para PostgreSQL (Cluster Elástico), de acordo com a tabela de correspondência abaixo. Após a migração, os clientes podem escalar ou reduzir com quase nenhum tempo de inatividade.

Fluxo de migração

1. O usuário inicia a migração da página do cluster CPG no portal do Azure.

2. O portal executa verificações de pré-validação.

3. Se as verificações forem aprovadas, o portal provisionará o Cluster Elástico (EC) de destino com as configurações de migração de CPG (por exemplo, a configuração de versão PG+Citus/ordenação).

4. O portal inicia a migração na EC provisionada.

5. A ferramenta de migração muda o cluster CPG para modo somente leitura e inicia a criação de snapshots (um por nó em ambientes com vários nós).

6. Ele chama o Cluster Elástico com as IDs de recurso de instantâneo para iniciar a migração baseada em disco.

7. Ele cria os novos discos de dados direto dos instantâneos, bloqueia o EC, interrompe os contêineres e troca o novo disco para que funcione como o /datadrive principal.

8. Ele copia os arquivos da plataforma "delta" para o novo disco (extensões, configurações de PG/extensão, certificados, arquios/WAL etc.), restaura a propriedade/permissões e realiza as correções necessárias nos metadados (por exemplo, mapeamentos de nó, funções, extensões).

9. Ele inicia contêineres e conclui a operação de migração;

10. Após o sucesso, a ferramenta aplica as configurações pós-migração ao EC (configurações alteradas pelo usuário, configurações de HA).

11. A migração é concluída: o portal atualiza o status de êxito/falha quando concluída. O Cluster de CPT é parado e o Cluster Elástico torna-se o novo destino gravável no qual o cliente pode alternar (nova cadeia de conexão, recriar o PEC, se necessário).

Tempo médio de migração

Na maioria dos casos, a migração de ponta a ponta é concluída em menos de 10 minutos. A janela de bloqueio de gravação (somente leitura) — do ponto em que o cluster de origem é alternado para somente leitura até que o Cluster Elástico de destino seja gravável — normalmente tem uma média de ~5 a 8 minutos, tornando-o adequado para execução dentro de uma janela de manutenção agendada padrão.

Fatores-chave que podem afetar o tempo: o tamanho do banco de dados e o número de nós (mais instantâneos ou discos), volume de extensão.

Conteúdo relacionado

• Banco de Dados do Azure para PostgreSQL