Quelles sont les meilleures pratiques à appliquer lors de la migration de bases de données PostgreSQL vers une base de données cible RDS pour PostgreSQL à l'aide d'AWS DMS ?

Brève description

Lorsque vous migrez des bases de données homogènes à l'aide d'AWS DMS, copiez les données initiales à l'aide des outils natifs de votre moteur, tels que pg_dump. Ensuite, exécutez pg_restore sur la cible. Vous pouvez également utiliser la réplication logique et la commande COPY. Pour plus d'informations, consultez Meilleures pratiques pour la migration des bases de données PostgreSQL vers Amazon RDS et Amazon Aurora.

Pour migrer d'une base de données RDS pour PostgreSQL vers une autre base de données RDS pour PostgreSQL, prenez un instantané, puis restaurez-le en tant que cible. Pour plus d'informations, consultez Migration d'un instantané d'une instance DB RDS pour PostgreSQL vers un cluster de bases de données Aurora PostgreSQL.

Sachez que la migration de toutes vos données d'une base de données source vers une base de données cible à l'aide du chargement complet d'AWS DMS peut prendre beaucoup de temps. Vous pourriez subir des retards en raison de facteurs tels que :

• Bandwidth
• Capacité de la source pour transmettre de grandes quantités de données
• Capacité du moteur de réplication pour stocker, traiter et transférer des charges en bloc
• Capacité cible pour consommer les données de la source

Comparativement, la réplication des modifications ne contient que des modifications de la source vers la cible, de sorte que les charges de travail de ce type peuvent être très légères.

Créer et déterminer le numéro de séquence de journal actuel (LSN)

Avant d'effectuer une sauvegarde, vous devez obtenir un marqueur pour indiquer à votre tâche AWS DMS d'où commencer la migration des modifications.

Sur la base de données PostgreSQL source, exécutez ces requêtes pour créer et déterminer le LSN actuel.

Créez l'emplacement de réplication :

SELECT * FROM
pg_create_logical_replication_slot('replication_slot_name','tset_decoding')

Obtenez le LSN actuel :

SELECT restart_LSN  FROM pg_replication_slots WHERE slot_name = 'replication_slot_name';

La commande Restart_LSN indique à la tâche AWS DMS où commencer la migration des modifications de la source vers la cible.

Solution

Utilisez ces bonnes pratiques pour migrer les données de PostgreSQL vers PostgreSQL à l'aide des tâches AWS DMS.

N'utilisez pas de clés et de déclencheurs étrangers pendant le chargement complet

Lorsque le chargement est complet, assurez-vous que les clés étrangères et les déclencheurs ne sont pas inclus pour la migration. AWS DMS migre les tables par ordre alphabétique, mais il ne sait pas quelles tables sont des tables parents et lesquelles sont des tables enfants. AWS DMS peut donc essayer de migrer d'abord les tables enfants. AWS DMS arrête ensuite la migration des tables en raison d'une violation de clé étrangère. Par conséquent, supprimez ou n'incluez pas les clés étrangères sur la cible pendant la migration.

Les déclencheurs ne doivent jamais être présents sur une cible pendant la migration, car ils exécutent plusieurs processus susceptibles de corrompre les données de la cible. Ajoutez n'importe quel déclencheur lors de la coupure.

Activer le mode LOB complet lors de la migration des données JSON

Lorsque vous migrez un LOB sous forme de JSON, activez le mode LOB complet afin que le format JSON ne soit pas tronqué. Si vous utilisez le mode LOB limité, la troncature des données peut se produire. Ensuite, AWS DMS s'assure que la table échoue car le format JSON n'est pas correct.

Assurez-vous que le champ de clé primaire n'est pas du type de données TEXT

Vérifiez que le champ de clé primaire n'est pas TEXT, en particulier si le mode LOB complet est activé. Vous pouvez rencontrer des DOUBLONS de NULL car AWS DMS traite le type de données TEXT comme LOB. Ainsi, pendant le chargement complet, AWS DMS essaie de rendre la clé primaire NULL, puis signale un doublon car de nombreuses colonnes de texte ont la même valeur. L'erreur n'est jamais traitée comme « NULL non autorisé sur la clé primaire », mais comme des doublons. Ce problème peut être difficile à découvrir et à résoudre. Vérifiez donc toujours que votre champ de clé primaire n'est pas TEXT pour éviter le problème.

