Partager via

Problèmes connus et limitations pour le service de migration dans Azure Database pour PostgreSQL

  • Article

S’APPLIQUE À : Azure Database pour PostgreSQL : serveur flexible

Cet article décrit les problèmes connus et limitations associés au service de migration dans Azure Database pour PostgreSQL.

Limitations courantes

Voici les limitations courantes qui s’appliquent aux scénarios de migration :

  • Il ne peut exister qu’une seule migration ou validation active vers votre serveur flexible.

  • Le service de migration prend uniquement en charge la migration des utilisateurs et des rôles lorsque la source est Azure Database pour PostgreSQL – Serveur unique.

  • Le service de migration indique le nombre de tables copiées de la source vers la cible. Vous devez vérifier manuellement les données et les objets PostgreSQL sur le serveur cible après la migration.

  • Le service de migration migre uniquement les bases de données utilisateur, et non les bases de données système telles que template_0 et template_1.

  • Le service de migration ne prend pas en charge le déplacement des extensions TIMESCALEDB, POSTGIS_TOPOLOGY, POSTGIS_TIGER_GEOCODER ou PG_PARTMAN de la source vers la cible.

  • Vous ne pouvez pas déplacer les extensions non prises en charge par Azure Database pour PostgreSQL – Serveur flexible. Les extensions prises en charge sont répertoriées dans Extensions – Azure Database pour PostgreSQL.

  • Les classements définis par l’utilisateur ne peuvent pas être migrés vers Azure Database pour PostgreSQL – Serveur flexible.

  • Vous ne pouvez pas migrer vers une version antérieure. Par exemple, vous ne pouvez pas effectuer de migration d’Azure Database pour PostgreSQL version 15 vers la version 14.

  • Le service de migration fonctionne uniquement avec les valeurs SSLMODE préférées ou requises.

  • Le service de migration ne prend pas en charge les objets et privilèges de superutilisateur.

  • Azure Database pour PostgreSQL – Serveur flexible ne prend pas en charge la création d’espaces de table personnalisés en raison de restrictions de privilèges de superutilisateur. Pendant la migration, les données issues des espaces de table personnalisés de l’instance PostgreSQL source sont migrées vers les espaces de table par défaut de l’instance Azure Database pour PostgreSQL – Serveur flexible cible.

  • Les objets PostgreSQL suivants ne peuvent pas être migrés vers la cible de serveur flexible PostgreSQL :

    • Créer des casts
    • Création d’analyseurs FTS et de modèles FTS
    • Utilisateurs avec des rôles de superutilisateur
    • Create TYPE

  • Le service de migration ne prend pas en charge la migration au niveau de l’objet, c’est-à-dire au niveau de la table ou du schéma.

  • La migration vers des références SKU burstables n’est pas prise en charge. Les bases de données doivent d’abord être migrées vers une référence SKU non burstable, puis faire l’objet d’un scale-down si nécessaire.

  • Le serveur d’exécution de migration a été conçu pour fonctionner avec les serveurs DNS/zones DNS privées par défaut, par exemple privatelink.postgres.database.azure.com. Les noms DNS/serveurs DNS personnalisés ne sont pas pris en charge par le service de migration lorsque vous utilisez la fonctionnalité de serveur d’exécution de migration. Lorsque vous configurez des points de terminaison privés pour les bases de données source et cible, il est impératif d’utiliser la zone DNS privée par défaut fournie par Azure pour le service de liaison privée. L’utilisation de configurations DNS personnalisées n’est pas encore prise en charge et peut entraîner des problèmes de connectivité pendant le processus de migration.

Limites de la migration à partir d’Azure Database pour PostgreSQL – Serveur unique

  • Les utilisateurs Microsoft Entra ID présents sur votre serveur source ne sont pas migrés vers le serveur cible. Pour pallier cette limite, consultez Gérer les rôles Microsoft Entra pour créer manuellement tous les utilisateurs Microsoft Entra sur votre serveur cible avant de déclencher une migration. Si les utilisateurs Microsoft Entra ne sont pas créés sur le serveur cible, la migration échoue.
  • Si le serveur flexible cible utilise la méthode de chiffrement de mot de passe SCRAM-SHA-256, la connexion à un serveur flexible avec les utilisateurs/rôles d’un serveur unique échoue, car les mots de passe sont chiffrés avec l’algorithme md5. Pour pallier cette limite, choisissez l’option MD5 pour le paramètre de serveur password_encryption sur votre serveur flexible.
  • La migration en ligne utilise pgcopydb follow, et certaines restrictions de décodage logique s’appliquent.

Contenu connexe