Extensões e objetos de replicação lógica a serem analisados

Verifique os itens a seguir antes da atualização:

Extensões

• pg_repack
• old_snapshot
• wal2json
• anon
• PostGIS

Slots de replicação

• Logical replication slots

Dependências das aplicações Se você remover extensões ou objetos de replicação dos quais suas aplicações dependem, verifique os fluxos de dados e o comportamento das aplicações antes de prosseguir com a atualização. Leve também em consideração possíveis interrupções na lógica do seu aplicativo que dependa de recursos específicos do PostgreSQL.

pg_repack

Exclua o diretório pg_repack antes da atualização e recrie-o após a atualização. O pg_repack utiliza uma extensão específica para cada versão e componentes cliente/servidor que devem corresponder à versão principal do PostgreSQL.

DROP EXTENSION pg_repack;

Recrie a extensão após a atualização somente se sua carga de trabalho ainda precisar dela.

CREATE EXTENSION pg_repack;

old_snapshot

Exclua o arquivo “ old_snapshot ” antes da atualização. Não o recrie após a atualização para o PostgreSQL 18, pois ele não é mais compatível.

DROP EXTENSION old_snapshot;

wal2json slots de replicação

Se você utilizar o wal2json para a decodificação lógica, é necessário excluir todos os slots de replicação associados antes da atualização. O utilitário pg_upgrade proíbe estritamente atualizações de versão principal enquanto houver slots de replicação e, nesse caso, gerará um erro crítico e interromperá a atualização.

Antes da atualização:

1. Certifique-se de que todos os dados pendentes do WAL tenham sido processados.
2. Encerre o aplicativo que utiliza o slot de replicação.
3. Excluir o(s) slot(s) de replicação:

SELECT pg_drop_replication_slot('your_slot_name');

Após a atualização, você poderá recriar os slots de replicação conforme necessário. Observe que o wal2json não é instalado por meio de CREATE EXTENSION , mas é configurado por meio de parâmetros do banco de dados (wal_level, max_replication_slots, max_wal_senders) e permissões de tabela, o que não impede as atualizações.

anon

Remova a extensão “ anon ” antes da atualização e reative-a após a atualização, caso ainda precise dela. São necessárias etapas adicionais antes de desinstalar o anon.

Se a extensão “ anon ” estiver instalada, siga as etapas abaixo e execute os comandos como usuário administrador antes de realizar a atualização.

1. Remova todas as regras de máscara (se estiverem ativadas).

   SELECT anon.remove_masks_for_all_columns();
   

2. Desative as funções mascaradas (a atualização pode falhar se alguma função estiver marcada como mascarada).

   SECURITY LABEL FOR anon ON ROLE <role_name> IS NULL;
   

3. Desative a extensão anon com a opção cascade.

   DROP EXTENSION anon CASCADE;
   

4. Se a extensão “ anon ” estiver instalada em vários bancos de dados dentro de uma instância, siga as etapas descritas para cada banco de dados.

5. Após a conclusão da atualização, reative a extensão “ anon ” e reaplique as regras de mascaramento conforme necessário.

Recomenda-se enfaticamente validar os dados tanto antes quanto depois de remover a extensão, a fim de garantir a consistência do mascaramento antes de realizar a atualização.

PostGIS

Se você estiver usando o PostGIS,, atualize primeiro o PostGIS antes de atualizar o PostgreSQL.

SELECT postgis_extensions_upgrade();

Use a consulta a seguir para validar a atualização da extensão “ PostGIS ”.

SELECT postgis_full_version();

Logical replication slots

Exclua todos os slots de replicação lógica antes da atualização e recrie-os após a atualização. Os slots lógicos estão vinculados ao estado do servidor de origem e devem ser recriados do zero na instância atualizada.

SELECT pg_drop_replication_slot('<slot_name>');

Slots de replicação lógica

