Data Transmission Service:Migrer des données incrémentielles d'une base PostgreSQL autonome vers ApsaraDB RDS for PostgreSQL

Prérequis

• La base de données PostgreSQL autonome source exécute une version comprise entre 10,1 et 13.

• Une instance ApsaraDB RDS for PostgreSQL est créée.Créer une instance ApsaraDB RDS for PostgreSQL.

  Remarque

  Pour des raisons de compatibilité, nous vous recommandons d'utiliser la même version de base de données sur l'instance RDS de destination que celle de la base de données PostgreSQL autonome source.

• L'instance RDS de destination doit disposer d'un espace de stockage supérieur à celui utilisé par la base de données source.

Notes d'utilisation

• Lors d'une migration complète des données, DTS consomme des ressources de lecture et d'écriture sur les bases de données source et de destination, ce qui augmente leur charge. Si vos bases de données présentent des performances médiocres, des spécifications faibles ou des charges de travail élevées (par exemple, si la base de données source contient de nombreuses requêtes SQL lentes ou des tables sans clés primaires, ou si des interblocages se produisent dans la base de données de destination), cette augmentation de la charge peut solliciter excessivement vos bases de données, voire provoquer des interruptions de service. Effectuez la migration des données pendant les heures creuses, par exemple lorsque l'utilisation du CPU des deux bases de données est inférieure à 30 %.

• Si une table source ne possède ni clé primaire ni contrainte unique et contient des données non uniques, des données en double peuvent être créées dans la base de données de destination.

• Lors de la migration incrémentielle des données, si vous sélectionnez un schéma comme objet de migration puis créez une nouvelle table ou reconstruisez une table à l'aide de RENAME, exécutez ALTER TABLE schema.table REPLICA IDENTITY FULL; avant d'écrire des données dans la table.

  Remarque

  Remplacez

  schema

  et

  table

  par les noms réels du schéma et de la table.

• DTS ajoute une table de heartbeat nommée dts_postgres_heartbeatà la base de données source afin de mesurer la latence de la migration incrémentielle.

• DTS crée un slot de réplication logique préfixé par dts_sync_ dans la base de données source. DTS nettoie les slots de réplication historiques toutes les 90 minutes pour éviter la consommation excessive d'espace disque.SELECT * FROM pg_replication_slots;slot_namedts_sync_slot_typelogicalactivetrue

  Remarque

  Lorsqu'une tâche de migration est libérée ou échoue, DTS nettoie automatiquement le slot de réplication. En cas de basculement primaire/secondaire sur l'instance RDS, nettoyez manuellement le slot de réplication sur l'instance secondaire.

  Vous pouvez exécuter

  pour afficher les slots de réplication. Un slot dont

  commence par

  ,

  de type

  et dont le statut est

  est en cours d'utilisation.

• Le basculement primaire/secondaire pendant la migration n'est pris en charge que pour ApsaraDB RDS for PostgreSQL 11. Définissez rds_failover_slot_mode sur sync.Basculement du slot de réplication logique.

  Avertissement

  Un basculement primaire/secondaire sur une base de données PostgreSQL autonome ou sur d'autres versions de RDS interrompt la migration.

• DTS relance automatiquement les tâches ayant échoué. Avant de basculer vos applications vers l'instance de destination, arrêtez ou libérez la tâche pour éviter d'écraser les données de destination.

• Les transactions de longue durée dans la base de données source peuvent empêcher l'effacement des journaux WAL, entraînant une accumulation des fichiers WAL et un épuisement de l'espace disque.

Limites

• Chaque tâche de migration ne migre qu'une seule base de données. Pour migrer plusieurs bases de données, créez une tâche distincte pour chacune d'elles.

• Les noms de bases de données ne doivent pas contenir de traits d'union (-). Exemple : dts-testdata.

• En cas de basculement primaire/secondaire sur la base de données source pendant la migration, la migration incrémentielle des données ne peut pas reprendre.

