Extensions et objets de réplication logique à examiner

Veuillez vérifier les points suivants avant la mise à niveau :

Extensions

• pg_repack
• old_snapshot
• wal2json
• anon
• PostGIS

Emplacements de réplication

• Logical replication slots

Dépendances des applications Si vous supprimez des extensions ou des objets de réplication dont dépendent vos applications, vérifiez vos flux de données et le comportement de vos applications avant de poursuivre la mise à niveau. Pensez également aux éventuelles perturbations qui pourraient affecter la logique de votre application si celle-ci dépend de fonctionnalités spécifiques d’ PostgreSQL.

pg_repack

Supprimez le répertoire « pg_repack » avant la mise à niveau, puis recréez-le après celle-ci. Le répertoire « pg_repack » utilise une extension spécifique à la version ainsi que des composants client/serveur qui doivent correspondre à la version majeure de « PostgreSQL ».

DROP EXTENSION pg_repack;

Ne recréez l'extension après la mise à niveau que si votre charge de travail en a toujours besoin.

CREATE EXTENSION pg_repack;

old_snapshot

Supprimez la table « old_snapshot » avant la mise à niveau. Ne pas le recréer après la mise à niveau vers la version 18 d' PostgreSQL, car il n'est plus pris en charge.

DROP EXTENSION old_snapshot;

wal2json emplacements de réplication

Si vous utilisez « wal2json » pour le décodage logique, vous devez supprimer tous les emplacements de réplication associés avant la mise à niveau. L'utilitaire « pg_upgrade » interdit formellement les mises à niveau vers une version majeure tant que des emplacements de réplication existent; il générera une erreur critique et interrompra la mise à niveau.

Avant la mise à jour :

1. Assurez-vous que toutes les données WAL en attente ont bien été traitées.
2. Arrêtez l'application qui utilise l'emplacement de réplication.
3. Supprimer le ou les emplacements de réplication :

SELECT pg_drop_replication_slot('your_slot_name');

Une fois la mise à niveau effectuée, vous pourrez recréer les emplacements de réplication selon vos besoins. Notez que « wal2json » n'est pas installé via CREATE EXTENSION, mais qu'il est configuré à l'aide de paramètres de base de données (wal_level, max_replication_slots, max_wal_senders) et d'autorisations sur les tables, ce qui n'empêche pas les mises à jour.

anon

Désinstallez l'extension « anon » avant la mise à jour, puis réactivez-la après celle-ci si vous en avez encore besoin. Il faut effectuer quelques étapes supplémentaires avant de désinstaller anon.

Si l'extension « anon » est installée, suivez les étapes ci-dessous et exécutez les commandes en tant qu'utilisateur « admin » avant de procéder à la mise à jour.

1. Supprimez toutes les règles de masquage (si elles sont activées).

   SELECT anon.remove_masks_for_all_columns();
   

