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

Article
03/09/2023

Les sections suivantes décrivent les problèmes connus et limitations associés aux migrations en ligne de PostgreSQL vers Azure Database pour PostgreSQL.

Configuration d’une migration en ligne

Le serveur PostgreSQL source doit exécuter la version 9.4, 9.5, 9.6, 10 ou 11. (pour plus d’informations, consultez la page Versions prises en charge des bases de données PostgreSQL) ;
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.config PostgreSQL source, définissez les paramètres suivants :
- 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 s’exécutant simultanément. La valeur recommandée est 10.
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.

Limitations 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, une commande pg_dump est utilisée pour prendre 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

Il existe une limite maximale de 7 500 caractères pouvant être inclus dans la commande pg_dump suivant l’option -t ou -T. La commande pg_dump utilise le nombre de caractères pour les tables sélectionnées ou non sélectionnées (la plus petite valeur des deux). Si le nombre de caractères pour les 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 relatives au type 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 quand la base de données source est vide. Vous avez probablement sélectionné la mauvaise base de données comme source.

Solution de contournement : Revérifiez 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 quand il n’y a pas de schéma dans 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 a une colonne JSON , toute opération DELETE ou UPDATE sur cette table peut entraîner un é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.