• La latence de réplication peut entraîner une incohérence des données entre les nœuds primaires et secondaires. Utilisez toujours le nœud primaire comme source de données.

  Remarque

  Effectuez la migration pendant les heures creuses. Vous pouvez ajuster le taux de migration en fonction de la charge de la base de données source.

  Modifier le taux de transfert de la migration complète des données

  .

• Le type de données BIT n'est pas pris en charge lors de la migration incrémentielle des données.

• Lors de la migration incrémentielle des données, seules les opérations DML (INSERT, DELETE, UPDATE) sont synchronisées.

  Remarque

  Seules les tâches créées après le 1er octobre 2020 prennent en charge la synchronisation DDL. Avant de configurer la tâche, créez des déclencheurs et des fonctions dans la base de données source pour capturer les informations DDL.

  Utiliser des déclencheurs et des fonctions pour implémenter la migration DDL incrémentielle pour PostgreSQL

  .

• Après le basculement des charges de travail vers la base de données de destination, les valeurs de séquence ne commencent pas à partir de la valeur maximale de la base de données source. Avant le basculement, interrogez la valeur maximale de la séquence dans la base de données source et définissez-la comme valeur initiale dans la base de données de destination.

• DTS valide le contenu des données mais ne valide pas les métadonnées telles que les séquences. Validez manuellement les métadonnées de séquence.

Facturation

Autorisations des comptes de base de données

Pour créer un compte de base de données et accorder des autorisations, consultez les rubriques suivantes :

• Base de données PostgreSQL autonome :CREATE USER et GRANT.

• Instance ApsaraDB for PostgreSQL :Créer un compte

  .

Processus de migration des données

Pour résoudre les dépendances entre objets et améliorer le taux de réussite de la migration, DTS migre les schémas et les données PostgreSQL selon l'ordre suivant.

Préparer la migration

1. Connectez-vous au serveur où réside votre base de données PostgreSQL autonome.

2. Modifiez le fichier postgresql.conf. Définissez wal_level sur logical.

   # - Settings -
   wal_level = logical                     # minimal, replica, or logical
                                           # (change requires restart)

   Remarque

   • Après avoir modifié le fichier, exécutez SELECT pg_reload_conf(); ou redémarrez la base de données PostgreSQL pour que les modifications prennent effet.

   • Si vous n'avez pas besoin de la migration incrémentielle des données, vous pouvez ignorer cette étape.

3. Ajoutez les blocs CIDR des serveurs DTS au fichier pg_hba.conf de votre base de données PostgreSQL autonome. Ajoutez uniquement les plages d'adresses IP DTS correspondant à la région de votre base de données de destination. Ajouter les adresses IP des serveurs DTS à une liste d'autorisation.

   Remarque

   Pour plus de détails sur ce fichier, consultez la documentation officielle PostgreSQL concernant

   Le fichier pg_hba.conf

   . Ignorez cette étape si l'adresse de confiance est déjà définie sur

   0.0.0.0/0

   , comme illustré ci-dessous.

   # "local" is for Unix domain socket connections only
   local   all             all                                     peer
   # IPv4 local connections:
   host    all             all             0.0.0.0/0               trust
   # IPv6 local connections:
   host    all             all             ::1/128                 md5

4. Facultatif : Pour synchroniser les opérations DDL, créez des déclencheurs et des fonctions dans la base de données source afin de capturer les informations DDL. Utiliser des déclencheurs et des fonctions pour implémenter la migration DDL incrémentielle pour PostgreSQL.

   Remarque

   Vous pouvez ignorer cette étape si vous n'avez pas besoin de synchroniser les opérations DDL.

Procédure

1. Connectez-vous à la console DTS.

   Remarque

   Si vous êtes redirigé automatiquement vers la console Data Management (DMS), cliquez sur l'icône située en bas à droite, puis sur pour revenir à la console DTS classique.

2. Dans le volet de navigation de gauche, cliquez sur Data Migration.

3. En haut de la page Migration Tasks, sélectionnez la région du cluster de destination.

4. Dans le coin supérieur droit de la page, cliquez sur Create Data Migration Task.