Exclua todos os slots de replicação lógica antes da atualização e recrie-os depois. Os slots de replicação lógica estão vinculados ao estado do servidor de origem e devem ser recriados na instância atualizada.

SELECT pg_drop_replication_slot('<slot_name>');

Antes de Iniciar

Verifique o seguinte antes de iniciar a atualização:

• Verifique se as atualizações de versão são compatíveis com sua implantação usando a interface do usuário, a API, a CLI ou o Terraform.

  Exemplo (CLI):

  ibmcloud cdb capability-show versions postgresql
  

• Verifique os requisitos de pré-verificação. A atualização é executada na implantação de origem e é bloqueada caso sejam detectados riscos. Certifique-se de que:

  • A implantação está em boas condições
  • Há pelo menos 10% de espaço livre em disco disponível
  • A utilização de E/S está abaixo de 90%
  • O tamanho do esquema e o número de objetos estão dentro dos limites permitidos
  • A limpeza necessária da extensão e do slot de replicação lógica foi concluída

• Consulte o Guia de Compatibilidade do Windows Server 2012 ( https://www.postgresql.org/docs/release/ ) para verificar se há alterações de compatibilidade que possam afetar seus aplicativos.

• O retrocesso para uma versão anterior não é compatível.

• Uma atualização no local não pode ser cancelada depois de iniciada.

• Certifique-se de que haja um backup recente disponível antes de fazer a atualização.

Gen2 começa com “ PostgreSQL ” 18. As rotas de atualização para versões mais recentes são adicionadas à medida que passam a ser compatíveis. Para versões anteriores (14–17), consulte /docs/databases-for-postgresql?topic=databases-for-postgresql-upgrading.

Após a conclusão da atualização, sua implantação será executada em uma nova versão principal do PostgreSQL. Os backups e os pontos PITR anteriores à atualização pertencem à linha do tempo da versão anterior e não podem ser restaurados na versão atualizada.

Para manter os recursos de restauração e PITR na nova versão, faça um backup imediatamente após a atualização. Esse backup passa a ser a base para futuras operações de recuperação.

Caso a atualização falhe, os backups feitos antes da atualização ainda podem ser usados com o PITR para restaurar a versão anterior em uma nova implantação.

Resolução de problemas

Caso surjam problemas após uma atualização bem-sucedida e você precise voltar à versão anterior, entre em contato com o suporte do IBM Cloud® para obter orientação. Evite realizar PITR ou restaurações sem orientação, pois isso pode complicar a recuperação.

As atualizações só são executadas depois que todas as verificações prévias forem aprovadas. Se a atualização estiver bloqueada, verifique:

• Integridade do cluster (o estado do Patroni está estável)
• Espaço livre suficiente no disco
• Utilização aceitável de E/S de disco
• Limites de tamanho do esquema e de número de objetos

Esquemas grandes e um número elevado de objetos podem aumentar a duração da atualização.

Se as tentativas de atualização continuarem falhando, abra um ticket de suporte pelo site https://cloud.ibm.com/login?redirect=%2Funifiedsupport%2Fsupportcenter.

Simulando a promoção e o upgrade

Para avaliar os efeitos das atualizações de versão principais, execute um teste simulado. Um teste simula a promoção e a atualização, com os resultados registrados nos logs do banco de dados. Acesse e visualize os logs do seu banco de dados por meio da integração de análise de logs. Isso garante que a versão que você está executando no momento, juntamente com suas extensões, possa ser atualizada com sucesso para a versão desejada.

A simulação deve ser executada com skip_initial_backup configurado como false e version definida.

O comando é o seguinte:

curl -X POST \
  https://api.{region}.databases.cloud.ibm.com/v5/ibm/deployments/{id}/remotes/promotion \
  -H 'Authorization: Bearer <>'  \
 -H 'Content-Type: application/json' \
 -d '{
    "promotion": {
        "version": "14",
        "skip_initial_backup": false,
        "dry_run": true
    }
}' \