Atualizações de versão principal no Banco de Dados do Azure para servidor flexível PostgreSQL

O seu servidor flexível Base de Dados do Azure para 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. Um 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. Podem incluir alterações internas e novas funcionalidades que não são retrocompatíveis com aplicações existentes.

O seu servidor flexível Base de Dados do Azure para PostgreSQL tem uma funcionalidade que realiza uma atualização importante do servidor no local. 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

O Base de Dados do Azure para PostgreSQL suporta atualizações de versões maiores no local apenas para as versões PostgreSQL atualmente suportadas. A versão alvo deve ser oficialmente suportada pelo Azure no momento da atualização. O portal do Azure impede a seleção de versões não suportadas, mas chamadas de API ou CLI que visam uma versão obsoleta falham. Consulte sempre a política de versionamento Azure PostgreSQL e o guia prático upgrade antes de iniciar uma atualização importante de versão.

Verificações da atualização

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

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

Pode fazer verificações de validação de atualização no portal Azure ou com a CLI do Azure. Para instruções, consulte Executar verificações de validação de atualização.

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

  • Sem problemas de bloqueio detetados: Verificações de Validação de Atualização concluídas com sucesso e não identificaram quaisquer problemas que bloqueiem a atualização.
  • Problemas de bloqueio detetados: Verificações de Validação de 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 as Verificações de Validação de 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 Executar verificações de validação de atualização.

Processo de atualização

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

  • Antes de iniciar a atualização, certifique-se de que o seu servidor tem pelo menos 10-20% de armazenamento 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, o seu 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 pré-verificação for concluída com êxito, o Base de Dados do Azure para PostgreSQL flexible server interrompe o serviço e cria 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.
  • Um 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 maior de um servidor no local, que está ativada para alta disponibilidade (HA), o serviço desativa o HA, realiza a atualização no servidor principal e depois reativa o 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 um 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.
  • Proteja o seu servidor Base de Dados do Azure para PostgreSQL. Após uma grande atualização de versão num servidor flexível Base de Dados do Azure para PostgreSQL, o primeiro utilizador criado no servidor, a quem é concedida a opção ADMIN, passa a ter privilégios administrativos sobre outros papéis para operações essenciais de manutenção.

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

Se uma operação de pré-verificação falhar durante uma atualização maior de versão no local, o processo de atualização para e apresenta uma mensagem de erro detalhada. As seguintes limitações conhecidas podem fazer com que a atualização falhe ou se comporte de forma inesperada:

Importante

Os requisitos de compatibilidade de atualização podem variar consoante a versão PostgreSQL de origem e destino e mudar ao longo do tempo. As listas nesta secção são uma referência geral e podem não refletir as verificações exatas para o seu caminho de upgrade. Antes de programar uma atualização, execute as verificações de validação da atualização no servidor para obter a lista atual e fidedigna de problemas que bloqueariam essa atualização específica, incluindo quaisquer requisitos relativos a slots de replicação lógica.

Configurações de servidores não suportadas

  • A geo-replicação no Base de Dados do Azure para PostgreSQL não é suportada 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, pode recriar a réplica.
  • As regras de tráfego de rede podem bloquear operações de atualização.
    • Garanta que o seu servidor flexível pode enviar e 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, a alta disponibilidade (HA) não é automaticamente reativada após a atualização. Pode ser necessário atualizar manualmente as regras do NSG e reativar o HA.
  • As vistas dependentes de pg_stat_activity não são suportadas durante atualizações de versões maiores.
  • Se estiver a atualizar do PostgreSQL 11 para uma versão mais recente, 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 autenticaçã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 falha durante a verificação prévia se houver uma extensão bloqueada num caminho de atualização afetado. A maioria dos blocos aplica-se a versões específicas de destino (e, por vezes, de origem), em vez de a todas as atualizações de versão, conforme indicado nas listas seguintes.

  • As seguintes extensões bloqueiam uma atualização direta para uma versão principal em todos os percursos de atualização. Remova-os antes da atualização e reative-os depois, se for suportado na versão de destino: session_variable, anon, age.

  • As seguintes extensões são extensões utilitárias não persistentes e devem ser eliminadas antes da atualização e recriadas depois, por design (todos os caminhos de atualização): pg_repack, hypopg, pg_partman.

  • As extensões seguintes são bloqueadas apenas em caminhos de versão específicos. Remova-os antes da atualização se a sua atualização corresponder à condição lista, e reative-os depois, se for suportado na versão alvo:

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

  • As seguintes extensões são bloqueadas quando outros objetos da base de dados dependem dos seus objetos, porque a atualização falharia de outra forma. Resolva as dependências antes da atualização:

    • pg_stat_statements: bloqueado quando outros objetos dependem da sua visão ou função, o que faria ALTER EXTENSION pg_stat_statements UPDATE com que falhassem. Remova primeiro os objetos dependentes.
    • pgcrypto: quando instalado no esquema pg_catalog e ao atualizar do PostgreSQL 11 ou 12 para o PostgreSQL 13 ou posterior, bloqueado quando os objetos do cliente dependem dele (um conflito com a função integrada gen_random_uuid()). Relocalize a extensão para outro esquema ou elimine primeiro os objetos dependentes.

