Partilhar via

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

  • Artigo

APLICA-SE A: Banco de Dados do Azure para PostgreSQL - Servidor Flexível

O servidor flexível do Banco de Dados do Azure para PostgreSQL dá suporte às versões 16, 15, 14, 13, 12 e 11 do PostgreSQL. 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 com versões anteriores de aplicativos existentes. O 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.

O servidor flexível do Banco de Dados do Azure para PostgreSQL tem um recurso que executa uma atualização de versão principal in-loco 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 in-loco mantêm o nome do servidor e outras configurações do servidor atual após a atualização de uma versão principal. 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.

Processo

Aqui estão algumas das considerações importantes com as atualizações de versão principal in-loco:

  • Durante o processo de uma atualização de versão principal in-loco, 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 causar falha na atualização.

    Se a pré-verificação encontrar alguma incompatibilidade, 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, o servidor flexível 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.

  • O servidor flexível do Banco de Dados do Azure para PostgreSQL usa a ferramenta pg_upgrade para executar atualizações de versão principal in-loco. O serviço oferece a flexibilidade de pular versões e atualizar diretamente para versões posteriores.

  • Durante uma atualização de versão principal in-loco de um servidor habilitado para alta disponibilidade (HA), o serviço desabilita a HA, executa a atualização no servidor primário 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 versão principal in-loco, com algumas exceções.

  • O processo de uma atualização de versão principal in-loco para o Banco de Dados do Azure para o servidor flexível PostgreSQL implanta automaticamente a versão secundária com suporte mais recente.

  • Uma atualização de versão principal in-loco é uma operação offline que resulta em um breve período de inatividade. O tempo de inatividade é normalmente inferior a 15 minutos. A duração pode variar, dependendo do número de tabelas do sistema envolvidas.

  • 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 de versão principal in-loco for bem-sucedida, não há maneiras automatizadas de reverter para a versão anterior. No entanto, você pode executar uma recuperação point-in-time (PITR) para um tempo antes da atualização para restaurar a versão anterior da instância do banco de dados.

Pós-atualização/migraçã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. Caso contrário, você pode ter problemas de desempenho.

postgres=> analyze;
ANALYZE

Logs de atualização da versão principal

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.

Configuração de logs de atualização

Para começar a usar PG_Upgrade_Logso , você pode configurar os logs por meio do portal do Azure ou da CLI do Azure. Escolha o método que melhor se adapta ao seu fluxo de trabalho.

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.

Limitações

Se as operações de pré-verificação falharem para uma atualização de versão principal in-loco, a atualização falhará com uma mensagem de erro detalhada para todas as seguintes limitações:

  • Atualmente, as atualizações de versão principal in-loco não suportam réplicas de leitura. Se você tiver um servidor que atua como uma réplica de leitura, precisará excluir a réplica antes de executar a atualização no servidor primário. Após a atualização, pode recriar a réplica.

  • O Banco de Dados do Azure para PostgreSQL - Servidor Flexível requer a capacidade de enviar e receber tráfego para as portas de destino 5432 e 6432 na rede virtual onde o servidor flexível é implantado e para o Armazenamento do Azure para arquivamento de logs.

    Se você configurar grupos de segurança de rede (NSGs) para restringir o tráfego de ou para seu servidor flexível dentro de sua sub-rede implantada, certifique-se de permitir o tráfego para as portas de destino 5432 e 6432 dentro da sub-rede. Permita o tráfego para o Armazenamento do Azure usando a marca de serviço Armazenamento do Azure como destino.

    Se as regras de rede não estiverem configuradas corretamente, a HA não será ativada automaticamente após uma atualização da versão principal e você deverá habilitar manualmente a HA. Modifique suas regras NSG para permitir o tráfego para as portas de destino e armazenamento e para habilitar um recurso HA no servidor.

  • As atualizações de versão principal in-loco não suportam determinadas extensões e existem algumas limitações para atualizar determinadas extensões. As seguintes extensões não são suportadas para todas as versões do PostgreSQL: Timescaledb, pgaudit, dblink, orafce, pg_partman, postgres_fdw.

  • Quando você estiver atualizando servidores com a extensão PostGIS instalada, defina o search_path parâmetro server para incluir explicitamente:

    • Esquemas da extensão PostGIS.
    • Extensões que dependem do PostGIS.
    • Extensões que servem como dependências para as seguintes extensões: , , , , , , , ( fuzzystrmatch necessário para postgis_tiger_geocoder). address_standardizer_data_usaddress_standardizerpostgis_topologypostgis_tiger_geocoderpostgis_sfcgalpostgis_rasterpostgis

  • Os servidores configurados com blocos de replicação lógica não são suportados.

Próximos passos