Utilisation d'une base de données PostgreSQL comme cible pour AWS Database Migration Service

Vous pouvez migrer des données vers des bases de données PostgreSQL à AWS DMS l'aide d'une autre base de données PostgreSQL ou de 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 cible, consultez. Objectifs pour AWS DMS

Note

• Amazon Aurora Serverless est disponible en tant que cible pour Amazon Aurora compatible avec PostgreSQL. Pour plus d'informations sur Amazon Aurora Serverless, consultez la section Utilisation d'Amazon Aurora Serverless v2 dans le guide de l'utilisateur Amazon Aurora.

• Les clusters de bases de données Aurora sans serveur sont uniquement accessibles à partir d’un réseau Amazon VPC et ne peuvent pas utiliser d’adresse IP publique. Par conséquent, si vous avez l’intention de disposer d’une instance de réplication dans une région différente de celle d’Aurora PostgreSQL sans serveur, vous devez configurer l’appairage de VPC. Sinon, vérifiez la disponibilité des régions Aurora PostgreSQL sans serveur et décidez d’utiliser l’une de ces régions à la fois pour Aurora PostgreSQL sans serveur et pour votre instance de réplication.

• La fonctionnalité Babelfish est intégrée à Amazon Aurora et n’entraîne aucun coût supplémentaire. Pour plus d’informations, consultez Utilisation de Babelfish for Aurora PostgreSQL en tant que cible pour AWS Database Migration Service.

AWS DMS adopte une table-by-table approche lors de la migration des données de la source vers la cible pendant la phase de chargement complet. L'ordre des tables pendant la phase de chargement complet ne peut pas être garanti. Les tables ne sont pas synchronisées pendant la phase de chargement complet et pendant que les transactions mises en cache pour les tables individuelles sont appliquées. En conséquence, les contraintes actives d'intégrité référentielle peuvent entraîner l'échec d'une tâche pendant la phase de chargement complet.