5. Configurez les informations relatives aux bases de données source et de destination.

   Catégorie	Paramètre	Description
   N/A	Nom de la tâche	DTS génère automatiquement un nom de tâche. Spécifiez un nom descriptif pour faciliter l'identification. Le nom n'a pas besoin d'être unique.
   Base de données source	Type d'instance	Sélectionnez l'emplacement de déploiement de la base de données source. Cet exemple utilise Self-managed Database with Public IP. Remarque Si votre base de données autonome utilise un autre type d'instance, des préparations supplémentaires sont nécessaires. Aperçu des préparatifs.
   	Région de l'instance	Si vous sélectionnez Self-managed Database with Public IP, il n'est pas nécessaire de définir le paramètre Instance Region.
   	Type de base de données	Sélectionnez PostgreSQL.
   	Nom d'hôte ou adresse IP	Saisissez l'adresse IP publique de la base de données PostgreSQL source.
   	Port	Saisissez le port de service de la base de données PostgreSQL source. Ce port doit être accessible depuis Internet public.
   	Nom de la base de données	Saisissez le nom de la base de données à migrer.
   	Compte de base de données	Saisissez le compte de la base de données PostgreSQL source. Pour connaître les exigences en matière d'autorisations, consultez la section Autorisations des comptes de base de données.
   	Mot de passe de la base de données	Saisissez le mot de passe du compte de base de données. Remarque Après avoir saisi les informations de la base de données source, vous pouvez cliquer sur Test Connectivity à côté de Database Password pour vérifier que les informations sont correctes. Si les informations sont correctes, le message Passed s'affiche. Si le message Failed s'affiche, cliquez sur Diagnose à côté du message Failed et ajustez les informations de la base de données source selon les instructions.
   Base de données de destination	Type d'instance	Sélectionnez RDS Instance.
   	Région de l'instance	Sélectionnez la région de l'instance RDS de destination.
   	ID de l'instance RDS	Sélectionnez l'ID de l'instance RDS de destination.
   	Nom de la base de données	Saisissez le nom de la base de données de destination. Il peut différer du nom de la base de données source. Remarque La base de données doit déjà exister dans l'instance RDS de destination. Sinon, créez une base de données.
   	Compte de base de données	Saisissez le compte de l'instance RDS de destination. Pour connaître les exigences en matière d'autorisations, consultez la section Autorisations des comptes de base de données.
   	Mot de passe de la base de données	Saisissez le mot de passe du compte de base de données. Remarque Après avoir saisi les informations de la base de données de destination, vous pouvez cliquer sur Test Connectivity après Database Password pour vérifier que les informations saisies sont correctes. Si les informations sont correctes, un message Passed s'affiche. Si un message Failed s'affiche, cliquez sur Diagnose après Failed et ajustez les informations de la base de données de destination selon les instructions.

6. Cliquez sur Set Whitelist and Next en bas à droite.

   Si la source ou la destination est une instance de base de données Alibaba Cloud (telle que

   ApsaraDB RDS for MySQL

   ou

   ApsaraDB for MongoDB

   ), DTS ajoute automatiquement les plages CIDR des serveurs DTS de la région correspondante à la liste d'autorisation de l'instance. Si la source ou la destination est une base de données autonome sur une instance ECS, DTS ajoute automatiquement les plages CIDR des serveurs DTS aux règles du groupe de sécurité de l'instance ECS. Vous devez également vous assurer que la base de données autonome ne restreint pas l'accès depuis l'instance ECS. Si la base de données est un cluster déployé sur plusieurs instances ECS, vous devez ajouter manuellement les plages CIDR des serveurs DTS de la région aux règles du groupe de sécurité de chaque instance ECS supplémentaire. Si la source ou la destination est une base de données autonome dans un centre de données ou sur une autre plateforme cloud, vous devez ajouter manuellement les plages CIDR des serveurs DTS de la région correspondante pour autoriser l'accès. Pour obtenir la liste des plages CIDR des serveurs DTS, consultez la rubrique

   Plages CIDR des serveurs DTS

   .

   Avertissement

   L'ajout des plages CIDR publiques des serveurs DTS, qu'il soit automatique ou manuel, peut présenter des risques de sécurité. En utilisant ce produit, vous reconnaissez et acceptez ces risques potentiels. Il vous incombe de mettre en œuvre des mesures de sécurité de base, notamment l'utilisation de mots de passe robustes, la restriction des ports ouverts, l'utilisation de l'authentification pour les appels API internes, la révision et la restriction régulières des segments réseau inutiles, ou la connexion via des réseaux privés tels que Express Connect, VPN Gateway ou Smart Access Gateway.

