Atualizações principais de versões em Base de Dados do Azure para PostgreSQL

A sua instância de servidor flexível Base de Dados do Azure para PostgreSQL suporta as versões 18, 17, 16, 15, 14, 13, 12, 11. A comunidade Postgres lança uma nova versão principal que contém novos recursos cerca de uma vez por ano. Além disso, cada versão principal recebe correções periódicas de bugs na forma de versões menores. As atualizações de versões secundárias incluem alterações que são compatíveis retroativamente com aplicações existentes. Uma instância de servidor flexível do Base de Dados do Azure para PostgreSQL atualiza periodicamente as versões menores durante a janela de manutenção do cliente.

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

A sua instância de servidor flexível Base de Dados do Azure para PostgreSQL tem uma funcionalidade que realiza uma atualização maior e significativa do servidor no local com apenas um clique. Esse recurso simplifica o processo de atualização, minimizando a interrupção para 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 major. Eles não exigem migração de dados ou alterações nas cadeias de conexão do aplicativo. As atualizações no local são mais rápidas e envolvem um período de indisponibilidade mais curto do que a migração de dados.

Verificações de validação antes da atualização (Pré-visualização)

O servidor flexível Base de Dados do Azure para PostgreSQL fornece Verificações de Validação Pré-Atualização (PVC) para ajudar a avaliar a prontidão da atualização antes de iniciar uma grande atualização de versão.

As Verificações de Validação Pré-Atualização executam uma série de validações de compatibilidade e configuração contra o servidor para identificar condições que possam causar falhas ou comportamentos inesperados da atualização. Verificações comuns incluem extensões não suportadas, slots de replicação lógica, transações preparadas, gatilhos de eventos, dependências de objetos não suportadas e alterações de configuração pendentes que exigem reinícios.

O processo de validação é concebido para avaliar a prontidão da atualização sem iniciar a operação real da atualização. As mesmas verificações de validação também são realizadas automaticamente durante o fluxo de trabalho de atualização de versões principais. Estas verificações não modificam a versão do servidor, não ativam o tempo de inatividade nem reiniciam o servidor. Recomendamos vivamente a realização de verificações de validação antes de agendar uma janela de atualização de produção.

Após a conclusão da validação, é devolvido um dos seguintes resultados:

• Não foram detetados problemas de bloqueio: Verificações de Validação Pré-Atualização concluídas com sucesso e não identificaram quaisquer problemas que pudessem bloquear a atualização.
• Problemas de bloqueio detetados: As Verificações de Validação Pré-Atualização identificaram um ou mais problemas que devem ser resolvidos antes que a atualização possa avançar.

Dependendo dos resultados, pode avançar com a atualização ou remediar os problemas reportados e reexecutar a validação.

Limitações

Ao utilizar Verificações de Validação Pré-Atualização, considere as seguintes limitações:

• O estado do servidor deve ser Pronto.
• Verificações de validação não são suportadas em réplicas de leitura.
• A validação não pode correr enquanto outra operação de servidor já estiver em curso.
• As verificações de validação requerem conectividade a todas as bases de dados do servidor. Bases de dados pouco responsivas ou inacessíveis podem causar falhas de validação.
• Embora as verificações de validação não causem tempo de inatividade, considere executá-las durante períodos de menor atividade na base de dados.

Para instruções passo a passo, veja Como executar Verificações de Validação Pré-Atualização.

Processo de atualização

Aqui estão algumas das considerações importantes com as atualizações de versão principal no local:

• Antes de iniciar a atualização, verifique se o servidor tem entre 10 a 20% de espaço livre disponível. Durante o processo de atualização, ficheiros de registo temporários e 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 maior de versão no local, a sua instância de servidor flexível Base de Dados do Azure para PostgreSQL executa um procedimento de precheck para identificar eventuais problemas que possam causar a falha da atualização.
  • Se a pré-verificação encontrar alguma incompatibilidade, ela criará um evento de log que mostra que a pré-verificação da atualização falhou, juntamente com uma mensagem de erro.
  • Se a verificação prévia for bem-sucedida, a instância de servidor flexível do Base de Dados do Azure para PostgreSQL interrompe o serviço e faz uma cópia de segurança implícita pouco antes de iniciar a atualização. O serviço pode usar este backup implícito para restaurar a instância da base de dados à sua versão anterior caso haja um erro de atualização.
• Uma instância de servidor Base de Dados do Azure para PostgreSQL flexível utiliza a ferramenta pg_upgrade para realizar atualizações maiores de versões no local. O serviço oferece a flexibilidade de pular versões e atualizar diretamente para versões posteriores.
• Durante uma atualização para uma versão principal in-loco de um servidor habilitado para alta disponibilidade (HA), o serviço desativa a HA, executa a atualização no servidor principal e reativa a HA após a conclusão da atualização. Reativar a HA requer capacidade suficiente para provisionar uma nova instância de espera.
• A maioria das extensões é atualizada automaticamente para versões posteriores durante uma atualização de uma versão principal no local, com algumas exceções.
• O processo de atualização de uma versão maior no local para uma instância de servidor flexível do Base de Dados do Azure para PostgreSQL implementa automaticamente a versão menor suportada mais recente.
• A duração da atualização depende do tamanho e complexidade da sua base de dados, incluindo o número de objetos (tabelas, índices, esquemas), objetos grandes e extensões. Cargas de trabalho maiores ou mais complexas podem ter tempos de atualização mais longos.
• Transações de longa duração 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 uma atualização local da versão principal for bem-sucedida, não há maneiras automatizadas de reverter para a versão anterior. Pode realizar uma recuperação pontual no tempo (PITR) até um momento antes da atualização para restaurar a versão anterior num novo servidor.
• A sua instância de servidor flexível Base de Dados do Azure para PostgreSQL faz uma cópia de segurança implícita da sua base de dados durante uma atualização. A cópia de segurança implícita é feita antes do início da atualização. Se a atualização falhar, o sistema restaura automaticamente a sua base de dados ao seu estado a partir da cópia de segurança implícita.
• O PostgreSQL 16 introduz medidas de segurança baseadas em funções . Após uma grande atualização de versão numa instância de servidor flexível do Base de Dados do Azure para PostgreSQL, o primeiro utilizador criado no servidor — a quem é concedida a opção ADMIN — terá agora privilégios administrativos sobre outras funções para operações essenciais de manutenção.

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

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

