Extensions et objets de réplication logique à examiner

Vérifiez les points suivants avant la mise à niveau :

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 propre à la version ainsi que des composants client/serveur qui doivent correspondre à la version principale 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. PostgreSQL NE LE RECRÉEZ PAS après la mise à jour vers Windows 18, car il n'est plus pris en charge.

DROP EXTENSION old_snapshot;

wal2json emplacements de réplication

Si vous utilisez la commande « 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 les emplacements de réplication :

SELECT pg_drop_replication_slot('your_slot_name');

Une fois la mise à niveau effectuée, vous pouvez recréer les emplacements de réplication selon vos besoins. Notez qu' wal2json ne s'installe pas via CREATE EXTENSION, mais qu'il se configure à 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 et réactivez-la après la mise à jour si vous en avez encore besoin. Il faut effectuer quelques étapes supplémentaires avant de quitter 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. Supprimer toutes les règles de masquage (si elles sont activées).

   SELECT anon.remove_masks_for_all_columns();
   

2. Désactiver le masquage des rôles (la mise à niveau peut échouer si des rôles sont marqués comme masqués).

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

3. Abandonnez 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 à niveau terminée, réactivez l'extension anon et réappliquez les règles de masquage si nécessaire.

Il est fortement recommandé de valider les données avant et après l'abandon de l'extension afin de garantir la cohérence du masquage avant d'effectuer la mise à niveau.

PostGIS

Si vous utilisez PostGIS,, mettez d'abord à jour PostGIS avant de mettre à jour PostgreSQL.

SELECT postgis_extensions_upgrade();

Utilisez la requête suivante pour valider 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>');

Avant de commencer

Avant de commencer la procédure de mise à niveau, tenez compte des aspects suivants.

• Vérifiez si une mise à jour est disponible pour votre version de déploiement en consultant les informations relatives aux capacités de déploiement via l'interface utilisateur, l'API, l'interface de ligne de commande ou Terraform.

  Exemple : consultation des informations relatives à la mise à jour de la version via l'interface en ligne de commande :

  ibmcloud cdb capability-show versions postgresql
  

• Assurez-vous de prendre connaissance des exigences relatives au contrôle préalable décrites dans cette rubrique avant de lancer l'IPU. IPU s'exécute directement sur l'environnement de déploiement d'origine et ne crée pas de nouvelle instance. Pour la sécurité des clients, le service effectue des vérifications préalables avant le début de la mise à niveau et bloque l'opération si un risque est détecté. Vérifiez notamment les points suivants :

  • Votre déploiement compte au maximum 3 membres.
  • Votre déploiement fonctionne correctement.
  • Votre déploiement dispose d'au moins 10 % d'espace disque libre. L'utilisation maximale autorisée par défaut de l'espace disque pour les pré-vérifications IPU est de 90 %.
  • Votre déploiement n'est pas soumis à une forte charge d'E/S. Le taux d'utilisation maximal autorisé par défaut pour la pré-vérification de l'IPU est de 90 %.
  • La taille de votre schéma et le nombre d'objets se situent dans les limites des seuils de pré-vérification par défaut. Par défaut, aucun schéma ne peut dépasser 100 Go et le nombre total d'index et de séquences doit rester inférieur à 50 000.
  • Vous avez effectué toutes les opérations nécessaires de nettoyage des extensions et des emplacements de réplication logique avant la mise à niveau.

• Chaque version majeure comporte certaines fonctionnalités qui peuvent ne pas être compatibles avec les versions antérieures. Consultez les notes de mise à jour fournies par l'éditeur de la base de données pour prendre connaissance des modifications susceptibles d'affecter vos applications.

• La rétrogradation d'un déploiement vers une version précédente n'est pas prise en charge.

• Une mise à niveau majeure effectuée sur place ne peut pas être annulée une fois lancée.

• Si vous ne disposez pas d'une sauvegarde récente, pensez à en effectuer une avant de procéder à la mise à jour.

