Atualizações de versão principais no Banco de Dados do Azure para PostgreSQL

Sua instância de servidor flexível do Banco de Dados do Azure para PostgreSQL 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 de servidor flexível do Banco 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ã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 de servidor flexível do Banco de Dados do Azure para PostgreSQL possui um recurso que executa uma atualização de versão principal direta do servidor com apenas um clique. 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.

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% de armazenamento livre 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 in-place, 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 provocar 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, a instância do servidor flexível do Banco de Dados do Azure para PostgreSQL interromperá o serviço e realizará um backup implícito pouco 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.
• Um servidor flexível do Azure Database para PostgreSQL usa a ferramenta pg_upgrade para executar atualizações principais de versão no local. O serviço fornece a flexibilidade de ignorar versões e atualizar diretamente para as versões posteriores.
• Durante uma atualização de versão principal in-loco de um servidor que está habilitado para HA (alta disponibilidade), o serviço desabilita a HA, executa a atualização no servidor primário e habilita a HA novamente após a conclusão da atualização.
• 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.
• Uma atualização de 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) na instância do PostgreSQL. Esquemas maiores ou mais complexos 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. No entanto, você pode executar uma recuperação pontual para um horário anterior à atualização para restaurar a versão anterior da instância do banco de dados.
• Sua instância de servidor flexível do Banco de Dados do Azure para PostgreSQL faz uma captura instantânea do seu banco de dados durante o processo de atualização. O instantâneo é tirado antes do início da atualização. Em caso de falha na atualização, o sistema restaurará automaticamente o banco de dados para o estado anterior a partir do instantâneo.
• O PostgreSQL 16 introduz medidas de segurança baseadas em função. 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 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. Abaixo estão as limitações conhecidas que podem fazer com que a atualização falhe ou se comporte inesperadamente:

Configurações de servidor sem suporte

• Réplicas de leitura não têm suporte 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 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 habilitará novamente automaticamente após a atualização. Talvez você precise atualizar manualmente as regras do NSG e reabilitar a HA.
• Não há suporte para os slots de replicação lógica durante as atualizações de versão principais no local.
• Os servidores que usam o armazenamento SSDv2 não são elegíveis para atualizações de versão principais.
• Exibições dependentes de pg_stat_activity não são suportadas durante atualizações de versões principais.
• Se você estiver executando a atualização de PG11 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 logon.

Limitações de extensão

As atualizações de versão maior no local não dão suporte a todas as extensões do PostgreSQL. A atualização falhará durante a verificação prévia se extensões sem suporte forem encontradas.

• As extensões a seguir têm suporte para uso regular, mas bloquearão uma atualização de versão principal no local, se presente. Remova-os antes da atualização e habilite-os novamente depois, se houver suporte na versão de destino: timescaledb, , dblink, orafce. postgres_fdw
• As seguintes extensões 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 extensões a seguir não têm suporte e devem ser removidas antes da atualização. Você poderá habilitá-los novamente somente se houver suporte na versão de destino: age, , azure_ai, hll, pg_diskann, pgrouting.

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

Considerações específicas do PostGIS

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

Outras considerações de atualização

• Gatilhos de evento: atualize os gatilhos de evento de blocos de pré-verificação porque eles se conectam a comandos DDL e podem referenciar catálogos do sistema que mudam entre as versões principais – remova todos os EVENT TRIGGERs antes de atualizar e recrie-os após a atualização para garantir uma atualização tranquila.
• 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, recomendamos executar o comando ANALYZE em cada banco de dados para atualizar a tabela pg_statistic. 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

Os logs de atualização da versão principal (PG_Upgrade_Logs) fornecem acesso direto a logs de servidor detalhados. A integração de PG_Upgrade_Logs ao processo de atualização pode ajudar a garantir uma transição mais suave e transparente para as novas versões do PostgreSQL.

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

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

Configurar logs de atualização

Para começar a usar PG_Upgrade_Logs, você poderá Configurar a captura de logs do servidor PostgreSQL e logs de atualização da versão principal.

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

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

• Diagnóstico criterioso: PG_Upgrade_Logs fornece insights importantes sobre o processo de atualização. Ele captura informações detalhadas sobre as operações executadas e realça todos os erros ou avisos que ocorrem. Esse nível de detalhes é fundamental para diagnosticar e resolver problemas que podem surgir durante a atualização, para proporcionar 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 nas operações. Os logs servem como uma ferramenta essencial de solução de problemas, permitindo uma resolução de problemas mais eficiente e eficaz.

Conteúdo relacionado

• Atualização de versão principal.
• Alta disponibilidade no Banco de Dados do Azure para PostgreSQL.
• Backup e restauração no Banco de Dados do Azure para PostgreSQL.