2. Désactivez les rôles masqués (la mise à niveau risque d'échouer si certains rôles sont marqués comme masqués).

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

3. Désactivez l'extension « anon » avec l'option « cascade ».

   DROP EXTENSION anon CASCADE;
   

4. Si l'extension « anon » est installée dans plusieurs bases de données au sein d'une même instance, suivez les étapes décrites pour chacune d'entre elles.

5. Une fois la mise à jour terminée, réactivez l'extension « anon » et réappliquez les règles de masquage si nécessaire.

Il est vivement recommandé de valider les données avant et après la suppression de l'extension afin de s'assurer de la cohérence du masquage avant de procéder à la mise à niveau.

PostGIS

Si vous utilisez PostGIS,, procédez d'abord à la mise à jour de PostGIS avant de mettre à jour PostgreSQL.

SELECT postgis_extensions_upgrade();

Utilisez la requête suivante pour vérifier la mise à jour de l'extension « PostGIS ».

SELECT postgis_full_version();

Logical replication slots

Supprimez tous les emplacements de réplication logique avant la mise à niveau, puis recréez-les après celle-ci. Les emplacements logiques sont liés à l'état du serveur source et doivent être recréés à partir de zéro sur l'instance mise à niveau.

SELECT pg_drop_replication_slot('<slot_name>');

Emplacements de réplication logique

Supprimez tous les emplacements de réplication logique avant la mise à niveau, puis recréez-les après celle-ci. Les emplacements de réplication logique sont liés à l'état du serveur source et doivent être recréés sur l'instance mise à niveau.

SELECT pg_drop_replication_slot('<slot_name>');

Avant de commencer

Veuillez vérifier les points suivants avant de lancer la mise à niveau :

• Vérifiez que les mises à jour de version sont prises en charge pour votre déploiement à l'aide de l'interface utilisateur, de l'API, de l'interface de ligne de commande ou de Terraform.

  Exemple (interface en ligne de commande):

  ibmcloud cdb capability-show versions postgresql
  

• Vérifiez les conditions préalables à la vérification. La mise à niveau s'effectue sur le déploiement source et est bloquée si des risques sont détectés. Veillez à ce que :

  • Le déploiement se déroule sans problème
  • Au moins 10 % d'espace disque libre est disponible
  • Le taux d'utilisation des E/S est inférieur à 90 %
  • La taille du schéma et le nombre d'objets se situent dans les limites autorisées
  • Le nettoyage requis des extensions et des emplacements de réplication logique est terminé

• Consultez le document « https://www.postgresql.org/docs/release/ » pour prendre connaissance des modifications de compatibilité susceptibles d'affecter vos applications.

• Le retour à une version antérieure n'est pas pris en charge.

• Une mise à niveau sur place ne peut pas être annulée une fois qu'elle a commencé.

• Assurez-vous de disposer d'une sauvegarde récente avant de procéder à la mise à jour.

Gen2 commence à la page 18 d' PostgreSQL. Les procédures de mise à niveau vers les versions plus récentes sont ajoutées au fur et à mesure qu'elles sont prises en charge. Pour les versions antérieures (14 à 17), consultez la page /docs/databases-for-postgresql?topic=databases-for-postgresql-upgrading.

Une fois la mise à niveau terminée, votre déploiement fonctionnera sous une nouvelle version majeure d' PostgreSQL. Les sauvegardes et les points PITR antérieurs à la mise à niveau relèvent de la chronologie de la version précédente et ne peuvent pas être restaurés dans la version mise à niveau.

Pour conserver les fonctionnalités de restauration et de PITR dans la nouvelle version, effectuez une sauvegarde immédiatement après la mise à niveau. Cette sauvegarde sert de référence pour les futures opérations de restauration.

Si la mise à niveau échoue, les sauvegardes effectuées avant celle-ci peuvent toujours être utilisées avec PITR pour restaurer la version antérieure dans un nouveau déploiement.

Traitement des incidents

Si des problèmes surviennent après une mise à jour réussie et que vous devez revenir à la version précédente, contactez le service d'assistance de IBM Cloud® pour obtenir de l'aide. Évitez d'effectuer des opérations PITR ou des restaurations sans assistance, car cela peut compliquer la récupération.

Les mises à niveau ne sont exécutées qu'une fois que toutes les vérifications préalables ont abouti. Si la mise à jour est bloquée, vérifiez les points suivants :

• État du cluster (état de Patroni : stable)
• Espace disque libre suffisant
• Utilisation acceptable des E/S disque
• Limites relatives à la taille des schémas et au nombre d'objets

Les schémas volumineux et le nombre élevé d'objets peuvent allonger la durée de la mise à niveau.

Si les tentatives de mise à jour échouent toujours, ouvrez un ticket d'assistance via https://cloud.ibm.com/login?redirect=%2Funifiedsupport%2Fsupportcenter.

Exécution-test de la promotion et de la mise à niveau

Pour évaluer les effets des mises à niveau vers une nouvelle version majeure, lancez un test de simulation. Une simulation permet de reproduire la promotion et la mise à niveau, les résultats étant consignés dans les journaux de la base de données. Accédez à vos journaux de base de données et consultez-les grâce à l'intégration « Analyse des journaux ». Cela garantit que la version que vous utilisez actuellement, avec ses extensions, pourra être mise à niveau sans problème vers la version souhaitée.

Pour effectuer l'exécution-test, vous devez définir skip_initial_backup sur false, et vous devez définir version.

La commande se présente comme suit :

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
    }
}' \