Observação

Deve executar a operação 'DROP EXTENSION' para remover quaisquer extensões não suportadas antes de atualizar. Não precisa de remover a extensão da lista de autorizações.

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

Se estiver a usar PostGIS ou qualquer extensão dependente, configure o search_path parâmetro 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
  • Se não configurares corretamente o search_path, a atualização pode falhar ou danificar objetos após a atualização.

Considerações específicas do TimescaleDB

Se estiver a usar TimescaleDB, as atualizações principais de versões no local são suportadas apenas para combinações específicas de código fonte e alvo do PostgreSQL:

Versão de origem do PostgreSQL Versões alvo suportadas
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 teu caminho de atualização do TimescaleDB não estiver listado na matriz suportada, a atualização principal da versão no local fica bloqueada. Para avançar, pode eliminar a extensão TimescaleDB antes da atualização, se possível, ou usar uma abordagem alternativa de migração, como migração lado a lado com replicação lógica.

Certifique-se de que as suas versões de origem e destino estão incluídas na matriz suportada antes de iniciar a atualização.

Outras considerações de atualização

  • Gatilhos de eventos: A pré-verificação da 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. Remova todos os EVENT TRIGGER antes da atualização e volte a criá-los após a atualização para garantir uma atualização sem problemas.
  • Objetos grandes (LOs): A forma como uma atualização lida com bases de dados que contêm milhões de objetos grandes (armazenados em pg_largeobject) depende da versão principal alvo:
    • Alvo PostgreSQL 15 ou posterior: A atualização utiliza um método otimizado em massa para transferir metadados de objetos grandes, pelo que a memória e o uso temporário do disco deixam de escalar com o número de objetos grandes. Bases de dados com dezenas ou centenas de milhões de objetos grandes atualizam-se de forma fiável sem preparação extra. Não é necessário executar vacuumlo nem aumentar a escala do servidor antecipadamente para contornar o grande volume de objetos grandes, embora continue a poder executar vacuumlo para remover objetos grandes não utilizados por outras razões.
    • Alvo PostgreSQL 14 ou anterior: Bases de dados com milhões de objetos grandes podem causar falhas de atualização devido ao elevado uso de memória ou volume de log. Use a utilidade Vacuumlo para limpar objetos grandes não usados e considere escalar o seu servidor antes da atualização se muitos objetos grandes ainda estiverem em uso.

Advertência

Tenha cuidado com vacuumlo. vacuumlo Identifica objetos grandes órfãos com base em colunas de referência convencionais (OID, LO). Se a sua aplicação usar tipos de referência personalizados ou indiretos, objetos grandes válidos podem ser eliminados por engano. Além disso, vacuumlo pode consumir CPU, memória e IOPS significativos, especialmente em bases de dados com milhões de objetos grandes. Execute-o durante as janelas de manutenção e teste-o primeiro num ambiente de não produção.

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

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 Descarregar PostgreSQL e atualizar registos para começar.

Observação

As atualizações de versão principal diretamente são suportadas em servidores automaticamente migrados. Após uma atualização importante bem-sucedida no local num servidor automigrado, o formato de nome de utilizador username@servername deixou de ser suportado. Em vez disso, use o formato padrão: nome de utilizador. 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