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

Sua instância de servidor Banco de Dados do Azure para PostgreSQL flexível dá suporte às versões 18, 17, 16, 15, 14, 13, 12, 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. Uma instância flexível de servidor 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.

Sua instância do Servidor Flexível do Banco de Dados do Azure para PostgreSQL conta com um recurso que realiza uma atualização local de versão principal do servidor. 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.

Verificações de validação de atualização (versão prévia)

O Servidor Flexível do Azure Database para PostgreSQL oferece verificações de validação da atualização para ajudar a avaliar a prontidão para a atualização antes de iniciar uma atualização de versão principal.

As Verificações de Validação de Atualização executam uma série de validações de configuração e compatibilidade no servidor para identificar condições que podem fazer com que a atualização falhe ou se comporte inesperadamente. As verificações comuns incluem extensões sem suporte, slots de replicação lógica, transações preparadas, gatilhos de evento, dependências de objeto sem suporte e alterações de configuração pendentes necessárias para reinicialização.

O processo de validação foi projetado para avaliar a preparação de atualização sem iniciar a operação de atualização real. As mesmas verificações de validação também são executadas automaticamente durante o fluxo de trabalho de atualização de versão principal. Essas verificações não modificam a versão do servidor, disparam o tempo de inatividade ou reiniciam o servidor. É altamente recomendável executar verificações de validação antes de agendar uma janela de atualização de produção.

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

• Nenhum problema de bloqueio detectado: as Verificações de Validação de Atualização foram concluídas com êxito e não identificaram nenhum problema que bloqueie a atualização.
• Problemas de bloqueio detectados: verificações de validação de atualização identificaram um ou mais problemas que devem ser resolvidos antes que a atualização possa continuar.

Dependendo dos resultados, você pode prosseguir com a atualização ou corrigir os problemas relatados e executar novamente a validação.

Limitações

Ao usar as Verificações de Validação de Atualização, considere as seguintes limitações:

• O estado do servidor deve estar Ready.
• As verificações de validação não são compatíveis em réplicas de leitura.
• A validação não pode ser executada enquanto outra operação de servidor já estiver em andamento.
• As verificações de validação exigem conectividade com todos os bancos de dados no servidor. Bancos de dados sem resposta 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 atividade de banco de dados inferior.

Para obter instruções passo a passo, consulte Executar verificações de validação de atualização (versão prévia).

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% armazenamento gratuito 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, sua instância de servidor flexível do Banco de Dados do Azure para PostgreSQL executa um procedimento de pré-verificação para identificar possíveis problemas que possam resultar em falha na atualização.
  • 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 Banco de Dados do Azure para PostgreSQL instância de servidor flexível interromperá o serviço e realizará um backup implícito pouco antes de iniciar a atualização. O serviço pode usar esse backup implícito para restaurar a instância do banco de dados para sua versão anterior se houver um erro de atualização.
• Uma instância de servidor flexível do Banco de Dados do Azure para PostgreSQL usa a ferramenta pg_upgrade para executar atualizações de versão principais no local. O serviço fornece a flexibilidade de ignorar versões e atualizar diretamente para as versões posteriores.
• Durante uma atualização local de versão principal de um servidor configurado para alta disponibilidade (HA), o serviço desabilita a HA, executa a atualização no servidor primário e, em seguida, reativa a HA após a conclusão da atualização. Habilitar novamente a HA requer capacidade suficiente para provisionar uma nova instância em espera.
• 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 atualização de versão principal in-loco para uma instância de servidor flexível do Banco de Dados do Azure para PostgreSQL implanta automaticamente a versão secundária mais recente suportada.
• A duração da atualização depende do tamanho e da complexidade do banco de dados, incluindo o número de objetos (tabelas, índices, esquemas), objetos grandes e extensões. Cargas de trabalho maiores ou mais complexas 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. Você pode realizar uma recuperação pontual (PITR) para um momento anterior à atualização, a fim de restaurar a versão anterior em um novo servidor.
• Sua instância de servidor Banco de Dados do Azure para PostgreSQL flexível faz um backup implícito do banco de dados durante uma atualização. O backup implícito é feito antes do início da atualização. Se a atualização falhar, o sistema restaurará automaticamente seu banco de dados para seu estado do backup implícito.
• Proteja as medidas de segurança do servidor Banco de Dados do Azure para PostgreSQL. Após uma atualização de versão principal em uma instância de servidor Banco de Dados do Azure para PostgreSQL flexível, o primeiro usuário criado no servidor, que recebe a opção ADMIN, agora tem 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. Veja a seguir 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 a replicação geográfica no Banco de Dados do Azure para PostgreSQL durante 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, você pode recriar a réplica.
• As regras de tráfego de rede podem bloquear as operações de atualização.
  • Verifique se sua instância de servidor flexível pode enviar/receber tráfego nas portas 5432 e 6432 em sua rede virtual e para Armazenamento do Azure (para arquivamento de log).
  • 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 seja necessário atualizar manualmente as regras do NSG e reativar a HA.
• Os slots de replicação lógica devem ser descartados antes de executar uma atualização de versão principal no local. Você pode recriá-los após a conclusão da atualização.
• Visualizações dependentes de pg_stat_activity não têm suporte durante atualizações para versões principais.
• Se você estiver executando a atualização do PostgreSQL 11 para uma versão mais alta, primeiro configure seu servidor flexível para usar a autenticação SCRAM habilitando SCRAM e redefinindo todas as senhas de função de logon.

