Problèmes connus et limitations concernant les migrations en ligne de PostgreSQL vers Azure Database pour PostgreSQL

Important

Pour une expérience de migration plus simple et plus efficace, il est recommandé d’utiliser le nouveau service de migration dans Azure Database pour PostgreSQL. Ce service simplifie le processus en prenant en charge une variété d’environnements sources afin d’assurer une transition sans problème vers Azure Database pour PostgreSQL.

Cet article décrit les problèmes connus et les limitations des migrations en ligne de PostgreSQL vers Azure Database pour PostgreSQL à l’aide d’Azure Database Migration Service (DMS).

Configuration d’une migration en ligne

• La version source PostgreSQL la plus basse prise en charge est 9.4 et la version cible la plus élevée prise en charge est 14.9.

• Seules les migrations vers une version identique ou supérieure sont prises en charge. Par exemple, une migration PostgreSQL 9.5 à Azure Database pour PostgreSQL 9.6 ou 10 n’est pas prise en charge. La migration de PostgreSQL 11 vers PostgreSQL 9.6 n’est pas prise en charge.

• Pour activer la réplication logique dans le fichier postgresql.conf source, définissez les paramètres suivants :

  Paramètre	Description
  wal_level	Définissez comme logique.
  max_replication_slots	Définissez au moins le nombre maximal de bases de données pour la migration. Si vous souhaitez migrer quatre bases de données, définissez la valeur sur au moins 4.
  max_wal_senders	Définissez le nombre de bases de données exécutées simultanément. 10 est la valeur recommandée.

• Ajouter une adresse IP d’agent DMS au fichier pg_hba.conf PostgreSQL source.

  1. Notez l’adresse IP DMS après avoir terminé le provisionnement d’une instance Azure Database Migration Service.

  2. Ajoutez l’adresse IP dans le fichier pg_hba.conf :

     host    all    172.16.136.18/10    md5
     host    replication postgres    172.16.136.18/10     md5
     

• L’utilisateur doit disposer du rôle REPLICATION sur le serveur qui héberge la base de données source.

• Les schémas des bases de données source et cible doivent correspondre.

Limites de taille

• Vous pouvez migrer jusqu’à 1 To de données de PostgreSQL vers Azure Database pour PostgreSQL à l’aide d’un seul service DMS.
• Le service DMS permet aux utilisateurs de choisir les tables au sein d’une base de données qu’ils souhaitent migrer.

En arrière-plan, la commande pg_dump prend une image mémoire des tables sélectionnées à l’aide de l’une des options suivantes :

• -T pour inclure les noms de table sélectionnés dans l’interface utilisateur
• -t pour inclure les noms de table qui ne sont sélectionnés par l’utilisateur

Le nombre de caractères qui peuvent être inclus dans la commande pg_dump après l’option -t ou -T est limité à 7 500. La commande pg_dump utilise le nombre de caractères des tables sélectionnées ou non sélectionnées (la plus petite valeur des deux). Si le nombre de caractères des tables sélectionnées et non sélectionnées dépasse 7 500, la commande pg_dump échoue avec une erreur.

Pour l’exemple précédent, la commande pg_dump est :

pg_dump -h hostname -u username -d databasename -T "\"public\".\"table_1\"" -T "\"public\".\"table_2\""

Dans la commande précédente, le nombre de caractères est 55 (inclut des guillemets doubles, des espaces, -T et une barre oblique)

Limitations des types de données

Limitation : S’il n’existe aucune clé primaire pour les tables, les modifications risquent de ne pas être synchronisées avec la base de données cible.

Solution de contournement : définissez temporairement une clé primaire pour la table afin de poursuivre la migration. Supprimez la clé primaire à l’issue de la migration de données.

Limitations de la migration en ligne depuis AWS RDS PostgreSQL

Lorsque vous essayez d’effectuer une migration en ligne d’Amazon Web Service (AWS) Relational Database (RDS) PostgreSQL vers Azure Database pour PostgreSQL, vous pouvez rencontrer les erreurs suivantes :

• Erreur : La valeur par défaut de la colonne ’{colonne}’ dans la table ’{table}’ de la base de données ’{base de données}’ est différente sur les serveurs source et cible. Elle est '{valeur sur la source}' sur la source et '{valeur sur la cible}' sur la cible.

  Limitation : Cette erreur se produit quand la valeur par défaut sur un schéma de colonne est différente entre les bases de données source et cible.

  Solution de contournement : Vérifiez que le schéma sur la cible correspond au schéma sur la source. Pour plus d’informations sur la migration du schéma, consultez la documentation de migration en ligne Azure Database pour PostgreSQL.

• Erreur : La base de données cible ’{base de données}’ a ’{nombre de tables}’ tables alors que la base de données source ’{base de données}’ en a ’{nombre de tables}’. Les bases de données source et cible doivent avoir le même nombre de tables.

  Limitation : Cette erreur se produit quand le nombre de tables est différent entre les bases de données source et cible.

  Solution de contournement : Vérifiez que le schéma sur la cible correspond au schéma sur la source. Pour plus d’informations sur la migration du schéma, consultez la documentation de migration en ligne Azure Database pour PostgreSQL.

• Erreur : La base de données source {database} est vide.

  Limitation: Cette erreur se produit lorsque la base de données source est vide. Vous avez probablement sélectionné la mauvaise base de données comme source.

  Solution de contournement: Vérifiez à nouveau la base de données source que vous avez sélectionnée pour la migration, puis réessayez.

• Erreur : La base de données cible {database} est vide. Migrer le schéma.

  Limitation: Cette erreur se produit lorsqu’il n’existe aucun schéma sur la base de données cible. Vérifiez que le schéma sur la cible correspond au schéma sur la source.

  Solution de contournement : Vérifiez que le schéma sur la cible correspond au schéma sur la source. Pour plus d’informations sur la migration du schéma, consultez la documentation de migration en ligne Azure Database pour PostgreSQL.

Autres limitations

• Le nom de la base de données ne peut pas contenir un point-virgule (;).

• Une table capturée doit avoir une clé primaire. Si une table n’a pas de clé primaire, le résultat des opérations d’enregistrement DELETE et UPDATE est imprévisible.

• La mise à jour d’un segment de clé primaire est ignorée. L’application d’une telle mise à jour sera identifiée par la cible comme une mise à jour qui n’a mis à jour aucune ligne. Le résultat est un enregistrement écrit dans la table exceptions.

• Si votre table comporte une colonne JSON, toute opération SUPPRIMER ou METTRE À JOUR sur cette table peut entraîner l'échec de la migration.

• La migration de plusieurs tables portant le même nom mais avec une casse différente peut entraîner un comportement imprévisible et n’est pas prise en charge. Un exemple est l’utilisation de table1, TABLE1 et Table1.

• Le traitement des modifications des DDL de table [ CREATE | ALTER | DROP | TRUNCATE ] n’est pas pris en charge.

• Dans Database Migration Service, une même activité de migration peut prendre en charge jusqu’à quatre bases de données.

• La migration de la table pg_largeobject n’est pas prise en charge.

Contenu connexe

• Présentation d’Azure Database Migration Service