Notez également qu'une fois la mise à niveau terminée, votre base de données fonctionnera sous une nouvelle version majeure d' PostgreSQL. Étant donné qu' PostgreSQL stocke les données dans des formats propres à chaque version, les sauvegardes et les points de restauration 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 toutes les fonctionnalités de restauration complète et de PITR (restauration à un instant donné) dans la nouvelle version, effectuez une nouvelle sauvegarde dès que la mise à niveau est terminée. Cette sauvegarde sert de référence pour les futures opérations de restauration sur la nouvelle chronologie.

Si l'IPU échoue, les sauvegardes valides antérieures à la mise à niveau peuvent toujours être utilisées avec PITR pour restaurer la version antérieure d' PostgreSQL.

Traitement des incidents

Si vos applications présentent des problèmes inattendus après une mise à niveau majeure réussie et que vous devez revenir à la version PostgreSQL précédente, contactez notre équipe d'assistance pour obtenir de l'aide. Évitez de lancer vous-même une procédure PITR ou de restaurer une sauvegarde, car cela pourrait compliquer la récupération.

Une mise à niveau majeure sur place ne sera effectuée qu'après la réussite de toutes les vérifications préalables. Ces mesures de sécurité ont pour but de protéger votre déploiement, car la mise à niveau s'effectue directement sur l'instance source. Si la mise à niveau est bloquée, vérifiez les points suivants :

• Nombre de nœuds : la mise à niveau de version majeure sur site prend en charge les déploiements comprenant au maximum 3 nœuds. Si votre déploiement compte plus de 3 membres, les vérifications préalables bloquent la mise à niveau. Les membres ne peuvent pas être supprimés dans le cadre d' une mise à l'échelle horizontale; veuillez donc ouvrir un ticket d'assistance auprès du service d'assistance d' IBM Cloud afin de réduire le nombre de membres avant de réessayer la mise à niveau.
• État du cluster : s'assurer que le cluster Patroni fonctionne correctement et qu'il existe une distinction claire entre le nœud principal et les répliques. Les mises à niveau ne peuvent pas être effectuées si Patroni signale des conditions d'instabilité ou de basculement.
• Espace disque : vérifiez qu'il y a suffisamment d'espace libre disponible. Le processus utilise le mode pg_upgrade lien, qui nécessite une marge suffisante. Si l'utilisation du disque dépasse la limite configurée (valeur par défaut : 90 %), libérez de l'espace avant de réessayer.
• Charge des E/S disque : vérifiez l'utilisation actuelle des E/S et le nombre d'IOPS. Les mises à niveau sont suspendues lorsque le système est soumis à une charge importante afin d'éviter toute dégradation des performances ou tout échec de la mise à niveau.
• Taille du schéma et nombre d'objets : comme mentionné précédemment, la taille du schéma a une incidence directe sur la durée d'une mise à niveau majeure sur place. Assurez-vous qu'aucun schéma individuel ne dépasse la taille maximale (valeur par défaut : 100 Go) et que le nombre total d'objets d'index et de séquence reste inférieur à la limite (valeur par défaut : 50 000). Les schémas volumineux ou les nombres d'objets inhabituellement élevés peuvent nécessiter un nettoyage ou une optimisation avant de procéder à la mise à niveau. pg_upgrade effectue des mises à niveau rapides en créant de nouvelles tables système et en réutilisant simplement les anciens fichiers de données utilisateur. Le temps nécessaire à la création de ces tables système dépend du nombre d'objets de la base de données. La consommation des ressources peut être évaluée à l'aide de l 'intégration de la surveillance. Si tous les composants de la base de données ne sont pas disponibles pour la mise à niveau, la tâche de mise à niveau échoue. Cela peut être dû à des travaux de maintenance. Les tâches qui ont échoué en raison d'échecs des contrôles d'intégrité peuvent être réessayées ultérieurement. Si la tâche échoue continuellement, ouvrez un ticket d'assistance auprès IBM Cloud du service d'assistance. Si certaines vérifications ne sont pas pertinentes pour votre environnement et que la mise à niveau est toujours bloquée, créez un ticket d'assistance pour obtenir de l'aide.

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 en mode simulation. Une exécution à sec simule la promotion et la mise à niveau, avec les résultats imprimés dans les journaux de la base de données. Accédez aux journaux de votre base de données et visualisez-les par l'intermédiaire de Intégration de l'analyse du journal. 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
    }
}' \