Atualizações de versão principal no Banco de Dados do Azure para PostgreSQL – Servidor Flexível

2025-06-19

APPLIES TO: Banco de Dados do Azure para PostgreSQL – Servidor Flexível

O servidor flexível do Banco de Dados do Azure para PostgreSQL dá suporte às versões 17 (versão prévia), 16, 15, 14, 13, 12 e 11 do PostgreSQL. A comunidade do Postgres lança uma vez por ano uma nova versão principal com novos recursos. Além disso, cada versão principal recebe correções periódicas de bugs na forma de versões secundárias. Atualizações de versões secundárias incluem mudanças compatíveis retroativamente com aplicativos existentes. O servidor flexível do Banco de Dados do Azure para PostgreSQL atualiza periodicamente as versões secundárias durante a janela de manutenção de um cliente.

As atualizações de versão principal são mais complicadas do que as atualizações de versão secundárias. Elas podem incluir alterações internas e novos recursos que podem não ser compatíveis com versões anteriores dos aplicativos existentes.

O servidor flexível do Banco de Dados do Azure para PostgreSQL tem um recurso que executa uma atualização de versão principal in-loco do servidor com apenas um clique. Esse recurso simplifica o processo de atualização minimizando a interrupção para os usuários e aplicativos que acessam o servidor.

As atualizações no local mantêm o nome do servidor e outras configurações do servidor atual após a atualização de uma versão principal. Elas não exigem migração de dados ou alterações nas cadeias de conexão do aplicativo. As atualizações in-loco são mais rápidas e envolvem um tempo de inatividade menor do que a migração de dados.

Processo de Atualização

Veja abaixo algumas considerações importantes sobre as atualizações de versão principal in-loco:

Antes de iniciar a atualização, verifique se o servidor tem pelo menos 10 a 20% de armazenamento livre disponível. Durante o processo de atualização, os arquivos de log temporários e as operações de metadados podem aumentar o uso do disco. Espaço livre insuficiente pode resultar em falhas de atualização ou problemas de reversão.
Durante o processo de uma atualização de versão principal no local, o servidor flexível do Banco de Dados do Azure para PostgreSQL executa um procedimento de verificação prévia para identificar possíveis problemas que possam fazer com que a atualização falhe.
- Se a verificação prévia encontrar alguma incompatibilidade, ela criará um evento de log que mostra que a verificação prévia da atualização falhou, juntamente com uma mensagem de erro.
- Se a verificação prévia for bem-sucedida, o servidor flexível do Banco de Dados do Azure para PostgreSQL interromperá o serviço e usará um backup implícito pouco antes de iniciar a atualização. O serviço pode usar esse backup para restaurar a instância do banco de dados para sua versão anterior se houver um erro de atualização.
O servidor flexível de Banco de Dados do Azure para PostgreSQL usa a ferramenta pg_upgrade para realizar atualizações de versão principal no local. O serviço fornece a flexibilidade de ignorar versões e atualizar diretamente para as versões posteriores.
Durante uma atualização de versão principal in-loco de um servidor que está habilitado para HA (alta disponibilidade), o serviço desabilita a HA, executa a atualização no servidor primário e habilita a HA novamente após a conclusão da atualização.
A maioria das extensões é atualizada automaticamente para as versões posteriores durante uma atualização de versão principal local, com algumas exceções.
O processo de uma atualização de versão principal in-loco para o servidor flexível do Banco de Dados do Azure para PostgreSQL implanta automaticamente a última versão secundária com suporte.
Uma atualização de versão principal no local é uma operação offline, o que significa que o servidor ficará indisponível durante o processo. Embora a maioria das atualizações seja concluída em menos de 15 minutos, a duração real depende do tamanho e da complexidade do banco de dados. Especificamente, o tempo necessário é diretamente proporcional ao número de objetos (tabelas, índices, esquemas) na instância do PostgreSQL. Esquemas maiores ou mais complexos podem experimentar tempos de atualização mais longos.
Transações de execução prolongada ou alta carga de trabalho antes da atualização podem aumentar o tempo necessário para desligar o banco de dados e aumentar o tempo de atualização.
Depois que a atualização de versão principal no local for bem-sucedida, não há meios automatizados para reverter para a versão anterior. No entanto, você pode executar uma recuperação pontual para um horário anterior à atualização para restaurar a versão anterior da instância do banco de dados.
O Banco de Dados do Azure para PostgreSQL – Servidor Flexível tira um instantâneo do seu banco de dados durante uma atualização. O instantâneo é tirado antes do início da atualização. Em caso de falha na atualização, o sistema restaurará automaticamente o banco de dados para o estado anterior a partir do instantâneo.
O PostgreSQL 16 introduz medidas de segurança baseadas em função. Após uma atualização de versão principal no servidor flexível do Banco de Dados do Azure para PostgreSQL, o primeiro usuário criado no servidor , que recebe a opção ADMIN, agora terá privilégios administrativos em relação a outras funções para operações de manutenção essenciais.

Considerações e limitações de atualização

Se uma operação de verificação prévia falhar durante uma atualização de versão principal no local, a atualização será bloqueada e uma mensagem de erro detalhada será exibida. Abaixo estão as limitações conhecidas que podem fazer com que a atualização falhe ou se comporte inesperadamente:

Configurações de servidor sem suporte

