Partager via

Problèmes connus et limites pour le service de migration

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

Limitations courantes

La liste suivante décrit les limites 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 qui sont 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. Le service ne migre pas les bases de données système telles que template_0 et template_1.

  • Vous ne pouvez pas déplacer d’extensions qui ne sont pas prises en charge par le serveur flexible Azure Database pour PostgreSQL. Les extensions prises en charge sont répertoriées dans Extensions pour Azure Database pour PostgreSQL.

  • Les classements définis par l’utilisateur ne peuvent pas être migrés vers un serveur flexible de Azure Database for PostgreSQL.

  • 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 Azure Database pour PostgreSQL version 14.

  • Le service de migration fonctionne uniquement avec une valeur SSLMODE de preferred ou de required.

  • Le service de migration ne prend pas en charge les objets et les autorisations de superutilisateur.

  • Le serveur flexible Azure Database pour PostgreSQL ne prend pas en charge la création d’espaces de table personnalisés en raison de restrictions sur les autorisations de superutilisateur. Pendant la migration, les données provenant d’espaces de table personnalisés dans l’instance PostgreSQL source sont migrées vers les espaces de table par défaut de l’instance cible du serveur flexible Azure Database pour PostgreSQL.

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

    • Créer des casts
    • Création d’analyseurs de recherche en texte intégral (FTS) et de modèles FTS
    • Utilisateurs qui ont des rôles superutilisateur
    • Créer un type

  • Le service de migration ne prend pas en charge la migration au niveau de l’objet. Autrement dit, vous ne pouvez pas migrer une table ou un schéma.

    Important

    Bien que la référence SKU Burstable ne soit pas une limitation, il est recommandé de choisir une référence SKU supérieure pour votre serveur flexible afin qu’il puisse effectuer les migrations plus rapidement. Le serveur flexible Azure pour PostgreSQL permet une mise à l’échelle du calcul et des IOPS avec un temps d’arrêt quasi nul, ce qui permet de mettre à jour le SKU avec un temps d’arrêt minimal. Vous pouvez toujours changer de référence SKU en fonction des besoins de l’application après la migration.

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

La liste suivante décrit les limitations spécifiques à la migration à partir d’Azure Database pour PostgreSQL - Serveur unique :

  • Si le serveur flexible cible utilise la méthode de chiffrement de mot de passe SCRAM-SHA-256, la connexion à un serveur flexible à l’aide des utilisateurs ou des rôles sur un seul serveur échoue. Sur un seul serveur, les mots de passe sont chiffrés à l’aide de l’algorithme MD5. Pour pallier cette limite, pour le paramètre de serveur password_encryption sur votre serveur flexible, sélectionnez l’option MD5.
  • La migration en ligne utilise pgcopydb follow. Certaines restrictions de décodage logique s’appliquent.
  • Le service de migration ne prend pas en charge la copie de rôles authentifiés par l’ID Microsoft Entra lors de l’utilisation d’un serveur d’exécution pour effectuer la migration d’un serveur unique vers un serveur flexible. Nous vous recommandons de créer manuellement les rôles entra ID authentifiés sur le serveur cible avant de lancer la migration.

Contenu connexe

  • Last updated on