Share 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 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. As atualizações de versão secundária incluem alterações compatíveis com versões anteriores com 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ã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.

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

Processar

Veja abaixo algumas considerações importantes sobre 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 verificação prévia para identificar possíveis problemas que possam causar 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, o servidor flexível do Banco de Dados do Azure para PostgreSQL interromperá o serviço e usará 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.

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

  • O processo de uma atualização de versão principal in-loco para o 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 de versão principal in-loco é uma operação offline que resulta em um breve período de tempo de inatividade. O tempo de inatividade normalmente é menor que 15 minutos. A duração pode variar, dependendo do número de tabelas do sistema envolvidas.

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

Logs de atualização da versão principal

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.

Instalação dos logs de atualização

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

Você pode acessar 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.

Limitações

Em caso de falha nas operações de pré-verificação 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:

  • No momento, as atualizações de versão principal in-loco não dão suporte a réplicas de leitura. Se você tiver um servidor que atua como uma réplica de leitura, precisará excluir a réplica para executar a atualização no servidor primário. Após a atualização, você 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 dentro na rede virtual em que o servidor flexível está implantado e para o Armazenamento do Azure para arquivamento de log.

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

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

  • As atualizações de versão principal in-loco não dão suporte a certas extensões e há algumas limitações para atualizar certas extensões. As seguintes extensões não têm suporte para todas as versões do PostgreSQL: Timescaledb, pgaudit, dblink, orafce, pg_partman, postgres_fdw.

  • Quando estiver atualizando os servidores com a extensão PostGIS instalada, defina o parâmetro do servidor search_path para incluir explicitamente:

    • Esquemas da extensão PostGIS.
    • Extensões que dependem do PostGIS.
    • Extensões que atuam como dependências para as seguintes extensões: postgis, postgis_raster, postgis_sfcgal, postgis_tiger_geocoder, postgis_topology, address_standardizer, address_standardizer_data_us, fuzzystrmatch (necessário para postgis_tiger_geocoder).

  • Não há suporte para os servidores configurados com slots de replicação lógica.

Próximas etapas