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

Seu 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. Um servidor Banco de Dados do Azure para PostgreSQL flexível 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. Podem incluir alterações internas e novos recursos que não são retrocompatíveis com os aplicativos existentes.

Seu servidor flexível do Banco de Dados do Azure para PostgreSQL conta com um recurso que executa uma atualização local da 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.

Observação

Banco de Dados do Azure para PostgreSQL dá suporte a atualizações de versão principais no local apenas para versões do PostgreSQL atualmente suportadas. A versão de destino deve ter suporte oficial do Azure no momento da atualização. O portal Azure impede a seleção de versões sem suporte, mas as chamadas à API ou à CLI direcionadas a uma versão preterida falham. Sempre consulte a política de versionamento do Azure PostgreSQL e o guia de instruções de atualização antes de iniciar uma atualização de versão principal.

Atualizar verificações de validação

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. Execute verificações de validação antes de agendar uma janela de atualização de produção.

Você pode executar verificações de validação de atualização no portal do Azure ou com o CLI do Azure. Para obter instruções, consulte Executar verificações de validação de atualizaçã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.

Processo de atualização

Aqui estão algumas considerações importantes para atualizações principais de versão no local:

  • 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 local de versão principal, o 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 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 Banco de Dados do Azure para PostgreSQL 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.
  • Um servidor flexível do Banco de Dados do Azure para PostgreSQL usa a ferramenta pg_upgrade para realizar atualizações in-loco da versão principal. 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 in-loco de versão principal de um servidor flexível do Banco de Dados do Azure para PostgreSQL implanta automaticamente a versão secundária mais recente com suporte.
  • 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.
  • Proteja seu servidor Banco de Dados do Azure para PostgreSQL. Após uma atualização de versão principal em um 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 verificação prévia falhar durante uma atualização local da versão principal, o processo de atualização será interrompido, e uma mensagem de erro detalhada será exibida. As seguintes limitações conhecidas podem fazer com que a atualização falhe ou se comporte inesperadamente:

Importante

Os requisitos de compatibilidade para atualização podem variar dependendo das versões de origem e de destino do PostgreSQL e podem mudar ao longo do tempo. As listas nesta seção são uma referência geral e podem não refletir as verificações exatas do caminho de atualização. Antes de agendar uma atualização, execute verificações de validação de atualização em seu servidor para obter o conjunto atual e autoritativo de problemas que bloqueariam sua atualização específica , incluindo quaisquer requisitos de slot de replicação lógica.

Configurações de servidor sem suporte

  • A georreplicação no Banco de Dados do Azure para PostgreSQL não é compatível 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 o servidor flexível pode enviar e 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 ALTA DISPONIBILIDADE (HA) não será habilitada automaticamente após a atualização. Talvez seja necessário atualizar manualmente as regras do NSG e reativar a HA.
  • Visualizações dependentes de pg_stat_activity não têm suporte durante atualizações para versões principais.
  • Se você estiver atualizando do PostgreSQL 11 para uma versão mais alta, primeiro deverá configurar seu servidor flexível para usar a autenticação SCRAM habilitando SCRAM e redefinindo todas as senhas de função de autenticação.

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, , anonage.

  • 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.

Observação

Você deve executar a operação 'DROP EXTENSION' para remover extensões sem suporte antes de atualizar. Você não precisa remover a extensão da lista de permissões.

Considerações específicas do PostGIS

Se você estiver usando o PostGIS ou quaisquer extensões dependentes, configure o search_path parâmetro 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
  • Se você não configurar o search_path corretamente, a atualização poderá falhar ou corromper objetos 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:

Versão do PostgreSQL de origem Versões de destino com suporte
PostgreSQL 11 PostgreSQL 12
PostgreSQL 12 PostgreSQL 13, 14, 15
PostgreSQL 13 PostgreSQL 14, 15, 16
PostgreSQL 14 PostgreSQL 15, 16
PostgreSQL 15 PostgreSQL 16, 17, 18
PostgreSQL 16 PostgreSQL 17, 18
PostgreSQL 17 PostgreSQL 18

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): a maneira como uma atualização lida com bancos de dados que contêm milhões de objetos grandes (armazenados) pg_largeobjectdepende da versão principal de destino:
    • PostgreSQL 15 ou posterior como destino: a atualização usa um método otimizado em lote para transferir metadados de objetos grandes, de modo que o uso de memória e de disco temporário não aumenta mais com o número de objetos grandes. Bancos de dados com dezenas ou centenas de milhões de objetos grandes são atualizados de forma confiável sem preparação extra. Executar vacuumlo ou dimensionar o servidor com antecedência não é necessário para contornar o volume de objetos grandes, embora você ainda possa executar vacuumlo para remover objetos grandes não utilizados por outros motivos.
    • PostgreSQL de destino versão 14 ou anterior: bancos de dados com milhões de objetos grandes podem causar falhas na atualização devido ao uso elevado de memória ou ao volume de logs. Use o utilitário vacuumlo para limpar objetos grandes não utilizados e considere dimensionar o servidor antes da atualização se muitos objetos grandes ainda estiverem em uso.

Aviso

Tenha cuidado com 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 isso em janelas de manutenção e teste primeiro em um ambiente de não produção.

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. Examine os logs durante e após a atualização para acompanhar o progresso, diagnosticar falhas ou atrasos e identificar problemas de bloqueio para que você possa tomar medidas corretivas rapidamente.

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.

Observação

Há suporte para atualizações de versão principal in-loco em servidores migrados automaticamente. Após uma atualização local bem-sucedida para uma nova versão principal em um servidor automigrado, o formato de nome de usuário username@servername não é mais compatível. Em vez disso, use 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.

Conteúdo relacionado

  • Last updated on