Dans PostgreSQL, les clés étrangères (contraintes d'intégrité référentielle) sont mises en œuvre à l'aide de déclencheurs. Pendant la phase de chargement complet, AWS DMS charge chaque table une par une. Nous vous recommandons vivement de désactiver les contraintes de clé étrangère pendant un chargement complet, à l'aide de l'une des méthodes suivantes :

• Désactivez temporairement tous les déclencheurs depuis l'instance, et terminez le chargement complet.

• Utilisez le paramètre session_replication_role dans PostgreSQL.

À un instant donné, un déclencheur peut être dans l'un des états suivants : origin, replica, always ou disabled. Lorsque le paramètre session_replication_role a la valeur replica, seuls les déclencheurs ayant l'état replica sont actifs et sont déclenchés lorsqu'ils sont appelés. Sinon, les déclencheurs demeurent inactifs.

PostgreSQL possède un mécanisme failsafe pour empêcher qu'une table soit tronquée, même lorsque session_replication_role est défini. Vous pouvez l'utiliser comme alternative à la désactivation des déclencheurs, afin d'aider le chargement complet à s'exécuter intégralement. Pour ce faire, définissez le mode de préparation des tables cible avec la valeur DO_NOTHING. Dans le cas contraire, les opérations DROP et TRUNCATE échouent lorsqu'il existe des contraintes de clé étrangère.

Dans Amazon RDS, vous pouvez définir ce paramètre à l’aide d’un groupe de paramètres. Pour une instance PostgreSQL s’exécutant sur Amazon EC2, vous pouvez définir le paramètre directement.

Pour plus d'informations sur l'utilisation d'une base de données PostgreSQL en tant que cible AWS DMS pour, consultez les sections suivantes :

Limitations relatives à l'utilisation de PostgreSQL comme cible pour AWS Database Migration Service

Les limitations suivantes s'appliquent lors de l'utilisation d'une base de données PostgreSQL comme cible pour AWS DMS :

• Pour les migrations hétérogènes, le type de données JSON est converti en type de données CLOB natif en interne.

• Lors d'une migration d'Oracle vers PostgreSQL, si une colonne d'Oracle contient un caractère NULL (valeur hexadécimale U+0000) AWS DMS , le caractère NULL est converti en espace (valeur hexadécimale U+0020). Cela est dû à une limitation PostgreSQL.

• AWS DMS ne prend pas en charge la réplication vers une table avec un index unique créé avec la fonction de coalesce.

• Si vos tables utilisent des séquences, mettez à jour la valeur de NEXTVAL pour chaque séquence dans la base de données cible après avoir arrêté la réplication depuis la base de données source. AWS DMS copie les données de votre base de données source, mais ne migre pas les séquences vers la cible pendant la réplication en cours.

Exigences de sécurité lors de l'utilisation d'une base de données PostgreSQL comme cible pour AWS Database Migration Service

À des fins de sécurité, le compte d'utilisateur utilisé pour la migration des données doit être un utilisateur enregistré dans une base de données PostgreSQL que vous utilisez comme cible.

Votre point de terminaison cible PostgreSQL nécessite des autorisations utilisateur minimales pour exécuter AWS DMS une migration, consultez les exemples suivants.

    CREATE USER newuser WITH PASSWORD 'your-password';
    ALTER SCHEMA schema_name OWNER TO newuser;
            

Ou

    GRANT USAGE ON SCHEMA schema_name TO myuser;
    GRANT CONNECT ON DATABASE postgres to myuser;
    GRANT CREATE ON DATABASE postgres TO myuser;
    GRANT CREATE ON SCHEMA schema_name TO myuser;
    GRANT UPDATE, INSERT, SELECT, DELETE, TRUNCATE ON ALL TABLES IN SCHEMA schema_name TO myuser;
    GRANT TRUNCATE ON schema_name."BasicFeed" TO myuser;
            

Paramètres du point de terminaison et attributs de connexion supplémentaires (ECA) lors de l'utilisation de PostgreSQL comme cible pour AWS DMS

Vous pouvez utiliser les paramètres des points de terminaison et les attributs de connexion supplémentaires (ECA) pour configurer votre base de données cible PostgreSQL.

Vous spécifiez les paramètres lorsque vous créez le point de terminaison cible à 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 '{"EndpointSetting": "value", ...}' JSON.

Vous spécifiez les ECA à l'aide du ExtraConnectionAttributes paramètre de votre point de terminaison.

Les paramètres de point de terminaison que vous pouvez utiliser avec PostgreSQL en tant que cible sont indiqués dans le tableau suivant.

Name (Nom)	Description
MaxFileSize	Spécifie la taille maximale (en Ko) de tout fichier .csv utilisé pour transférer des données vers PostgreSQL. Valeur par défaut : 32 768 Ko (32 Mo) Valeurs valides : 1 à 1 048 576 Ko (jusqu’à 1,1 Go) Exemple : --postgre-sql-settings '{"MaxFileSize": 512}'
ExecuteTimeout	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 : --postgre-sql-settings '{"ExecuteTimeout": 100}'
AfterConnectScript= SET session_replication_role = replica	Cet attribut permet de AWS DMS contourner les clés étrangères et les déclencheurs utilisateur afin de réduire le temps nécessaire au chargement groupé des données.
MapUnboundedNumericAsString	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 : false Valeurs valides : false/true Exemple : --postgre-sql-settings '{"MapUnboundedNumericAsString": "true"} 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. Note Utilisez MapUnboundedNumericAsString uniquement dans les points de terminaison source et cible PostgreSQL ensemble. L’utilisation de MapUnboundedNumericAsString sur les points de terminaison PostgreSQL source limite la précision à 28 pendant la CDC. L’utilisation de MapUnboundedNumericAsString sur les points de terminaison cibles migre les données avec une précision de 28 et une échelle de 6. N’utilisez pas MapUnboundedNumericAsString avec des cibles autres que PostgreSQL.
loadUsingCSV	Utilisez cet attribut de connexion supplémentaire (ECA) pour transférer des données pour les opérations de chargement complet à l'aide de la commande \ COPY. Valeur par défaut : true Valeurs valides : true/false Exemple d’ECA : loadUsingCSV=true; Remarque : le fait de définir cet ECA sur false peut entraîner une certaine dégradation des performances de réplication en raison de l'exécution directe des INSERTS.
DatabaseMode	Utilisez cet attribut pour modifier le comportement par défaut de la gestion par la réplication des points de terminaison compatibles avec Postgresql qui nécessitent une configuration supplémentaire, tels que les points de terminaison Babelfish. Valeur par défaut : DEFAULT Valeurs valides : DEFAULT, BABELFISH Exemple : DatabaseMode=default;
BabelfishDatabaseName	Utilisez cet attribut pour spécifier le nom de la base de données T-SQL Babelfish cible vers laquelle la migration est effectuée. Obligatoire si DatabaseMode est défini sur Babelfish. Il ne s’agit pas de la base de données babelfish_db réservée. Exemple : BabelfishDatabaseName=TargetDb;

Types de données cibles pour PostgreSQL

Le point de terminaison de base de données PostgreSQL pour AWS DMS prend en charge la plupart des types de données de base de données PostgreSQL. Le tableau suivant indique les types de données cibles de base de données PostgreSQL pris en charge lors de l' AWS DMS utilisation et le mappage AWS DMS par défaut à partir des types de données.

Pour plus d'informations sur AWS DMS les types de données, consultezTypes de données pour AWS Database Migration Service.

AWS DMS type de données	Type de données PostgreSQL
BOOLEAN	BOOLEAN
BLOB	BYTEA
BYTES	BYTEA
DATE	DATE
TIME	TIME
DATETIME	Si l'échelle s'étend de 0 à 6, utilisez TIMESTAMP. Si l'échelle s'étend de 7 à 9, utilisez VARCHAR (37).
INT1	SMALLINT
INT2	SMALLINT
INT4	INTEGER
INT8	BIGINT
NUMERIC	DECIMAL (P,S)
REAL4	FLOAT4
REAL8	FLOAT8
CHAÎNE	Si la longueur est comprise entre 1 et 21 845, utilisez VARCHAR (longueur en octets). Si la longueur est comprise entre 21 846 et 2 147 483 647, utilisez VARCHAR (65535).
UINT1	SMALLINT
UINT2	INTEGER
UINT4	BIGINT
UINT8	BIGINT
WSTRING	Si la longueur est comprise entre 1 et 21 845, utilisez VARCHAR (longueur en octets). Si la longueur est comprise entre 21 846 et 2 147 483 647, utilisez VARCHAR (65535).
NCLOB	TEXT
CLOB	TEXT

Note

Lors de la réplication à partir d'une source PostgreSQL AWS DMS , crée la table cible avec les mêmes types de données pour toutes les colonnes, à l'exception des colonnes avec des types de données définis par l'utilisateur. Dans ces cas, le type de données est créé en tant que « character varying » dans la cible.

Utilisation de Babelfish pour Aurora PostgreSQL comme cible pour AWS Database Migration Service

Vous pouvez migrer les tables sources SQL Server vers une cible Babelfish for Amazon Aurora PostgreSQL à l’aide d’ AWS Database Migration Service. Avec Babelfish, Aurora PostgreSQL comprend T-SQL, le dialecte SQL propriétaire de Microsoft SQL Server, et prend en charge le même protocole de communication. Ainsi, les applications écrites pour SQL Server peuvent désormais fonctionner avec Aurora avec moins de modifications de code. La fonctionnalité Babelfish est intégrée à Amazon Aurora et n’entraîne aucun coût supplémentaire. Vous pouvez activer Babelfish sur votre cluster Amazon Aurora à partir de la console Amazon RDS.

Lorsque vous créez votre point de terminaison AWS DMS cible à l'aide des commandes de AWS DMS console, d'API ou de CLI, spécifiez le moteur cible comme Amazon Aurora PostgreSQL et nommez la base de données babelfish_db. Dans la section Paramètres de point de terminaison, ajoutez les paramètres pour définir DatabaseMode sur Babelfish et BabelfishDatabaseName sur le nom de la base de données Babelfish T-SQL cible.

Ajout de règles de transformation à votre tâche de migration

Lorsque vous définissez une tâche de migration pour une cible Babelfish, vous devez inclure des règles de transformation garantissant que DMS utilise les tables Babelfish T-SQL pré-créées dans la base de données cible.

Commencez par ajouter une règle de transformation à votre tâche de migration qui convertit tous les noms de table en minuscules. Babelfish stocke en minuscules dans le catalogue pg_class PostgreSQL les noms des tables que vous créez à l’aide de T-SQL. Toutefois, lorsque vous avez des tables SQL Server avec des noms en casse mixte, DMS crée les tables en utilisant les types de données natifs PostgreSQL au lieu des types de données compatibles T-SQL. Pour cette raison, veillez à ajouter une règle de transformation qui convertit tous les noms de table en minuscules. Notez que les noms de colonnes ne doivent pas être convertis en minuscules.

Ensuite, si vous avez utilisé le mode de migration à plusieurs bases de données lorsque vous avez défini votre cluster, ajoutez une règle de transformation qui renomme le schéma SQL Server d’origine. Assurez-vous de renommer le nom du schéma SQL Server de sorte à inclure le nom de la base de données T-SQL. Par exemple, si le nom du schéma SQL Server d’origine est dbo et que le nom de la base de données T-SQL est mydb, renommez le schéma mydb_dbo en utilisant une règle de transformation.

Si vous utilisez le mode à une seule base de données, vous n’avez pas besoin d’une règle de transformation pour renommer les noms de schéma. Les noms de schéma sont one-to-one mappés avec la base de données T-SQL cible dans Babelfish.

L’exemple de règle de transformation suivant convertit tous les noms de table en minuscules et renomme le nom du schéma SQL Server d’origine dbo en mydb_dbo.

{
   "rules": [
   {
      "rule-type": "transformation",
      "rule-id": "566251737",
      "rule-name": "566251737",
      "rule-target": "schema",
      "object-locator": {
         "schema-name": "dbo"
      },
      "rule-action": "rename",
      "value": "mydb_dbo",
      "old-value": null
   },
   {
      "rule-type": "transformation",
      "rule-id": "566139410",
      "rule-name": "566139410",
      "rule-target": "table",
      "object-locator": {
         "schema-name": "%",
         "table-name": "%"
      },
      "rule-action": "convert-lowercase",
      "value": null,
      "old-value": null
   },
   {
      "rule-type": "selection",
      "rule-id": "566111704",
      "rule-name": "566111704",
      "object-locator": {
         "schema-name": "dbo",
         "table-name": "%"
      },
      "rule-action": "include",
      "filters": []
   }
]
}          
            

Limitations de l’utilisation d’un point de terminaison cible PostgreSQL avec des tables Babelfish

Les limitations suivantes s’appliquent lors de l’utilisation d’un point de terminaison cible PostgreSQL avec des tables Babelfish :

• Pour le mode Préparation de table cible, utilisez uniquement les modes Ne rien faire ou Tronquer. N’utilisez pas le mode Supprimer les tables sur la cible. Dans ce mode, DMS crée les tables en tant que tables PostgreSQL que T-SQL peut ne pas reconnaître.

• AWS DMS ne prend pas en charge le type de données sql_variant.

• Babelfish ne prend pas en charge les types de données HEIRARCHYID, GEOMETRY et GEOGRAPHY. Pour migrer ces types de données, vous pouvez ajouter des règles de transformation pour convertir le type de données en wstring(250).

• Babelfish ne prend en charge que la migration des types de données BINARY, VARBINARY et IMAGE avec le type de données BYTEA. Pour les versions antérieures d’Aurora PostgreSQL, vous pouvez utiliser DMS pour migrer ces tables vers un point de terminaison cible Babelfish. Il n’est pas nécessaire de spécifier une longueur pour le type de données BYTEA, comme illustré dans l’exemple suivant.

  [Picture] [VARBINARY](max) NULL

  Remplacez le type de données T-SQL précédent par le type de données BYTEA pris en charge par T-SQL.

  [Picture] BYTEA NULL

• Pour les versions antérieures d’Aurora PostgreSQL Babelfish, si vous créez une tâche de migration pour une réplication continue de SQL Server vers Babelfish à l’aide du point de terminaison cible PostgreSQL, vous devez affecter le type de données SERIAL à toutes les tables utilisant des colonnes IDENTITY. À partir d’Aurora PostgreSQL (versions 15.3/14.8 et ultérieures) et de Babelfish (versions 3.2.0 et ultérieures), la colonne d’identité est prise en charge et il n’est plus nécessaire d’affecter le type de données SERIAL. Pour plus d’informations, consultez Syntaxe de SERIAL dans la section Séquences et identité du Manuel de migration de SQL Server vers Aurora PostgreSQL. Ensuite, lorsque vous créez la table dans Babelfish, modifiez la définition de colonne comme suit.

      [IDCol] [INT] IDENTITY(1,1) NOT NULL PRIMARY KEY

  Modifiez la ligne précédente comme suit.

      [IDCol] SERIAL PRIMARY KEY

  Aurora PostgreSQL compatible avec Babelfish crée une séquence en utilisant la configuration par défaut et ajoute une contrainte NOT NULL à la colonne. La séquence récemment créée se comporte comme une séquence normale (incrémentée de 1) et ne possède aucune option SERIAL composite.

• Après avoir migré les données avec des tables qui utilisent des colonnes IDENTITY ou le type de données SERIAL, réinitialisez l’objet de séquence basé sur PostgreSQL en fonction de la valeur maximale de la colonne. Après avoir effectué un chargement complet des tables, utilisez la requête T-SQL suivante pour générer des instructions afin d’amorcer l’objet de séquence associé.

  DECLARE @schema_prefix NVARCHAR(200) = ''
  
  IF current_setting('babelfishpg_tsql.migration_mode') = 'multi-db'
          SET @schema_prefix = db_name() + '_'
  
  SELECT 'SELECT setval(pg_get_serial_sequence(''' + @schema_prefix + schema_name(tables.schema_id) + '.' + tables.name + ''', ''' + columns.name + ''')
                 ,(select max(' + columns.name + ') from ' + schema_name(tables.schema_id) + '.' + tables.name + '));'
  FROM sys.tables tables
  JOIN sys.columns columns ON tables.object_id = columns.object_id
  WHERE columns.is_identity = 1
  
  UNION ALL
  
  SELECT 'SELECT setval(pg_get_serial_sequence(''' + @schema_prefix + table_schema + '.' + table_name + ''', 
  ''' + column_name + '''),(select max(' + column_name + ') from ' + table_schema + '.' + table_name + '));'
  FROM information_schema.columns
  WHERE column_default LIKE 'nextval(%';
  

  La requête génère une série d’instructions SELECT que vous exécutez afin de mettre à jour les valeurs maximales d’IDENTITY et de SERIAL.

• Pour les versions de Babelfish antérieures à 3.2, le Mode LOB complet peut entraîner une erreur de table. Dans ce cas, créez une tâche distincte pour les tables qui n’ont pas pu être chargées. Utilisez ensuite le Mode LOB limité pour spécifier la valeur appropriée pour Taille de LOB maximale (Ko). Sinon, vous pouvez définir le paramètre de l’attribut de connexion du point de terminaison SQL ServerForceFullLob=True.

• Pour les versions de Babelfish antérieures à 3.2, la validation des données avec des tables Babelfish qui n’utilisent pas de clés primaires basées sur des entiers génère un message indiquant qu’aucune clé unique appropriée n’a été trouvée. À partir d’Aurora PostgreSQL (versions 15.3/14.8 et ultérieures) et de Babelfish (versions 3.2.0 et ultérieures), la validation des données pour les clés primaires non entières est prise en charge.

• En raison des différences de précision dans le nombre de décimales par seconde, DMS signale des échecs de validation des données pour les tables Babelfish qui utilisent les types de données DATETIME. Pour éviter ces échecs, vous pouvez ajouter le type de règle de validation suivant pour les types de données DATETIME.

  {
           "rule-type": "validation",
           "rule-id": "3",
           "rule-name": "3",
           "rule-target": "column",
           "object-locator": {
               "schema-name": "dbo",
               "table-name": "%",
               "column-name": "%",
               "data-type": "datetime"
           },
           "rule-action": "override-validation-function",
           "source-function": "case when ${column-name} is NULL then NULL else 0 end",
           "target-function": "case when ${column-name} is NULL then NULL else 0 end"
       }