Partilhar via

Atualizações de versões principais no Azure Database para PostgreSQL

A sua instância de servidor flexível Azure Database for PostgreSQL suporta PostgreSQL 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 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õ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 do Azure Database para PostgreSQL possui um recurso que realiza uma atualização no local da maior versão do servidor 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.

Observação

A Base de Dados do Azure para PostgreSQL suporta atualizações de versão principal no local apenas para versões do PostgreSQL atualmente suportadas. Por exemplo, você pode atualizar a versão atual dado que a versão de destino é oficialmente suportada pelo Azure no momento da atualização. As versões sem suporte não podem ser selecionadas como destinos de atualização e a tentativa de atualizar para uma versão preterida pode resultar em falha ou interrupção do serviço. Consulte sempre a política de versão do Azure PostgreSQL e a documentação de atualização antes de iniciar uma atualização de versão principal.

Observação

As principais atualizações de versões para o PostgreSQL 18 estão a ser ativadas em fases. Neste momento, o MVU para PostgreSQL 18 está disponível nas regiões AustráliaSudeste, CanadáCentral, CentroÍndia, CentroEUA, Leste Asiático, LesteUS, LesteUS2, NorteCentralEUA, África do SulNorte, SulCentral dos EUA, Suécia Central, WestCentralUS, WestUS2 e WestUS3.

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, arquivos de log 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 atualização de versão principal no local, a 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 falhar na 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 pré-verificação for bem-sucedida, a instância flexível do servidor do Banco de Dados do Azure para PostgreSQL interromperá o serviço e fará um backup implícito 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.
  • 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 major 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.
  • 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 para uma versão principal no local de uma instância de servidor flexível do Banco de Dados do Azure para PostgreSQL implanta automaticamente a versão secundária mais recente com suporte.
  • Uma atualização para uma nova 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) em sua instância do PostgreSQL. Esquemas maiores ou mais complexos 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. No entanto, você pode executar uma recuperação pontual (PITR) para um momento anterior à atualização para restaurar a versão anterior da instância do banco de dados.
  • Durante uma atualização, a sua instância de servidor flexível do Azure Database para PostgreSQL faz uma captura instantânea do seu banco de dados. O instantâneo é tirado antes do início da atualização. Se a atualização falhar, o sistema restaurará automaticamente o banco de dados ao seu estado a partir do snapshot.
  • O PostgreSQL 16 introduz medidas de segurança baseadas em funções . Após uma atualização de versão principal em uma instância de 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 sobre outras funções para operações de manutenção essenciais.

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 servidor não suportadas

  • Durante as atualizações no local, não há suporte para réplicas de leitura. 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 as operações de atualização.
    • Certifique-se de que sua instância de servidor flexível possa 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 reativará automaticamente após a atualização. Talvez seja necessário atualizar manualmente as regras do NSG e reativar o HA.
  • Não há suporte para slots de replicação lógica durante atualizações de versão major no local.
  • Os servidores que utilizam armazenamento SSDv2 não são elegíveis para atualizações de versões principais.
  • Visualizações dependentes de pg_stat_activity não são suportadas durante atualizações de versão principal.
  • Se você estiver executando a atualização do PG11 para uma versão superior, você deve primeiro configurar seu servidor flexível para usar a autenticação SCRAM , habilitando o SCRAM e redefinindo todas as senhas de função de login.

Limitações de extensão

As atualizações de versão principal locais 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. Removê-los antes da atualização e reativá-los depois, se suportado na versão de destino: timescaledb, dblink, orafce, postgres_fdw.
  • 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 o PostgreSQL 17, as seguintes extensões não são suportadas e devem ser removidas antes da atualização. Você pode reativá-los apenas se eles forem suportados na versão de destino: age, azure_ai, hll, pg_diskann, pgrouting.

Observação: Se qualquer uma dessas extensões aparecer no parâmetro server azure.extensions , a atualização será bloqueada. Remova-os do parâmetro antes de iniciar a atualização.

PostGIS-Specific Considerações

Se estiver a utilizar PostGIS ou quaisquer extensões dependentes, tem de configurar o parâmetro search_path server 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 pré-verificação de atualização bloqueia gatilhos de eventos porque eles se conectam a comandos DDL e podem fazer referência a catálogos do sistema que mudam entre as versões principais — solte todos os EVENT TRIGGERs antes da atualização e depois recrie-os após a atualização para garantir uma atualização suave.
  • 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.

Advertência

Tenha cuidado com o aspirador. vacuumlo Identifica objetos grandes órfãos com base em colunas de referência convencionais (OID, LO). Se seu aplicativo usa tipos de referência personalizados ou indiretos, objetos grandes válidos podem ser excluídos por engano. 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 as janelas de manutenção e teste primeiro no ambiente não-produtivo.

Pós-atualização

Após a conclusão da atualização da versão principal, recomendamos executar 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 degradar o desempenho e ocupar 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 aos logs detalhados do servidor. A integração PG_Upgrade_Logs em seu processo de atualização pode ajudar a garantir uma transição mais suave e transparente para novas versões do PostgreSQL.

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

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

Configurar logs de atualização

Para começar a usar PG_Upgrade_Logs, pode configurar a captura de logs do servidor PostgreSQL e logs de atualização para uma versão principal.

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

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

  • Diagnósticos perspicazes: PG_Upgrade_Logs fornecem informações valiosas sobre o processo de atualização. Ele captura informações detalhadas sobre as operações realizadas e destaca quaisquer erros ou avisos que ocorram. Esse nível de detalhe é fundamental para diagnosticar e resolver problemas que possam surgir durante a atualização, para 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 em suas operações. Os logs servem como uma ferramenta crucial de solução de problemas, permitindo uma resolução de problemas mais eficiente e eficaz.

Observação

As atualizações de versão principal diretamente são suportadas em servidores automaticamente migrados. Após uma Atualização de Versão Principal local bem-sucedida em um servidor com migração automática, o formato nome de usuário username@servername não será mais suportado. Em vez disso, você deve usar o formato padrão: username. Para evitar problemas de autenticação, revise 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