Limitações de extensão

As atualizações in-place de versão principal não oferecem suporte a todas as extensões do PostgreSQL. A atualização falhará durante a verificação prévia se uma extensão bloqueada estiver presente em um caminho de atualização afetado. A maioria dos blocos tem como escopo versões específicas de destino (e às vezes de origem) em vez de todas as atualizações, conforme observado nas listas a seguir.

• As extensões a seguir bloqueiam uma atualização de versão maior no local em todos os caminhos de atualização. Remova-os antes da atualização e habilite-os novamente depois, se houver suporte na versão de destino: session_variable, , anon, age. pg_duckdb

• As extensões a seguir são extensões de utilitário não persistentes e devem ser descartadas antes da atualização e recriadas depois, por design (todos os caminhos de atualização): pg_repack, , hypopgpg_partman.

• As extensões a seguir são bloqueadas apenas em caminhos de versão específicos. Remova-os antes da atualização se a atualização corresponder à condição listada e habilite-as novamente depois, se houver suporte na versão de destino:

  Extension	Bloqueado quando
  pg_hint_plan	A versão de destino é PostgreSQL 14
  semver	A versão de destino é PostgreSQL 16 ou 17
  azure_local_ai	A versão de destino é PostgreSQL 17 ou 18
  pg_failover_slots	A versão de destino é PostgreSQL 17 ou 18 (biblioteca de pré-carregamento compartilhada)
  azure_ai	A versão de destino é PostgreSQL 18
  azure_storage	A versão de destino é PostgreSQL 18
  pg_diskann	A versão de destino é PostgreSQL 18
  pgrouting	A versão de destino é PostgreSQL 15; ou a origem é anterior ao PostgreSQL 16 e o destino é PostgreSQL 16 ou posterior; ou a versão de destino é PostgreSQL 18
  orafce	A versão de origem é PostgreSQL 11, 12 ou 13

• As extensões a seguir são bloqueadas quando outros objetos de banco de dados dependem de seus objetos, pois a atualização falhará de outra forma. Resolva as dependências antes da atualização:

  • pg_stat_statements: bloqueado quando outros objetos dependem de sua exibição ou função, o que causaria ALTER EXTENSION pg_stat_statements UPDATE falha. Remova os objetos dependentes primeiro.
  • pgcrypto: quando instalado no esquema pg_catalog e ao atualizar do PostgreSQL 11 ou 12 para o PostgreSQL 13 ou superior, fica bloqueado se houver objetos do cliente que dependam dele (um conflito com a função interna gen_random_uuid()). Realoque a extensão para outro esquema ou solte os objetos dependentes primeiro.

Considerações específicas do PostGIS

Se você estiver usando o PostGIS ou quaisquer extensões dependentes, deverá configurar o parâmetro search_path 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.

Considerações específicas do TimescaleDB

Se você estiver usando TimescaleDB, há suporte para atualizações locais de versão principal apenas para combinações específicas entre versões de origem e de destino do PostgreSQL:

Se o caminho de atualização do TimescaleDB não constar na matriz de compatibilidade, a atualização in-loco de versão principal será bloqueada. Para continuar, remova a extensão TimescaleDB antes da atualização, se viável, ou use uma abordagem de migração alternativa, como migração lado a lado com replicação lógica.

Verifique se as versões de origem e de destino estão incluídas na matriz com suporte antes de iniciar a atualização.

Outras considerações de atualização

• Gatilhos de evento: a pré-verificação da atualização bloqueia os gatilhos de evento porque eles se vinculam aos comandos DDL e podem fazer referência a catálogos do sistema que mudam entre versões principais. Remova todos os EVENT TRIGGERs antes de atualizar e recrie-os após a 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 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.

Pós-atualização

Depois que a atualização da versão principal for concluída, execute o ANALYZE comando em cada banco 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 prejudicar o desempenho e consumir memória excessiva.

postgres=> analyze;
ANALYZE

Exibir logs de atualização

Use PG_Upgrade_Logs para monitorar o progresso da atualização e solucionar problemas.

Habilitar logs de atualização usando parâmetros de log do servidor

• Definido logfiles.download_enable como ON.
• Configurar a retenção com logfiles.retention_days.

Confira Baixar PostgreSQL e logs de atualização para começar.

Acesse PG_Upgrade_Logs pela interface de logs do servidor

• Examine PG_Upgrade_Logs durante e após a atualização para monitorar o progresso e diagnosticar falhas ou atrasos.
• Verifique se há erros ou avisos se a atualização falha ou demora mais do que o esperado.
• Use logs para identificar problemas de bloqueio e executar uma ação corretiva rapidamente.

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

• Diagnosticar problemas rapidamente: use PG_Upgrade_Logs para examinar cada etapa da atualização e identificar erros ou avisos.
• Solucionar problemas com eficiência: analise logs para identificar falhas, reduzir o tempo de inatividade e tomar medidas corretivas mais rapidamente.

PG_Upgrade_Logs ajuda você a entender o que aconteceu durante a atualização e resolver problemas com confiança.

Conteúdo relacionado

• Atualização de versão principal
• Executar verificações de validação de atualização (versão prévia)