7. Sélectionnez les types de migration et les objets à migrer.

   Paramètre	Description
   Types de migration	Pour effectuer uniquement une migration complète, sélectionnez Schema Migration et Full Data Migration. Pour migrer avec un temps d'arrêt minimal, sélectionnez Schema Migration, Full Data Migration et Incremental Data Migration. Cet exemple sélectionne les trois options. Remarque Si vous ne sélectionnez pas Incremental Data Migration, évitez d'écrire de nouvelles données dans la base de données source pendant la migration afin de garantir la cohérence des données.
   Objets de migration	Dans la zone Available Objects, sélectionnez les objets à migrer et cliquez sur pour les déplacer vers la zone Selected Objects. Remarque Vous pouvez sélectionner des objets au niveau du schéma, de la table ou de la colonne. Par défaut, les noms des objets migrés restent identiques dans la destination. Pour renommer les objets, utilisez la fonctionnalité de mappage des noms d'objets. Mappage des noms d'objets. Le mappage des noms d'objets peut entraîner l'échec de la migration des objets dépendants.
   Modifier les noms mappés	Pour renommer les objets de migration dans la destination, utilisez la fonctionnalité de mappage des noms d'objets. Mappage des noms d'objets.
   Durée de nouvelle tentative de connexion source et destination	La période de nouvelle tentative par défaut est de 12 heures. Vous pouvez la personnaliser. Si DTS se reconnecte dans ce délai, la tâche reprend automatiquement. Sinon, la tâche échoue. Remarque L'instance DTS est facturée pendant la période de nouvelle tentative. Personnalisez la période de nouvelle tentative en fonction de vos besoins, ou libérez l'instance DTS rapidement après la libération des instances source et de destination.

8. Une fois la configuration terminée, cliquez sur Precheck and Start en bas à droite de la page.

   Remarque

   • Avant le démarrage de la tâche de migration, DTS effectue une vérification préalable. La tâche ne peut démarrer qu'après avoir réussi cette vérification.

   • Si la vérification préalable échoue, cliquez sur l'icône à côté de l'élément ayant échoué pour afficher les détails.

     • Corrigez les problèmes selon les instructions et exécutez à nouveau la vérification préalable.

     • Si vous n'avez pas besoin de corriger les éléments d'avertissement, vous pouvez sélectionner Ignore puis cliquer sur Ignore Warnings and Rerun Precheck pour relancer la vérification préalable.

9. Une fois la tâche passée avec succès à la vérification préalable, cliquez sur Next.

10. Dans la boîte de dialogue Confirm Settings qui s'affiche, sélectionnez une Instance Class et cochez la case Data Transmission Service (pay-as-you-go) Service Terms.

11. Cliquez sur Buy and Start pour démarrer la tâche de migration.

Arrêter la tâche de migration

• Migration complète des données

  N'arrêtez pas manuellement une tâche pendant la migration complète des données. Sinon, le système risque de ne pas migrer toutes les données. Attendez que la tâche de migration se termine automatiquement.

• Migration incrémentielle des données

  Ce type de tâche ne s'arrête pas automatiquement ; vous devez l'arrêter manuellement.

  1. Attendez que la tâche passe à l'étape Incremental Data Migration avec un statut Undelayed. Ensuite, suspendez les écritures dans la base de données source pendant quelques minutes. Durant cette période, le statut Incremental Data Migration peut indiquer une latence.

  2. Attendez que le statut Incremental Data Migration revienne à Undelayed. Une fois cela confirmé dans la liste, cochez la case de la tâche et cliquez sur le bouton StopEnd dans la barre d'opérations par lot en bas.