Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Utilisation d’une base de données PostgreSQL en tant que source AWS DMS
Vous pouvez migrer les données d'une ou de plusieurs bases de données PostgreSQL à l'aide de. AWS DMS Avec une base de données PostgreSQL en tant que source, vous pouvez migrer les données vers une autre base de données PostgreSQL ou vers l’une des autres bases de données prises en charge.
Pour plus d'informations sur les versions de PostgreSQL compatibles en tant AWS DMS que source, consultez. Sources pour AWS DMS
AWS DMS prend en charge PostgreSQL pour les types de bases de données suivants :
-
Bases de données sur site
-
Bases de données sur une EC2 instance Amazon
-
Bases de données sur une instance de base de données Amazon RDS
-
Bases de données sur une instance de base de données basée sur Amazon Aurora PostgreSQL-Compatible Edition
-
Bases de données sur une instance de base de données basée sur Amazon Aurora PostgreSQL-Compatible Edition sans serveur
Note
DMS prend en charge Amazon Aurora PostgreSQL sans serveur V1 en tant que source pour le chargement complet uniquement. Mais vous pouvez utiliser Amazon Aurora PostgreSQL sans serveur V2 en tant que source pour les tâches Chargement complet, Chargement complet + CDC et CDC uniquement.
Version source de PostgreSQL |
AWS DMS version à utiliser |
---|---|
9.x, 10.x, 11.x, 12.x |
Utilisez n'importe quelle AWS DMS version disponible. |
13.x |
Utilisez AWS DMS la version 3.4.3 et supérieure. |
14.x |
Utilisez AWS DMS la version 3.4.7 ou supérieure. |
15.x |
Utilisez AWS DMS la version 3.5.1 ou supérieure. |
16.x |
Utilisez AWS DMS la version 3.5.3 ou supérieure. |
Vous pouvez utiliser Secure Socket Layers (SSL) pour chiffrer les connexions entre votre point de terminaison PostgreSQL et l’instance de réplication. Pour plus d'informations sur l'utilisation de SSL avec un point de terminaison PostgreSQL, consultez Utilisation du protocole SSL avec AWS Database Migration Service.
Lorsque vous utilisez PostgreSQL en tant que source, la seule exigence de sécurité supplémentaire consiste à ce que le compte d’utilisateur spécifié soit un utilisateur enregistré dans la base de données PostgreSQL.
Pour configurer une base de données PostgreSQL en tant que point de terminaison AWS DMS source, procédez comme suit :
-
Créez un utilisateur PostgreSQL doté des autorisations appropriées pour AWS DMS fournir l'accès à votre base de données source PostgreSQL.
Note
-
Si la base de données source PostgreSQL est autogérée, consultez Utilisation de bases de données PostgreSQL autogérées en tant que source dans AWS DMS pour plus d’informations.
-
Si la base de données source PostgreSQL est gérée par Amazon RDS, consultez Utilisation de bases de données PostgreSQL AWS gérées en tant que source DMS pour plus d’informations.
-
-
Créez un point de terminaison source PostgreSQL conforme à la configuration de base de données PostgreSQL que vous avez choisie.
-
Créez une tâche ou un ensemble de tâches pour migrer vos tables.
Pour créer une full-load-only tâche, aucune autre configuration de point de terminaison n'est nécessaire.
Avant de créer une tâche pour la capture des données de modification (une tâche CDC uniquement ou une tâche de chargement complet + CDC), consultez Activation du CDC en utilisant une base de données PostgreSQL autogérée comme source AWS DMS ou Activation du CDC avec une instance de base de données PostgreSQL AWS gérée avec AWS DMS.
Rubriques
Utilisation de bases de données PostgreSQL autogérées en tant que source dans AWS DMS
Utilisation de bases de données PostgreSQL AWS gérées en tant que source DMS
Activation de la capture des données de modification (CDC) à l’aide de la réplication logique
Utilisation de points de départ CDC natifs pour configurer la charge CDC d’une source PostgreSQL
Migration depuis Babelfish pour Amazon Aurora PostgreSQL à l'aide de AWS DMS
Supprimer AWS DMS des artefacts d'une base de données source PostgreSQL
Utilisation du paramètre de point de MapBooleanAsBoolean terminaison PostgreSQL
Limitations de l’utilisation d’une base de données PostgreSQL en tant que source DMS
Utilisation de bases de données PostgreSQL autogérées en tant que source dans AWS DMS
Avec une base de données PostgreSQL autogérée comme source, vous pouvez migrer les données vers une autre base de données PostgreSQL ou vers l'une des autres bases de données cibles prises en charge par. AWS DMS La source de base de données peut être une base de données sur site ou un moteur autogéré exécuté sur une instance Amazon EC2 . Vous pouvez utiliser une instance de base de données pour les tâches de chargement complet et pour les tâches de capture des données de modification (CDC).
Conditions préalables à l'utilisation d'une base de données PostgreSQL autogérée en tant que source AWS DMS
Avant de migrer des données à partir d’une base de données source PostgreSQL autogérée, procédez comme suit :
-
Assurez-vous d’utiliser une base de données PostgreSQL version 9.4.x ou ultérieure.
-
Pour les tâches de chargement complet + CDC ou les tâches de CDC uniquement, accordez des autorisations de super-utilisateur pour le compte d’utilisateur spécifié pour la base de données source PostgreSQL. Le compte d’utilisateur a besoin d’autorisations de super-utilisateur pour accéder aux fonctions spécifiques à la réplication dans la source. Pour les tâches de chargement complet uniquement, le compte d’utilisateur a besoin d’autorisations SELECT sur les tables afin de les migrer.
-
Ajoutez l'adresse IP du serveur de AWS DMS réplication au fichier de
pg_hba.conf
configuration et activez la réplication et les connexions par socket. Un exemple suit.# Replication Instance host all all 12.3.4.56/00 md5 # Allow replication connections from localhost, by a user with the # replication privilege. host replication dms 12.3.4.56/00 md5
Le fichier de configuration
pg_hba.conf
de PostgreSQL contrôle l'authentification du client. (HBA signifie authentification basée sur l'hôte.) Le fichier est traditionnellement stocké dans le répertoire de données du cluster de base de données. -
Si vous configurez une base de données comme source de réplication logique à l'aide AWS DMS de Activation du CDC en utilisant une base de données PostgreSQL autogérée comme source AWS DMS
Note
Certaines AWS DMS transactions restent inactives pendant un certain temps avant que le moteur DMS ne les réutilise. En utilisant le paramètre idle_in_transaction_session_timeout
dans PostgreSQL versions 9.6 et ultérieures, vous pouvez provoquer l’expiration et l’échec des transactions inactives. Ne mettez pas fin aux transactions inactives lorsque vous utilisez AWS DMS.
Activation du CDC en utilisant une base de données PostgreSQL autogérée comme source AWS DMS
AWS DMS prend en charge la capture des données de modification (CDC) à l'aide de la réplication logique. Pour activer la réplication logique d’une base de données source PostgreSQL autogérée, définissez les paramètres suivants dans le fichier de configuration postgresql.conf
:
-
Configurez
wal_level = logical
. -
Définissez une valeur supérieure à 1 pour
max_replication_slots
.Définissez la valeur
max_replication_slots
selon le nombre de tâches que vous souhaitez exécuter. Par exemple, pour exécuter cinq tâches, vous définissez au moins cinq emplacements. Les emplacements s'ouvrent automatiquement dès qu'une tâche commence et restent ouvert même lorsque la tâche n'est plus en cours d'exécution. Assurez-vous de supprimer manuellement les emplacements ouverts. Notez que DMS supprime automatiquement les emplacements de réplication lorsque la tâche est supprimée, si DMS les a créés. -
Définissez une valeur supérieure à 1 pour
max_wal_senders
.Le paramètre
max_wal_senders
définit le nombre de tâches simultanées qui peuvent s'exécuter. -
Le paramètre
wal_sender_timeout
met fin aux connexions de réplication qui sont inactives plus longtemps que le nombre de millisecondes spécifié. La valeur par défaut pour une base de données PostgreSQL sur site est de 60 000 millisecondes (60 secondes). La définition de la valeur sur 0 (zéro) désactive le mécanisme d’expiration et constitue une valeur valide pour DMS.Lorsque vous définissez
wal_sender_timeout
sur une valeur différente de zéro, une tâche DMS avec CDC nécessite au moins 10 000 millisecondes (10 secondes) et échoue si la valeur est inférieure à 10 000. Définissez une valeur inférieure à 5 minutes pour éviter tout retard lors du basculement multi-AZ d’une instance de réplication DMS.
Certains paramètres sont statiques et vous ne pouvez les définir qu’au démarrage du serveur. Toute modification apportée à leurs entrées dans le fichier de configuration (pour une base de données autogérée) ou le groupe de paramètres de base de données (pour une base de données RDS for PostgreSQL) est ignorée jusqu’au redémarrage du serveur. Pour de plus amples informations, veuillez consulter la documentation sur PostgreSQL
Pour plus d’informations sur l’activation de la CDC, consultez Activation de la capture des données de modification (CDC) à l’aide de la réplication logique.
Utilisation de bases de données PostgreSQL AWS gérées en tant que source DMS
Vous pouvez utiliser une instance de base de données PostgreSQL AWS gérée comme source pour. AWS DMS Vous pouvez effectuer à la fois des tâches de chargement complet et des tâches de capture des données de modification (CDC) à l’aide d’une source PostgreSQL gérée par AWS.
Conditions préalables à l'utilisation d'une base de AWS données PostgreSQL gérée comme source DMS
Avant de migrer des données depuis une base de données source AWS PostgreSQL gérée, procédez comme suit :
-
Nous vous recommandons d'utiliser un compte AWS utilisateur avec les autorisations minimales requises pour l'instance de base de données PostgreSQL comme compte utilisateur pour le point de terminaison source PostgreSQL pour. AWS DMS L’utilisation du compte principal n’est pas recommandée. Le compte doit avoir le rôle
rds_superuser
et le rôlerds_replication
. Le rôlerds_replication
accorde les autorisations permettant de gérer des emplacements logiques et de diffuser les données à l’aide d’emplacements logiques.Assurez-vous de créer plusieurs objets à partir du compte d’utilisateur principal pour le compte que vous utilisez. Pour en savoir plus sur la création de ces objets, consultez Migration d’une base de données Amazon RDS for PostgreSQL sans utiliser le compte d’utilisateur principal.
-
Si la base de données source se trouve dans un cloud privé virtuel (VPC), choisissez le groupe de sécurité de VPC qui permet d’accéder à l’instance de base de données où réside la base de données. Cette action est nécessaire pour que l’instance de réplication DMS se connecte avec succès à l’instance de base de données source. Lorsque la base de données et l’instance de réplication DMS se trouvent dans le même VPC, ajoutez le groupe de sécurité approprié à ses propres règles entrantes.
Note
Certaines AWS DMS transactions restent inactives pendant un certain temps avant que le moteur DMS ne les réutilise. En utilisant le paramètre idle_in_transaction_session_timeout
dans PostgreSQL versions 9.6 et ultérieures, vous pouvez provoquer l’expiration et l’échec des transactions inactives. Ne mettez pas fin aux transactions inactives lorsque vous utilisez AWS DMS.
Activation du CDC avec une instance de base de données PostgreSQL AWS gérée avec AWS DMS
AWS DMS prend en charge le CDC sur les bases de données PostgreSQL Amazon RDS lorsque l'instance de base de données est configurée pour utiliser la réplication logique. Le tableau suivant récapitule la compatibilité de réplication logique de chaque version de AWS PostgreSQL gérée.
Vous ne pouvez pas utiliser les réplicas en lecture RDS PostgreSQL pour la CDC (réplication continue).
Version PostgreSQL |
AWS DMS support de chargement complet |
AWS DMS Soutien du CDC |
---|---|---|
Compatibilité d’Aurora PostgreSQL version 2.1 avec PostgreSQL 10.5 (ou antérieur) |
Oui |
Non |
Compatibilité d’Aurora PostgreSQL version 2.2 avec PostgreSQL 10.6 (ou ultérieur) |
Oui |
Oui |
Compatibilité de RDS for PostgreSQL avec PostgreSQL 10.21 (ou ultérieur) |
Oui |
Oui |
Pour activer la réplication logique pour une instance DB RDS PostgreSQL
-
Utilisez le compte utilisateur AWS principal pour l'instance de base de données PostgreSQL comme compte utilisateur pour le point de terminaison source PostgreSQL. Le compte d'utilisateur principal a les rôles nécessaires qui lui permettent de configurer la capture des données modifiées.
Si vous utilisez un compte autre que le compte d’utilisateur principal, assurez-vous de créer plusieurs objets à partir du compte principal pour le compte que vous utilisez. Pour de plus amples informations, veuillez consulter Migration d’une base de données Amazon RDS for PostgreSQL sans utiliser le compte d’utilisateur principal.
-
Définissez le paramètre
rds.logical_replication
de votre groupe de paramètres DB CLUSTER sur 1. Ce paramètre statique nécessite un redémarrage de l'instance DB pour son application. Pour l'application de ce paramètre, AWS DMS définit les paramètreswal_level
,max_wal_senders
,max_replication_slots
etmax_connections
. Ces modifications de paramètres peuvent augmenter la génération WAL (Write ahead log) ; de sorte qu’il faut uniquement définirrds.logical_replication
lorsque vous utilisez des emplacements de réplication logique. -
Le paramètre
wal_sender_timeout
met fin aux connexions de réplication qui sont inactives plus longtemps que le nombre de millisecondes spécifié. La valeur par défaut pour une base de données PostgreSQL AWS gérée est de 30 000 millisecondes (30 secondes). La définition de la valeur sur 0 (zéro) désactive le mécanisme d’expiration et constitue une valeur valide pour DMS.Lorsque vous définissez
wal_sender_timeout
sur une valeur différente de zéro, une tâche DMS avec CDC nécessite au moins 10 000 millisecondes (10 secondes) et échoue si la valeur est comprise entre 0 et 10 000. Définissez une valeur inférieure à 5 minutes pour éviter tout retard lors du basculement multi-AZ d’une instance de réplication DMS. -
Assurez-vous que la valeur du paramètre
max_worker_processes
dans le groupe de paramètres de votre cluster de bases de données est supérieure ou égale aux valeurs combinées totales demax_logical_replication_workers
,autovacuum_max_workers
etmax_parallel_workers
. Un nombre élevé de processus de travail en arrière-plan peut avoir un impact sur les charges de travail d’application sur les instances de petite taille. Vous devez donc surveiller les performances de la base de données si vous définissezmax_worker_processes
sur une valeur supérieure à la valeur par défaut. -
Lorsque vous utilisez Aurora PostgreSQL comme source avec CDC, définissez sur.
synchronous_commit
ON
Migration d’une base de données Amazon RDS for PostgreSQL sans utiliser le compte d’utilisateur principal
Dans certains cas, vous risquez de ne pas utiliser le compte d’utilisateur principal pour l’instance de base de données Amazon RDS PostgreSQL que vous utilisez en tant que source. Dans ce cas, créez plusieurs objets afin de capturer des événements DDL (data definition language). Vous créez ces objets dans le compte autre que le compte principal, puis vous créez un déclencheur dans le compte utilisateur principal.
Note
Si vous définissez le paramètre de point de terminaison CaptureDdls
sur false
sur le point de terminaison source, vous n’avez pas besoin de créer la table et le déclencheur suivants sur la base de données source.
Utilisez la procédure suivante pour créer ces objets.
Pour créer des objets
-
Choisissez le schéma où les objets doivent être créés. Le schéma par défaut est
public
. Assurez-vous que le schéma existe et qu'il est accessible par le compte
.OtherThanMaster
-
Connectez-vous à l’instance de base de données PostgreSQL en utilisant un compte d’utilisateur autre que le compte principal, à savoir le compte
dans notre cas.OtherThanMaster
-
Créez la table
awsdms_ddl_audit
en exécutant la commande suivante, en remplaçant
dans le code suivant par le nom du schéma à utiliser.objects_schema
CREATE TABLE
objects_schema
.awsdms_ddl_audit ( c_key bigserial primary key, c_time timestamp, -- Informational c_user varchar(64), -- Informational: current_user c_txn varchar(16), -- Informational: current transaction c_tag varchar(24), -- Either 'CREATE TABLE' or 'ALTER TABLE' or 'DROP TABLE' c_oid integer, -- For future use - TG_OBJECTID c_name varchar(64), -- For future use - TG_OBJECTNAME c_schema varchar(64), -- For future use - TG_SCHEMANAME. For now - holds current_schema c_ddlqry text -- The DDL query associated with the current DDL event ); -
Créez la fonction
awsdms_intercept_ddl
en exécutant la commande suivante, en remplaçant
dans le code suivant par le nom du schéma à utiliser.objects_schema
CREATE OR REPLACE FUNCTION
objects_schema
.awsdms_intercept_ddl() RETURNS event_trigger LANGUAGE plpgsql SECURITY DEFINER AS $$ declare _qry text; BEGIN if (tg_tag='CREATE TABLE' or tg_tag='ALTER TABLE' or tg_tag='DROP TABLE' or tg_tag = 'CREATE TABLE AS') then SELECT current_query() into _qry; insert intoobjects_schema
.awsdms_ddl_audit values ( default,current_timestamp,current_user,cast(TXID_CURRENT()as varchar(16)),tg_tag,0,'',current_schema,_qry ); delete fromobjects_schema
.awsdms_ddl_audit; end if; END; $$; -
Déconnectez-vous du compte
et connectez-vous avec un compte auquel le rôleOtherThanMaster
rds_superuser
a été attribué. -
Créez le déclencheur d’événements
awsdms_intercept_ddl
en exécutant la commande suivante.CREATE EVENT TRIGGER awsdms_intercept_ddl ON ddl_command_end EXECUTE PROCEDURE
objects_schema
.awsdms_intercept_ddl(); -
Assurez-vous que tous les utilisateurs et rôles qui accèdent à ces événements disposent des autorisations DDL nécessaires. Par exemple :
grant all on public.awsdms_ddl_audit to public; grant all on public.awsdms_ddl_audit_c_key_seq to public;
Une fois que vous avez terminé la procédure précédente, vous pouvez créer le point de terminaison source AWS DMS
à l'aide du compte
.OtherThanMaster
Note
Ces événements sont déclenchés par les instructions CREATE TABLE
, ALTER
TABLE
et DROP TABLE
.
Activation de la capture des données de modification (CDC) à l’aide de la réplication logique
Vous pouvez utiliser la fonctionnalité de réplication logique native de PostgreSQL pour activer la capture des données de modification (CDC) lors de la migration de base de données pour les sources PostgreSQL. Vous pouvez utiliser cette fonctionnalité avec une instance de base de données PostgreSQL autogérée et avec une instance de base de données SQL Amazon RDS for PostgreSQL. Cette approche réduit les temps d’arrêt et permet de garantir que la base de données cible est synchronisée avec la base de données PostgreSQL source.
AWS DMS prend en charge le CDC pour les tables PostgreSQL avec des clés primaires. Si une table n’a pas de clé primaire, les journaux WAL n’incluent pas d’image antérieure de la ligne de base de données. Dans ce cas, DMS ne peut pas mettre à jour la table. Ici, vous pouvez utiliser des paramètres de configuration supplémentaires et l’identité du réplica de table comme solution de contournement. Toutefois, cette approche peut générer des journaux supplémentaires. Nous vous recommandons d’utiliser l’identité du réplica de table comme solution de contournement uniquement après avoir effectué des tests méticuleux. Pour de plus amples informations, veuillez consulter Paramètres de configuration supplémentaires lors de l’utilisation d’une base de données PostgreSQL en tant que source DMS.
Note
REPLICA IDENTITY FULL est compatible avec un plug-in de décodage logique, mais pas avec un plug-in pglogical. Pour plus d’informations, consultez la documentation de pglogical
Pour le chargement complet et les tâches CDC et CDC uniquement, AWS DMS utilise des emplacements de réplication logiques pour conserver les journaux WAL à des fins de réplication jusqu'à ce qu'ils soient décodés. Au redémarrage (et non à la reprise) pour une tâche de chargement complet + CDC ou une tâche de CDC, l’emplacement de réplication est recréé.
Note
Pour le décodage logique, DMS utilise le plug-in test_decoding ou pglogical. Si le plug-in pglogical est disponible sur une base de données PostgreSQL source, DMS crée un emplacement de réplication à l’aide de pglogical. Sinon, un plug-in test_decoding est utilisé. Pour plus d’informations sur le plug-in test_decoding, consultez la documentation de PostgreSQL
Si le paramètre de base de données max_slot_wal_keep_size
est défini sur une valeur autre que celle par défaut et que le paramètre restart_lsn
d’un emplacement de réplication dépasse la taille du LSN actuel, la tâche DMS échoue en raison de la suppression des fichiers WAL requis.
Configuration du plug-in pglogical
Mis en œuvre en tant qu’extension PostgreSQL, le plug-in pglogical est un système et un modèle de réplication logique pour la réplication sélective des données. Le tableau suivant identifie les versions de base de données PostgreSQL source qui prennent en charge le plug-in pglogical.
Source PostgreSQL |
Prend en charge pglogical |
---|---|
PostgreSQL 9.4 autogéré ou version ultérieure |
Oui |
Amazon RDS PostgreSQL 9.5 ou version antérieure |
Non |
Amazon RDS PostgreSQL 9.6 ou version ultérieure |
Oui |
Aurora PostgreSQL 1.x jusqu’à 2.5.x |
Non |
Aurora PostgreSQL 2.6.x ou version ultérieure |
Oui |
Aurora PostgreSQL 3.3.x ou version ultérieure |
Oui |
Avant de configurer pglogical pour l'utiliser avec AWS DMS, activez d'abord la réplication logique pour la capture des données de modification (CDC) sur votre base de données source PostgreSQL.
-
Pour en savoir plus sur l’activation de la réplication logique pour la CDC sur les bases de données sources PostgreSQL autogérées, consultez Activation du CDC en utilisant une base de données PostgreSQL autogérée comme source AWS DMS.
-
Pour en savoir plus sur l’activation de la réplication logique pour la CDC sur les bases de données sources PostgreSQL gérées par AWS, consultez Activation du CDC avec une instance de base de données PostgreSQL AWS gérée avec AWS DMS.
Une fois la réplication logique activée sur la base de données source PostgreSQL, suivez les étapes ci-dessous pour configurer pglogical en vue de son utilisation avec DMS.
Pour utiliser le plugin pglogical pour une réplication logique sur une base de données source PostgreSQL avec AWS DMS
-
Créez une extension pglogical sur la base de données PostgreSQL source :
-
Définissez le paramètre correct :
-
Pour les bases de données PostgreSQL autogérées, définissez le paramètre de base de données
shared_preload_libraries= 'pglogical'
. -
Pour les bases de données PostgreSQL sur Amazon RDS et Amazon Aurora PostgreSQL-Compatible Edition, définissez le paramètre
shared_preload_libraries
surpglogical
dans le même groupe de paramètres RDS.
-
-
Redémarrez la base de données source PostgreSQL.
-
Sur la base de données PostgreSQL, exécutez la commande
create extension pglogical;
.
-
-
Exécutez la commande suivante pour vérifier que pglogical a été correctement installé :
select * FROM pg_catalog.pg_extension
Vous pouvez désormais créer une AWS DMS tâche qui capture les données de modification pour le point de terminaison de votre base de données source PostgreSQL.
Note
Si vous n’activez pas pglogical dans la base de données source PostgreSQL, AWS DMS utilise le plug-in test_decoding
par défaut. Lorsque pglogical est activé pour le décodage logique, AWS DMS utilise pglogical par défaut. Mais vous pouvez définir l’attribut de connexion supplémentaire, PluginName
, pour utiliser le plug-in test_decoding
à la place.
Utilisation de points de départ CDC natifs pour configurer la charge CDC d’une source PostgreSQL
Pour activer les points de départ CDC natifs avec PostgreSQL en tant que source, définissez l’attribut de connexion supplémentaire slotName
sur le nom d’un emplacement de réplication logique existant lorsque vous créez le point de terminaison. Cet emplacement de réplication logique contient les modifications en cours à partir du moment de la création du point de terminaison, il prend donc en charge la réplication à partir d'un point précédent dans le temps.
PostgreSQL écrit les modifications de base de données dans des fichiers WAL qui sont uniquement ignorés après qu' AWS DMS a réussi à lire les modifications à partir de l'emplacement de réplication logique. L'utilisation d'emplacements de réplication logique permet de protéger les modifications consignées, pour qu’elles ne soient pas supprimées avant d’être consommées par le moteur de réplication.
Toutefois, selon le taux de changement et de consommation, les modifications conservées dans un emplacement de réplication logique peuvent entraîner une utilisation élevée du disque. Nous vous recommandons de définir des alarmes d’utilisation de l’espace dans l’instance PostgreSQL source lorsque vous utilisez des emplacements de réplication logique. Pour de plus amples informations sur l'utilisation de l'attribut de connexion supplémentaire slotName
, veuillez consulter Paramètres du point de terminaison et attributs de connexion supplémentaires (ECAs) lors de l'utilisation de PostgreSQL comme source DMS.
La procédure suivante décrit cette approche plus en détail.
Pour utiliser un point de départ CDC natif afin de configurer une charge CDC d'un point de terminaison source PostgreSQL
-
Identifiez l'emplacement de réplication logique utilisé par une tâche de réplication antérieure (tâche parent) que vous souhaitez utiliser comme point de départ. Ensuite, recherchez la vue
pg_replication_slots
de votre base de données source pour vous assurer que cet emplacement ne présente aucune connexion active. S’il en a, résolvez-les et fermez-les avant de poursuivre.Pour les étapes suivantes, il faut supposer que votre emplacement de réplication logique est
abc1d2efghijk_34567890_z0yx98w7_6v54_32ut_1srq_1a2b34c5d67ef
. -
Créez un nouveau point de terminaison source qui inclut le paramètre d'attribut de connexion supplémentaire suivant.
slotName=abc1d2efghijk_34567890_z0yx98w7_6v54_32ut_1srq_1a2b34c5d67ef;
-
Créez une nouvelle tâche uniquement CDC à l'aide de la console AWS CLI ou AWS DMS de l'API. Par exemple, à l’aide de l’interface de ligne de commande, vous pouvez exécuter la commande
create-replication-task
suivante.aws dms create-replication-task --replication-task-identifier postgresql-slot-name-test --source-endpoint-arn arn:aws:dms:us-west-2:012345678901:endpoint:ABCD1EFGHIJK2LMNOPQRST3UV4 --target-endpoint-arn arn:aws:dms:us-west-2:012345678901:endpoint:ZYX9WVUTSRQONM8LKJIHGF7ED6 --replication-instance-arn arn:aws:dms:us-west-2:012345678901:rep:AAAAAAAAAAA5BB4CCC3DDDD2EE --migration-type cdc --table-mappings "file://mappings.json" --cdc-start-position "4AF/B00000D0" --replication-task-settings "file://task-pg.json"
Dans la commande précédente, les options suivantes sont définies :
-
L’option
source-endpoint-arn
est définie sur la nouvelle valeur que vous avez créée à l’étape 2. -
L’option
replication-instance-arn
est définie sur la même valeur que pour la tâche parent à l’étape 1. -
Les options
table-mappings
etreplication-task-settings
sont définies sur les mêmes valeurs que pour la tâche parent à l’étape 1. -
L’option
cdc-start-position
est définie sur une valeur de position de départ. Pour trouver cette position de départ, recherchez la vuepg_replication_slots
de votre base de données source ou affichez les détails de la console pour la tâche parent à l'étape 1. Pour de plus amples informations, veuillez consulter Définition d'un point de départ natif CDC.
Pour activer le mode de démarrage CDC personnalisé lors de la création d'une nouvelle tâche uniquement CDC à l'aide de la AWS DMS console, procédez comme suit :
Dans la section Paramètres de tâche, pour Mode de départ CDC pour les transactions sources, choisissez Activer le mode de départ CDC personnalisé.
Pour Point de départ CDC personnalisé pour les transactions sources, choisissez Spécifier un numéro de séquence de journal. Spécifiez le numéro SCN ou choisissez Spécifier un point de contrôle de récupération et fournissez un point de contrôle de récupération.
Lorsque cette tâche CDC s'exécute, AWS DMS une erreur est générée si le slot de réplication logique spécifié n'existe pas. Il déclenche également une erreur si la tâche n’est pas créée avec un paramètre valide pour
cdc-start-position
. -
Lorsque vous utilisez des points de départ CDC natifs avec le plug-in pglogical et que vous souhaitez utiliser un nouvel emplacement de réplication, effectuez les étapes de configuration suivantes avant de créer une tâche de CDC.
Pour utiliser un nouvel emplacement de réplication qui n’a pas été créé précédemment dans le cadre d’une autre tâche DMS
-
Créez un emplacement de réplication, comme indiqué ci-dessous :
SELECT * FROM pg_create_logical_replication_slot('
replication_slot_name
', 'pglogical'); -
Une fois que la base de données a créé l’emplacement de réplication, obtenez les valeurs de restart_lsn et confirmed_flush_lsn pour l’emplacement et notez-les :
select * from pg_replication_slots where slot_name like 'replication_slot_name';
Notez que la position de départ CDC native d’une tâche de CDC créée après l’emplacement de réplication ne peut pas être antérieure à la valeur de confirmed_flush_lsn.
Pour en savoir plus sur les valeurs de restart_lsn et confirmed_flush_lsn, consultez pg_replication_slots
. -
Créez un nœud pglogical.
SELECT pglogical.create_node(node_name := '
node_name
', dsn := 'your_dsn_name
'); -
Créez deux ensembles de réplications à l’aide de la fonction
pglogical.create_replication_set
. Le premier ensemble de réplications assure le suivi des mises à jour et des suppressions des tables dotées de clés primaires. Le deuxième ensemble de réplications assure uniquement le suivi des insertions et porte le même nom que le premier ensemble de réplications, avec le préfixe « i ».SELECT pglogical.create_replication_set('
replication_slot_name
', false, true, true, false); SELECT pglogical.create_replication_set('ireplication_slot_name
', true, false, false, true); -
Ajoutez une table à l’ensemble de réplications.
SELECT pglogical.replication_set_add_table('
replication_slot_name
', 'schemaname.tablename', true); SELECT pglogical.replication_set_add_table('ireplication_slot_name
', 'schemaname.tablename', true); -
Définissez l’attribut de connexion supplémentaire (ECA) suivant lorsque vous créez le point de terminaison source.
PluginName=PGLOGICAL;slotName=
slot_name
;
Vous pouvez désormais créer une tâche de CDC uniquement avec un point de départ natif PostgreSQL à l’aide du nouvel emplacement de réplication. Pour plus d’informations sur le plug-in pglogical, consultez la documentation de pglogical 3.7
Migration de PostgreSQL vers PostgreSQL à l'aide de AWS DMS
Lorsque vous migrez d'un moteur de base de données autre que PostgreSQL vers une base de données PostgreSQL AWS DMS , c'est presque toujours le meilleur outil de migration à utiliser. En revanche, lorsque vous effectuez une migration à partir d’une base de données PostgreSQL vers une base de données PostgreSQL, les outils PostgreSQL peuvent être plus efficaces.
Utilisation des outils natifs PostgreSQL pour migrer des données
Nous vous recommandons d’utiliser les outils de migration de base de données PostgreSQL, par exemple pg_dump
, dans les conditions suivantes :
-
Vous avez une migration homogène, dans laquelle vous effectuez une migration d'une base de données PostgreSQL source vers une base de données PostgreSQL cible.
-
Vous migrez une base de données entière.
-
Les outils natifs vous permettent de migrer vos données avec une interruption minimale.
L’utilitaire pg_dump utilise la commande COPY pour créer un schéma et un vidage des données d’une base de données PostgreSQL. Le script de vidage généré par pg_dump charge les données dans une base de données portant le même nom et recrée les tables, les index et les clés étrangères. Pour restaurer les données dans une base de données portant un autre nom, utilisez la commande pg_restore
et le paramètre -d
.
Si vous migrez des données d'une base de données source PostgreSQL exécutée EC2 sur une cible Amazon RDS for PostgreSQL, vous pouvez utiliser le plugin pglogical.
Pour plus d’informations sur l’importation d’une base de données PostgreSQL dans Amazon RDS for PostgreSQL ou Amazon Aurora PostgreSQL-Compatible Edition, consultez https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/PostgreSQL.Procedural.Importing.html.
Utilisation de DMS pour migrer des données de PostgreSQL vers PostgreSQL
AWS DMS peut migrer des données, par exemple, d'une base de données PostgreSQL source installée sur site vers une instance Amazon RDS for PostgreSQL ou Aurora PostgreSQL cible. La migration des types de données PostgreSQL principaux ou de base réussit souvent.
Note
Lorsque vous répliquez des tables partitionnées d’une source PostgreSQL vers une cible PostgreSQL, il n’est pas nécessaire de mentionner la table parent dans les critères de sélection de la tâche DMS. En mentionnant la table parent, cela déclenche la duplication des données dans les tables enfants de la cible, ce qui peut entraîner une violation de la PK. En sélectionnant uniquement les tables enfants dans les critères de sélection du mappage de table, la table parent est automatiquement remplie.
Les types de données pris en charge sur la base de données source mais non pris en charge sur la cible risquent de ne pas réussir à migrer. AWS DMS diffuse certains types de données sous forme de chaînes si le type de données est inconnu. La migration de certains types de données, tels que JSON et XML, peut réussir s'il s'agit de fichiers peu volumineux, mais peut échouer s'il s'agit de documents volumineux.
Lorsque vous effectuez une migration du type de données, prenez en considération ce qui suit :
-
Dans certains cas, le type de données PostgreSQL NUMERIC(p,s) ne spécifie aucune précision ni aucune échelle. Pour DMS versions 3.4.2 et versions antérieures, DMS utilise une précision de 28 et une échelle de 6 par défaut, soit NUMERIC(28,6). Par exemple, la valeur 0,611111104488373 de la source est convertie en 0,611111 sur la cible PostgreSQL.
-
Une table avec un type de données ARRAY doit posséder une clé primaire. Une table dont le type de données ARRAY ne contient pas de clé primaire est suspendue pendant le chargement complet.
Le tableau suivant montre les types de données PostgreSQL source et indique si leur migration peut réussir :
Type de données | Réussite de la migration | Migre partiellement | Ne migre pas | Commentaires |
---|---|---|---|---|
INTEGER | X | |||
SMALLINT | X | |||
BIGINT | X | |||
NUMERIC/DECIMAL(p,s) | X | Où 0<p<39 et 0<s | ||
NUMERIC/DECIMAL | X | Où p>38 ou p=s=0 | ||
REAL | X | |||
DOUBLE | X | |||
SMALLSERIAL | X | |||
SERIAL | X | |||
BIGSERIAL | X | |||
MONEY | X | |||
CHAR | X | Sans précision spécifiée | ||
CHAR(n) | X | |||
VARCHAR | X | Sans précision spécifiée | ||
VARCHAR(n) | X | |||
TEXT | X | |||
BYTEA | X | |||
TIMESTAMP | X | Les valeurs infinies positives et négatives sont tronquées à « 9999-12-31 23:59:59 » et « 4713-01-01 00:00:00 BC » respectivement. | ||
TIMESTAMP WITH TIME ZONE | X | |||
DATE | X | |||
TIME | X | |||
TIME WITH TIME ZONE | X | |||
INTERVAL | X | |||
BOOLEAN | X | |||
ENUM | X | |||
CIDR | X | |||
INET | X | |||
MACADDR | X | |||
TSVECTOR | X | |||
TSQUERY | X | |||
xml | X | |||
POINT | X | Type de données spatiales PostGIS | ||
LINE | X | |||
LSEG | X | |||
BOX | X | |||
PATH | X | |||
POLYGON | X | Type de données spatiales PostGIS | ||
CIRCLE | X | |||
JSON | X | |||
ARRAY | X | Nécessite une clé primaire | ||
COMPOSITE | X | |||
RANGE | X | |||
LINESTRING | X | Type de données spatiales PostGIS | ||
MULTIPOINT | X | Type de données spatiales PostGIS | ||
MULTILINESTRING | X | Type de données spatiales PostGIS | ||
MULTIPOLYGON | X | Type de données spatiales PostGIS | ||
GEOMETRYCOLLECTION | X | Type de données spatiales PostGIS |
Migration de types de données spatiales PostGIS
Les données spatiales identifient les informations géométriques d'un objet ou d'un emplacement dans l'espace. Les bases de données relationnelles objet PostgreSQL prennent en charge les types de données spatiales PostGIS.
Avant de migrer des objets de données spatiales PostgreSQL, assurez-vous que le plug-in PostGIS est activé au niveau global. Cela garantit la AWS DMS création des colonnes de données spatiales source exactes pour l'instance de base de données cible PostgreSQL.
Pour les migrations homogènes de PostgreSQL vers PostgreSQL AWS DMS , prend en charge la migration des types et sous-types d'objets de données géométriques et géographiques (coordonnées géodésiques) de PostGIS tels que les suivants :
-
POINT
-
LINESTRING
-
POLYGON
-
MULTIPOINT
-
MULTILINESTRING
-
MULTIPOLYGON
-
GEOMETRYCOLLECTION
Migration depuis Babelfish pour Amazon Aurora PostgreSQL à l'aide de AWS DMS
Vous pouvez migrer les tables sources PostgreSQL de Babelfish for Aurora vers tous les points de terminaison cibles pris en charge à l'aide de. AWS DMS
Lorsque vous créez votre point de terminaison AWS DMS source à l'aide de la console DMS, de l'API ou des commandes CLI, vous définissez la source sur Amazon Aurora PostgreSQL et le nom de la base de données sur. babelfish_db
Dans la section Paramètres du point de terminaison, assurez-vous que le DatabaseModeest défini sur Babelfish et que le nom de la base de données Babelfish T-SQL source BabelfishDatabaseNameest défini sur Babelfish. Au lieu d'utiliser le port TCP Babelfish1433
, utilisez le port TCP Aurora PostgreSQL. 5432
Vous devez créer vos tables avant de migrer les données afin de vous assurer que DMS utilise les types de données et les métadonnées de table appropriés. Si vous ne créez pas vos tables sur la cible avant d'exécuter la migration, DMS peut créer les tables avec des types de données et des autorisations incorrects.
Ajout de règles de transformation à votre tâche de migration
Lorsque vous créez une tâche de migration pour une source Babelfish, vous devez inclure des règles de transformation garantissant que DMS utilise les tables cibles pré-créées.
Si vous avez défini le mode de migration multi-bases de données lorsque vous avez défini votre cluster Babelfish pour PostgreSQL, ajoutez une règle de transformation qui renomme le nom du schéma en schéma T-SQL. Par exemple, si le nom du schéma T-SQL est le même que dbo
celui de votre schéma Babelfish pour PostgreSQLmydb_dbo
, renommez le schéma en utilisant une règle de transformation. dbo
Pour trouver le nom du schéma PostgreSQL, consultez l'architecture de Babelfish dans le guide de l'utilisateur Amazon Aurora.
Si vous utilisez le mode base de données unique, il n'est pas nécessaire d'utiliser une règle de transformation pour renommer les schémas de base de données. Les noms de schéma PostgreSQL sont mappés aux noms one-to-one de schéma de la base de données T-SQL.
L'exemple de règle de transformation suivant montre comment renommer le nom du schéma de mydb_dbo
retour en dbo
:
{ "rules": [ { "rule-type": "transformation", "rule-id": "566251737", "rule-name": "566251737", "rule-target": "schema", "object-locator": { "schema-name": "mydb_dbo" }, "rule-action": "rename", "value": "dbo", "old-value": null }, { "rule-type": "selection", "rule-id": "566111704", "rule-name": "566111704", "object-locator": { "schema-name": "mydb_dbo", "table-name": "%" }, "rule-action": "include", "filters": [] } ] }
Limitations liées à l'utilisation d'un point de terminaison source PostgreSQL avec des tables Babelfish
Les limitations suivantes s'appliquent lors de l'utilisation d'un point de terminaison source PostgreSQL avec des tables Babelfish :
DMS prend uniquement en charge la migration depuis Babelfish version 16.2/15.6 et versions ultérieures, et DMS version 3.5.3 et ultérieure.
DMS ne reproduit pas les modifications de définition de table Babelfish sur le point de terminaison cible. Une solution à cette limitation consiste à appliquer d'abord les modifications de définition de table sur la cible, puis à modifier la définition de table sur la source Babelfish.
Lorsque vous créez des tables Babelfish avec le type de données BYTEA, DMS les convertit en type de
varbinary(max)
données lors de la migration vers SQL Server en tant que cible.DMS ne prend pas en charge le mode LOB complet pour les types de données binaires. Utilisez plutôt le mode LOB limité pour les types de données binaires.
DMS ne prend pas en charge la validation des données pour Babelfish en tant que source.
Pour le réglage de la tâche en mode de préparation de la table cible, utilisez uniquement les modes Ne rien faire ou Tronquer. N’utilisez pas le mode Supprimer les tables sur la cible. Lorsque vous utilisez Drop tables on target, DMS peut créer les tables avec des types de données incorrects.
Lorsque vous utilisez la réplication continue (CDC ou Full load et CDC), définissez l'attribut de connexion
PluginName
supplémentaire (ECA) surTEST_DECODING
.-
DMS ne prend pas en charge la réplication (CDC ou Full load et CDC) de tables partitionnées pour Babelfish en tant que source.
Supprimer AWS DMS des artefacts d'une base de données source PostgreSQL
Pour capturer les événements DDL, AWS DMS crée divers artefacts dans la base de données PostgreSQL lorsqu'une tâche de migration démarre. Lorsque la tâche se termine, vous pouvez supprimer ces objets.
Pour supprimer les artefacts, émettez les instructions suivantes (dans leur ordre d’apparition), où {AmazonRDSMigration}
est le schéma dans lequel les artefacts ont été créés. Procédez avec prudence lors de la suppression d’un schéma. Ne supprimez jamais un schéma opérationnel, surtout s'il est public.
drop event trigger awsdms_intercept_ddl;
Le déclencheur d'événements n'appartient pas à un schéma spécifique.
drop function {AmazonRDSMigration}.awsdms_intercept_ddl() drop table {AmazonRDSMigration}.awsdms_ddl_audit drop schema {AmazonRDSMigration}
Paramètres de configuration supplémentaires lors de l’utilisation d’une base de données PostgreSQL en tant que source DMS
Vous pouvez ajouter des paramètres de configuration supplémentaires lors de la migration des données d'une base de données PostgreSQL de deux façons :
-
Vous pouvez ajouter des valeurs à l'attribut de connexion supplémentaire pour capturer les événements DDL et pour spécifier le schéma dans lequel les objets de base de données DDL opérationnelle sont créés. Pour de plus amples informations, veuillez consulter Paramètres du point de terminaison et attributs de connexion supplémentaires (ECAs) lors de l'utilisation de PostgreSQL comme source DMS.
-
Vous pouvez remplacer les paramètres de chaîne de connexion. Choisissez cette option pour effectuer l’une des opérations suivantes :
-
Spécifiez les AWS DMS paramètres internes. Ces paramètres étant rarement nécessaires, ils ne sont pas présentés dans l’interface utilisateur.
-
Spécifiez les valeurs pass-through (passthru) pour le client de base de données spécifique. AWS DMS inclut des paramètres intermédiaires dans la chaîne de connexion transmise au client de base de données.
-
-
En utilisant le paramètre au niveau de la table dans les versions 9.4 et supérieures de
REPLICA IDENTITY
PostgreSQL, vous pouvez contrôler les informations écrites dans write-ahead logs (). WALs Il le fait notamment pour identifier WALs les lignes mises à jour ou supprimées.REPLICA IDENTITY FULL
enregistre les anciennes valeurs de toutes les colonnes de la ligne. À utiliserREPLICA IDENTITY FULL
avec précaution pour chaque table, car il n'est peut-être pas nécessaire deFULL
générer un nombre supplémentaire de WALs ce qui pourrait ne pas être nécessaire. Pour plus d’informations, consultez ALTER TABLE-REPLICA IDENTITY.
Utilisation du paramètre de point de MapBooleanAsBoolean terminaison PostgreSQL
Vous pouvez utiliser les paramètres de point de terminaison PostgreSQL pour mapper un booléen en tant que booléen de votre source PostgreSQL à une cible Amazon Redshift. Par défaut, un type BOOLEAN est migré au format varchar(5). Vous pouvez indiquer à MapBooleanAsBoolean
d’autoriser PostgreSQL à migrer le type booléen en tant que booléen, comme illustré dans l’exemple suivant.
--postgre-sql-settings '{"MapBooleanAsBoolean": true}'
Notez que vous devez définir ce paramètre à la fois sur les points de terminaison sources et cibles pour qu’il prenne effet.
Étant donné que MySQL n’a pas de type BOOLEAN, utilisez une règle de transformation plutôt que ce paramètre lors de la migration de données BOOLEAN vers MySQL.
Paramètres du point de terminaison et attributs de connexion supplémentaires (ECAs) lors de l'utilisation de PostgreSQL comme source DMS
Vous pouvez utiliser les paramètres du point de terminaison et les attributs de connexion supplémentaires (ECAs) pour configurer votre base de données source PostgreSQL. Vous spécifiez les paramètres du point de terminaison lorsque vous créez le point de terminaison source à l'aide de la AWS DMS console ou à l'aide de la create-endpoint
commande dans le AWS CLI, avec la syntaxe --postgre-sql-settings '{"
JSON.EndpointSetting"
:
"value"
, ...
}'
Le tableau suivant indique les paramètres du point de terminaison ECAs que vous pouvez utiliser avec PostgreSQL en tant que source.
Nom d'attribut | Description |
---|---|
|
Pour capturer les événements DDL, AWS DMS crée divers artefacts dans la base de données PostgreSQL au démarrage de la tâche. Vous pouvez ensuite supprimer ces objets comme décrit dans Supprimer AWS DMS des artefacts d'une base de données source PostgreSQL. Si cette valeur est définie sur false, vous n’avez pas besoin de créer de tables ni de déclencheurs dans la base de données source. Heure à laquelle les événements DDL sont enregistrés. Valeur par défaut : Valeurs valides : true/false Exemple : |
|
Utilisé pour contrôler la façon dont les transactions monolithiques comportant des numéros de séquence de log (LSNs) dupliqués sont répliquées. Lorsque ce paramètre est défini Valeur par défaut : Valeurs valides : false/true Exemple : |
|
Définit le schéma dans lequel les artefacts de base de données DDL opérationnels sont créés. Valeur par défaut : public Valeurs valides : string Exemple : |
|
Désactive le filtre de source Unicode avec PostgreSQL pour les valeurs transmises au filtre de règles de sélection sur les valeurs des colonnes Source Endpoint. Par défaut, DMS effectue des comparaisons de filtres source à l'aide d'une chaîne Unicode, ce qui peut faire en sorte que les recherches ignorent les index dans les colonnes de texte et ralentissent les migrations. Le support Unicode ne doit être désactivé que si un filtre de règles de sélection est utilisé sur une colonne de texte de la base de données source indexée. Valeur par défaut : false Valeurs valides : true/false Exemple : |
|
Définit le délai d'attente de déclaration client pour l'instance PostgreSQL, en secondes. La valeur par défaut est de 60 secondes. Exemple : |
|
Lorsque la valeur est définie sur Si une tâche est définie sur le mode LOB limité et que cette option a pour valeur true, la tâche échoue au lieu de tronquer les données LOB. Valeur par défaut : false Valeurs valides : booléen Exemple : |
|
Cet attribut de connexion supplémentaire (ECA) définit le nombre de lignes que le curseur va extraire pendant le chargement complet. En fonction des ressources disponibles dans l’instance de réplication, vous pouvez augmenter ou réduire la valeur. Valeur par défaut : Valeurs valides : nombre Exemple d’ECA : |
|
La fonction WAL Heartbeat imite une transaction fictive, de sorte que les emplacements de réplication logiques inactifs ne conservent pas les anciens journaux WAL, ce qui se traduit par des situations de saturation du stockage sur la source. Cette pulsation permet de relancer l'exécution de Valeur par défaut : Valeurs valides : true/false Exemple : |
|
Définit la fréquence de pulsation du WAL (en minutes). Valeur par défaut : Valeurs valides : nombre Exemple : |
|
Définit le schéma dans lequel les artefacts de pulsation sont créés. Valeur par défaut : Valeurs valides : string Exemple : |
|
Par défaut, AWS DMS mappe JSONB à NCLOB. Vous pouvez indiquer à Exemple : |
|
Par défaut, AWS DMS mappe VARCHAR à WSTRING. Vous pouvez indiquer à
Exemple : |
|
Ce paramètre traite les colonnes contenant des types de données NUMERIC illimités comme STRING afin de réussir la migration sans perte de précision de la valeur numérique. Utilisez ce paramètre uniquement pour la réplication d’une source PostgreSQL vers une cible PostgreSQL ou pour des bases de données compatibles avec PostgreSQL. Valeur par défaut : Valeurs valides : Exemple : L’utilisation de ce paramètre peut entraîner une certaine dégradation des performances de réplication en raison de la transformation de la valeur numérique en chaîne, puis à nouveau en valeur numérique. Ce paramètre est compatible avec DMS versions 3.4.4 et ultérieures. NoteUtilisez L’utilisation de N’utilisez pas |
|
Spécifie le plugin à utiliser pour créer un emplacement de réplication. Valeurs valides : Exemple : |
|
Définit le nom d'un emplacement de réplication logique précédemment créé pour une charge CDC de l'instance PostgreSQL source. Lorsqu'il est utilisé avec le paramètre de Pour de plus amples informations sur la configuration du paramètre de demande Valeurs valides : string Exemple : |
|
Cet attribut de connexion supplémentaire (ECA) définit la taille maximale d'une colonne de données définie en tant que type VarChar sans spécificateur de longueur maximale. La valeur par défaut est de 8 000 octets. La valeur maximale est de 1 048 5760 octets. |
Limitations de l’utilisation d’une base de données PostgreSQL en tant que source DMS
Les limites suivantes s'appliquent lorsque vous utilisez PostgreSQL comme source pour AWS DMS :
-
AWS DMS ne fonctionne pas avec Amazon RDS pour PostgreSQL 10.4 ou Amazon Aurora PostgreSQL 10.4 en tant que source ou cible.
-
Une table capturée doit posséder une clé primaire. Si une table ne possède pas de clé primaire, AWS DMS ignore les opérations d'enregistrement DELETE et UPDATE pour cette table. Consultez Activation de la capture des données de modification (CDC) à l’aide de la réplication logique pour obtenir une solution de contournement.
Remarque : il n’est pas recommandé d’effectuer une migration sans clé primaire/index unique. Dans le cas contraire, des limitations supplémentaires s’appliquent, telles que la capacité d’application par lots « NO », le mode LOB complet, la validation des données et l’impossibilité de répliquer efficacement vers une cible Redshift.
-
AWS DMS ignore une tentative de mise à jour d'un segment de clé primaire. Dans ces cas, la cible identifie la mise à jour comme une mise à jour n'ayant mis à jour aucune ligne. Toutefois, comme les résultats de la mise à jour d'une clé primaire dans PostgreSQL sont imprévisibles, aucun enregistrement n'est écrit dans la table d'exceptions.
-
AWS DMS ne prend pas en charge l'option d'exécution Start Process Changes from Timestamp.
-
AWS DMS ne reproduit pas les modifications résultant d'opérations de partition ou de sous-partition (
ADD
DROP
, ouTRUNCATE
). -
La réplication de plusieurs tables portant le même nom lorsque chaque nom a une majuscule différente (par exemple, table1 et table1) peut entraîner un comportement imprévisible. TABLE1 En raison de ce problème, AWS DMS ne prend pas en charge ce type de réplication.
-
Dans la plupart des cas, AWS DMS prend en charge le traitement des modifications des instructions DDL CREATE, ALTER et DROP pour les tables. AWS DMS ne prend pas en charge ce traitement des modifications si les tables sont contenues dans un bloc de corps de fonction ou de procédure interne ou dans d'autres constructions imbriquées.
Par exemple, la modification suivante n’est pas capturée.
CREATE OR REPLACE FUNCTION attu.create_distributors1() RETURNS void LANGUAGE plpgsql AS $$ BEGIN create table attu.distributors1(did serial PRIMARY KEY,name varchar(40) NOT NULL); END; $$;
-
Actuellement, les types de données
boolean
dans une source PostgreSQL sont migrés vers une cible SQL Server en tant que type de donnéesbit
avec des valeurs incohérentes. Pour contourner le problème, créez au préalable la table avec un type deVARCHAR(1)
données pour la colonne (ou demandez à AWS DMS de créer la table). Ensuite, faites en sorte que le traitement en aval traite un « F » comme Faux et un « T » comme Vrai. -
AWS DMS ne prend pas en charge le traitement des modifications des opérations TRUNCATE.
-
Le type de données LOB OID n'est pas migré vers la cible.
AWS DMS prend en charge le type de données PostGIS uniquement pour les migrations homogènes.
-
Si votre source est une base de données PostgreSQL sur site ou sur une instance EC2 Amazon, assurez-vous que le plug-in de sortie test_decoding est installé sur votre point de terminaison source. Vous trouverez ce plug-in dans le package contrib PostgreSQL. Pour plus d'informations sur le plug-in test_decoding, consultez la documentation PostgreSQL
. -
AWS DMS ne prend pas en charge le traitement des modifications pour définir ou annuler les valeurs par défaut des colonnes (en utilisant la clause ALTER COLUMN SET DEFAULT sur les instructions ALTER TABLE).
-
AWS DMS ne prend pas en charge le traitement des modifications pour définir la nullité des colonnes (en utilisant la clause ALTER COLUMN [SET|DROP] NOT NULL sur les instructions ALTER TABLE).
-
Lorsque la réplication logique est activée, le nombre maximal de modifications conservées en mémoire par transaction est de 4 Mo. Ensuite, les modifications sont déversées sur le disque. En conséquence,
ReplicationSlotDiskUsage
augmente etrestart_lsn
n’avance pas tant que la transaction n’est pas terminée ou arrêtée et que la restauration n’est pas terminée. Comme il s’agit d’une transaction longue, sa restauration peut prendre beaucoup de temps. Évitez donc les transactions de longue durée ou les nombreuses sous-transactions lorsque la réplication logique est activée. Divisez plutôt la transaction en plusieurs transactions plus petites.Sur les versions 13 et ultérieures d'Aurora PostgreSQL, vous pouvez régler le paramètre pour contrôler
logical_decoding_work_mem
le moment où des déversements de DMS modifient les données sur le disque. Pour de plus amples informations, veuillez consulter Déversez des fichiers dans Aurora PostgreSQL. -
Une table avec un type de données ARRAY doit posséder une clé primaire. Une table dont le type de données ARRAY ne contient pas de clé primaire est suspendue pendant le chargement complet.
-
AWS DMS ne prend pas en charge la réplication de tables partitionnées. Lorsqu'une table partitionnée est détectée, voici ce qui se produit :
-
Le point de terminaison indique la liste des tables parent et enfant.
-
AWS DMS crée la table sur la cible en tant que table normale avec les mêmes propriétés que les tables sélectionnées.
-
Si la table parent dans la base de données source a la même valeur de clé primaire que ses tables enfants, une erreur « clé dupliquée » est générée.
-
-
Afin de répliquer les tables partitionnés d’une source PostgreSQL vers une cible PostgreSQL, commencez par créer manuellement les tables parent et enfant sur la cible. Définissez ensuite une tâche distincte pour effectuer la réplication sur ces tables. Dans ce cas, définissez la configuration de la tâche sur Tronquer avant le chargement.
-
Le type de données PostgreSQL
NUMERIC
n'est pas fixe. Lors du transfert de données de typeNUMERIC
sans précision ni échelle, DMS utiliseNUMERIC(28,6)
(une précision de 28 et une échelle de 6) par défaut. Par exemple, la valeur 0,611111104488373 de la source est convertie en 0,611111 sur la cible PostgreSQL. -
AWS DMS prend en charge Aurora PostgreSQL Serverless V1 en tant que source pour les tâches à chargement complet uniquement. AWS DMS prend en charge Aurora PostgreSQL Serverless V2 en tant que source pour les tâches à chargement complet, à chargement complet, CDC et CDC uniquement.
-
AWS DMS ne prend pas en charge la réplication d'une table avec un index unique créé à l'aide d'une fonction de coalesce.
-
Si la définition de la clé primaire sur la source et la cible ne correspond pas, les résultats de la réplication peuvent être imprévisibles.
-
Lorsque vous utilisez la fonctionnalité de chargement parallèle, la segmentation de table en fonction des partitions ou des sous-partitions n’est pas prise en charge. Pour plus d’informations sur le chargement parallèle, consultez Utilisation du chargement parallèle pour certaines tables, vues et collections.
-
AWS DMS ne prend pas en charge les contraintes différées.
-
AWS DMS la version 3.4.7 prend en charge PostgreSQL 14.x en tant que source avec les limitations suivantes :
-
AWS DMS ne prend pas en charge le traitement des modifications lors de validations en deux phases.
-
AWS DMS ne prend pas en charge la réplication logique pour diffuser de longues transactions en cours.
-
-
AWS DMS ne prend pas en charge le proxy CDC pour Amazon RDS pour PostgreSQL en tant que source.
-
Lorsque vous utilisez des filtres de source qui ne contiennent pas de colonne de clé primaire, les opérations
DELETE
ne sont pas capturées. -
Si la base de données source est également la cible d’un autre système de réplication tiers, les modifications DDL risquent de ne pas être migrées pendant la CDC. En effet, cette situation peut empêcher le déclencheur d’événement
awsdms_intercept_ddl
de s’activer. Pour contourner ce problème, modifiez ce déclencheur dans la base de données source comme suit :alter event trigger awsdms_intercept_ddl enable always;
-
AWS DMS ne prend pas en charge le cluster de bases de données multi-AZ CDC pour Amazon RDS pour PostgreSQL en tant que source, car les clusters de bases de données multi-AZ RDS pour PostgreSQL ne prennent pas en charge la réplication logique.
Types de données sources pour PostgreSQL
Le tableau suivant indique les types de données sources PostgreSQL pris en charge lors de l' AWS DMS utilisation et le mappage AWS DMS par défaut vers les types de données.
Pour en savoir plus sur la façon d'afficher le type de données qui est mappé dans la cible, consultez la section concernant le point de terminaison cible que vous utilisez.
Pour plus d'informations sur AWS DMS les types de données, consultezTypes de données pour AWS Database Migration Service.
Types de données PostgreSQL |
Types de données DMS |
---|---|
INTEGER |
INT4 |
SMALLINT |
INT2 |
BIGINT |
INT8 |
NUMERIC (p,s) |
Si la précision se situe entre 0 et 38, utilisez NUMERIC. Si la précision est 39 ou supérieure, utilisez STRING. |
DECIMAL(P,S) |
Si la précision se situe entre 0 et 38, utilisez NUMERIC. Si la précision est 39 ou supérieure, utilisez STRING. |
REAL |
REAL4 |
DOUBLE |
REAL8 |
SMALLSERIAL |
INT2 |
SERIAL |
INT4 |
BIGSERIAL |
INT8 |
MONEY |
NUMERIC(38,4) Le type de données MONEY est mappé sur FLOAT dans SQL Server. |
CHAR |
WSTRING (1) |
CHAR(N) |
WSTRING (n) |
VARCHAR(N) |
WSTRING (n) |
TEXT |
NCLOB |
CITEXT |
NCLOB |
BYTEA |
BLOB |
TIMESTAMP |
DATETIME |
TIMESTAMP WITH TIME ZONE |
DATETIME |
DATE |
DATE |
TIME |
TIME |
TIME WITH TIME ZONE |
TIME |
INTERVAL |
STRING (128) : 1 YEAR, 2 MONTHS, 3 DAYS, 4 HOURS, 5 MINUTES, 6 SECONDS |
BOOLEAN |
CHAR (5) Vrai ou faux ? |
ENUM |
STRING (64) |
CIDR |
STRING (50) |
INET |
STRING (50) |
MACADDR |
STRING (18) |
BIT (n) |
STRING (n) |
BIT VARYING (n) |
STRING (n) |
UUID |
CHAÎNE |
TSVECTOR |
CLOB |
TSQUERY |
CLOB |
xml |
CLOB |
POINT |
STRING (255) "(x,y)" |
LINE |
STRING (255) "(x,y,z)" |
LSEG |
STRING (255) "((x1,y1),(x2,y2))" |
BOX |
STRING (255) "((x1,y1),(x2,y2))" |
PATH |
CLOB "((x1,y1),(xn,yn))" |
POLYGON |
CLOB "((x1,y1),(xn,yn))" |
CIRCLE |
STRING (255) "(x,y),r" |
JSON |
NCLOB |
JSONB |
NCLOB |
ARRAY |
NCLOB |
COMPOSITE |
NCLOB |
HSTORE |
NCLOB |
INT4GAMME |
STRING (255) |
INT8GAMME |
STRING (255) |
NUMRANGE |
STRING (255) |
STRRANGE |
STRING (255) |
Utilisation des types de données source LOB pour PostgreSQL
Les tailles de colonne PostgreSQL affectent la conversion des types de données LOB PostgreSQL en types de données AWS DMS . Pour utiliser cela, procédez comme suit pour les types de données AWS DMS :
-
BLOB : définissez Limiter la taille LOB à sur la valeur Taille LOB maximale (Ko) lors de la création de la tâche.
-
CLOB — La réplication traite chaque caractère comme un UTF8 caractère. Par conséquent, recherchez la longueur de la chaîne de caractères la plus longue dans la colonne, à savoir
max_num_chars_text
dans cet exemple. Utilisez cette longueur pour spécifier la valeur de Limiter la taille LOB à. Si les données comprennent des caractères à 4 octets, multipliez par 2 pour spécifier la valeur, en octets, de Limit LOB size to (Limiter la taille LOB à) Dans ce cas, la valeur de Limit LOB size to (Limiter la taille LOB à) est égale àmax_num_chars_text
multiplié par 2. -
NCLOB : la réplication gère chaque caractère en tant que caractère à deux octets. Par conséquent, recherchez la longueur de la chaîne de caractères la plus longue dans la colonne (
max_num_chars_text
) et multipliez-la par 2. Faites-le pour spécifier la valeur de Limiter la taille LOB à. Dans ce cas, la valeur de Limit LOB size to (Limiter la taille LOB à) est égale àmax_num_chars_text
multiplié par 2. Si les données comprennent des caractères à 4 octets, multipliez encore par 2. Dans ce cas, la valeur de Limit LOB size to (Limiter la taille LOB à) est égale àmax_num_chars_text
multiplié par 4.