Configurações de servidores não suportadas

• As réplicas de leitura não são suportadas durante as atualizações no local. Você deve excluir a réplica de leitura (incluindo qualquer réplica de leitura em cascata) antes de atualizar o servidor primário. Após a atualização, pode recriar a réplica.
• As regras de tráfego de rede podem bloquear operações de atualização.
  • Garanta que a sua instância de servidor flexível pode enviar/receber tráfego nas portas 5432 e 6432 dentro da sua rede virtual e para o Armazenamento do Azure (para arquivamento de logs).
  • Se os Grupos de Segurança de Rede (NSGs) restringirem este tráfego, o HA não reativará automaticamente após a atualização. Pode ser necessário atualizar manualmente as regras do NSG e reativar o HA.
• Os slots de replicação lógica devem ser removidos antes de realizar uma atualização principal de versão no local. Podes recriá-los depois de a atualização estar concluída.
• As vistas dependentes de pg_stat_activity não são suportadas durante atualizações de versões maiores.
• Se estiver a realizar a atualização de PG11 para uma versão superior, deve primeiro configurar o seu servidor flexível para usar autenticação SCRAM, ativando a autenticação SCRAM e redefinindo as palavras-passe de todas as funções de início de sessão.

Limitações de extensão

As atualizações principais de versões no local não suportam todas as extensões PostgreSQL. A atualização falhará durante a pré-verificação se forem encontradas extensões não suportadas.

• As extensões a seguir são suportadas para uso regular, mas bloquearão uma atualização de versão principal no local, se estiverem presentes. Remova-os antes da atualização e reative-os depois, se for suportado na versão alvo: timescaledb, postgres_fdw, session_variable, pg_hint_plan, plv8.
• As extensões a seguir são extensões de utilitário não persistentes e precisarão ser descartadas e recriadas após a atualização por design: pg_repack, hypopg.
• Ao atualizar para PostgreSQL 17 e superiores, as seguintes extensões não são suportadas e devem ser removidas antes da atualização. Só pode voltar a ativá-los se for suportado na versão alvo: age, azure_ai, hll, pg_diskann, pgrouting.

Considerações específicas pós-GIS

Se estiver a usar PostGIS ou quaisquer extensões dependentes, deve configurar o parâmetro de search_path para incluir:

• Esquemas relacionados com PostGIS
• Extensões dependentes, incluindo: postgis, postgis_raster, postgis_sfcgal, postgis_tiger_geocoder, postgis_topology, address_standardizer, address_standardizer_data_us, fuzzystrmatch
• 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

• Gatilhos de eventos: A verificação prévia à atualização bloqueia os gatilhos de eventos porque estão associados a comandos DDL e podem fazer referência a catálogos do sistema que mudam entre versões principais — elimine todos os EVENT TRIGGER antes de atualizar e recrie-os depois da atualização para garantir uma atualização sem problemas.
• 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 volume de log. Use o utilitário vacuumlo para limpar LOs não utilizados e considere dimensionar seu servidor antes de atualizar se muitos LOs ainda estiverem em uso.

Pós-atualização

Após a atualização principal da versão estar concluída, execute o ANALYZE comando em cada base de dados para atualizar a pg_statistic tabela. Estatísticas ausentes ou obsoletas podem levar a planos de consulta incorretos, o que, por sua vez, pode degradar o desempenho e ocupar memória excessiva.

postgres=> analyze;
ANALYZE

Exibir logs de atualização

Uso PG_Upgrade_Logs para monitorizar o progresso das atualizações e resolver problemas.

Ativar registos de atualização usando parâmetros do registo do servidor

• Definir logfiles.download_enable para ON.
• Configure a retenção com logfiles.retention_days.

Consulte Configurar captura dos registos do servidor PostgreSQL e dos registos de atualização de versões principais para começar.

Acede PG_Upgrade_Logs a partir da interface de registos do servidor

• Revise PG_Upgrade_Logs durante e após a atualização para monitorizar o progresso e diagnosticar falhas ou atrasos.
• Verifique se há erros ou avisos se a atualização falhar ou demorar mais do que o esperado.
• Use registos para identificar problemas de bloqueio e tomar medidas corretivas rapidamente.

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

• Diagnosticar problemas rapidamente: Use PG_Upgrade_Logs para rever cada etapa da atualização e identificar erros ou avisos.
• Solucione problemas de forma eficiente: Analise registos para identificar falhas, reduzir o tempo de inatividade e tomar medidas corretivas mais rapidamente.

PG_Upgrade_Logs Ajuda-te a perceber o que aconteceu durante a atualização e a resolver os problemas com confiança.

Conteúdo relacionado

• Atualização da versão principal.
• Verificações de validação pré-atualização.