Autoriser AWS DMS à créer des tables cibles

Si le chargement est complet, autorisez AWS DMS à créer des tables sur la cible. Lorsque AWS DMS crée des tables, il crée également les champs correspondants sans valeurs DEFAULT pour les colonnes. Les valeurs par défaut des colonnes peuvent entraîner un comportement inattendu dans AWS DMS. Par exemple, SERIAL fait échouer la migration AWS DMS car ce champ souhaite créer automatiquement une valeur. Consultez cet exemple :

CREATE TABLE COMPANY (
   ID SERIAL PRIMARY KEY,
   NAME TEXT      NOT NULL);

Si la cible est structurée comme dans cet exemple, PostgreSQL internals souhaite générer la valeur de la colonne ID. Mais la source contient également une valeur à INSERT qui pose problème. Assurez-vous donc que DEFAULTS ne fait pas partie de la cible lors de la migration.

Définir les partitions en tant que tables sources dans les mappages de tables de tâches

Lorsque vous migrez des tables partitionnées, veillez à définir les partitions en tant que tables sources dans les mappages de tables de tâches, et non en tant que tables parentes. En effet, les journaux WAL retiennent les informations des tables partitionnées. Les tables parents ne doivent être utilisées que pendant le chargement complet, donc n'utilisez pas de tables parents pour la phase CDC. Si vous définissez des tables parents pendant le CDC, vous risquez de rencontrer des erreurs en double qui affectent la migration.

De même, lorsque vous mappez les tables cibles, assurez-vous que toutes les partitions sont remappées sur le parent. Cela signifie que le parent est utilisé pour distribuer automatiquement sur ses partitions.

Définissez toutes les facettes de la source lorsque vous utilisez PGLOGICAL

Lorsque vous utilisez PGLOGICAL pour la migration, assurez-vous de définir chaque facette requise sur la source. Si vous ignorez une zone, vous constaterez un comportement inattendu. Les problèmes qui en résultent sont très difficiles à résoudre. Vérifiez donc que vous avez défini ces zones avant de commencer la migration avec PGLOGICAL.

Pour Amazon RDS, définissez ces articles :

Groupe de paramètres :

shared_preload_libraries = pglocical

Niveau de la base de données:

create extension pglogical;

Pour Sur site, définissez les éléments suivants :

postgresql.conf :

shared_preload_libraries = pglogical

Niveau de la base de données:

create extension pglogical;

Assurez-vous que tous les plugins PG définis sur la source le sont sur la cible

Assurez-vous que tous les plugins PG que vous définissez sur la source le sont également sur la cible. Cela contribue à la compatibilité et au traitement fluide des données.

Assurez-vous que les tâches ne restent pas à l'état Arrêt/Erreur

Lorsque les tâches prennent beaucoup de temps dans les états Stop ou Error, le stockage se remplit sur l'emplacement de réplication.

Supprimer les emplacements de réplication créés manuellement de la source

Si vous avez créé des emplacements de réplication manuellement, supprimez-les de la source lorsque la migration est terminée. Si les emplacements de réplication restent sur la source, leur taille s'accumule et le stockage se remplit.

Migration des tables avec une clé primaire/un index unique

Il est recommandé de s'assurer que les tables que vous migrez ont une clé primaire/un index unique. Si une table ne possède pas de clé primaire, les instructions UPDATE et DELETE peuvent ne pas être appliquées à la table car elles ne sont pas enregistrées dans les journaux WAL. Pour les tables sans clé primaire, utilisez REPLICATE IDENTITY FULL, mais sachez que cela génère de nombreuses informations dans les journaux.

---

Informations connexes

Utilisation d'une base de données PostgreSQL comme source AWS DMS

Cibles pour la migration des données