Não há suporte para as réplicas de leitura durante as atualizações no local. Você deve excluir a réplica de leitura antes de atualizar o servidor primário. Após a atualização, você pode recriar a réplica.
As regras de tráfego de rede podem bloquear as operações de atualização.
- Verifique se o servidor flexível pode enviar/receber tráfego nas portas 5432 e 6432 em sua rede virtual e no Armazenamento do Azure (para arquivamento de logs).
- Se os NSGs (Grupos de Segurança de Rede) restringirem esse tráfego, a HA não habilitará novamente automaticamente após a atualização. Talvez você precise atualizar manualmente as regras do NSG e reabilitar a HA.
Não há suporte para os slots de replicação lógica durante as atualizações de versão principais no local.
Os servidores que usam o armazenamento SSDv2 não são elegíveis para atualizações de versão principais.
Exibições dependentes de pg_stat_activity não são suportadas durante atualizações de versões principais.

Limitações de extensão

As atualizações de versão maior no local não dão suporte a todas as extensões do PostgreSQL. A atualização falhará durante a verificação prévia se extensões sem suporte forem encontradas.

As seguintes extensões não têm suporte em nenhuma versão do PostgreSQL: timescaledb, , dblink, orafce, , pg_partmanpostgres_fdw
As seguintes extensões não têm suporte quando o destino de atualização é PostgreSQL 16 ou superior: pgrouting
Não há suporte para as seguintes extensões ao atualizar para o PostgreSQL 17: pgrouting, , age, azure_ai, , hllpg_diskann
Extensões como pg_repack, e hypopg não dão suporte a atualizações in-loco e devem ser descartadas antes da atualização e recriadas depois. Essas extensões são não persistentes e seguras para reconfigurar após a atualização.

Essas extensões devem ser removidas do parâmetro do servidor azure.extensions antes da atualização. Se presente, a atualização será bloqueada.

Considerações específicas do PostGIS

Se você estiver usando o PostGIS ou quaisquer extensões dependentes, deverá configurar o parâmetro search_path servidor para incluir:

Esquemas relacionados ao PostGIS
Extensões dependentes, incluindo: postgis, , postgis_raster, postgis_sfcgal, postgis_tiger_geocoder, postgis_topology, , address_standardizer, , , address_standardizer_data_usfuzzystrmatch
A falha ao configurar o search_path corretamente pode levar a falhas de atualização ou objetos quebrados após a atualização.

Outras considerações de atualização

Objetos grandes (LOs): bancos de dados com milhões de objetos grandes (armazenados em pg_largeobject) podem causar falhas de atualização devido ao alto uso de memória ou ao volume do log. Use o utilitário vacuumlo para limpar LOs não utilizados e considere dimensionar o servidor antes da atualização se muitos LOs ainda estiverem em uso.

Aviso

Tenha cuidado ao usar vacuumlo. vacuumlo identifica objetos grandes órfãos com base em colunas de referência convencionais (oid, lo). Se o aplicativo usar tipos de referência personalizados ou indiretos, objetos grandes válidos poderão ser excluídos erroneamente. Além disso, vacuumlo pode consumir CPU, memória e IOPS significativas, especialmente em bancos de dados com milhões de objetos grandes. Execute durante os períodos de manutenção e teste primeiro em ambientes não-produtivos.

Pós-atualização

Depois que a atualização da versão principal for concluída, recomendamos executar o comando ANALYZE em cada banco de dados para atualizar a tabela pg_statistic. Estatísticas ausentes ou obsoletas podem levar a planos de consulta incorretos, o que, por sua vez, pode prejudicar o desempenho e consumir memória excessiva.

postgres=> analyze;
ANALYZE

Exibir logs de atualização

Os logs de atualização da versão principal (PG_Upgrade_Logs) fornecem acesso direto a logs de servidor detalhados. A integração de PG_Upgrade_Logs ao processo de atualização pode ajudar a garantir uma transição mais suave e transparente para as novas versões do PostgreSQL.

Você pode configurar os logs de atualização da versão principal da mesma maneira que os logs do servidor, usando os parâmetros do servidor a seguir:

Para ativar o recurso, defina logfiles.download_enable como ON.
Para definir a retenção dos arquivos de log em dias, use logfiles.retention_days.

Configurar logs de atualização

Para começar a usar PG_Upgrade_Logs, você poderá Configurar a captura de logs do servidor PostgreSQL e logs de atualização da versão principal.

Acesse os logs de atualização por meio da interface do usuário para logs de servidor. Lá, você pode monitorar o progresso e os detalhes das atualizações de versão principal do PostgreSQL em tempo real. Essa interface do usuário fornece um local centralizado para exibir logs, para que você possa acompanhar e solucionar problemas no processo de atualização com mais facilidade.

Benefícios do uso de logs de atualização

Diagnóstico criterioso: PG_Upgrade_Logs fornece insights importantes sobre o processo de atualização. Ele captura informações detalhadas sobre as operações executadas e realça todos os erros ou avisos que ocorrem. Esse nível de detalhes é fundamental para diagnosticar e resolver problemas que podem surgir durante a atualização, para proporcionar uma transição mais suave.
Solução de problemas simplificada: com acesso direto a esses logs, você pode identificar e resolver rapidamente possíveis obstáculos de atualização, reduzir o tempo de inatividade e minimizar o impacto nas operações. Os logs servem como uma ferramenta essencial de solução de problemas, permitindo uma resolução de problemas mais eficiente e eficaz.

Observação

Há suporte para atualizações de versão principal in-loco em servidores migrados automaticamente. Após uma atualização de versão majoritária bem-sucedida feita localmente em um servidor automigrado, o formato de nome de usuário username@servername não terá mais suporte. Em vez disso, você deve usar o formato padrão: nome de usuário. Para evitar problemas de autenticação, examine e atualize cuidadosamente todas as cadeias de conexão em seus aplicativos e scripts para garantir que eles usem o formato de nome de usuário atualizado após a atualização.

Compartilhar via