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.

# Migration de données depuis des bases de données PostgreSQL avec des migrations de données homogènes dans AWS DMS
<a name="dm-migrating-data-postgresql"></a>

Vous pouvez utiliser [Migrations de données homogènes](data-migrations.md) pour migrer une base de données PostgreSQL autogérée vers RDS for PostgreSQL ou Aurora PostgreSQL. AWS DMS crée un environnement sans serveur pour la migration de vos données. Pour différents types de migrations de données, AWS DMS utilise différents outils de base de données PostgreSQL natifs.

Pour des migrations de données homogènes de type **Full load**, utilisez AWS DMS pg\$1dump pour lire les données de votre base de données source et les stocker sur le disque connecté à l'environnement sans serveur. Après avoir AWS DMS lu toutes vos données sources, il utilise pg\$1restore dans la base de données cible pour restaurer vos données.

Pour des migrations de données homogènes de type **CDC (Full Load and Change Data Capture)**, il AWS DMS permet `pg_dump` de lire des objets de schéma sans données de table depuis votre base de données source et de les stocker sur le disque connecté à l'environnement sans serveur. Il les utilise ensuite `pg_restore` dans la base de données cible pour restaurer les objets de votre schéma. Une fois le `pg_restore` processus AWS DMS terminé, il passe automatiquement à un modèle d'éditeur et d'abonné pour la réplication logique avec la `Initial Data Synchronization` possibilité de copier les données de table initiales directement de la base de données source vers la base de données cible, puis de lancer la réplication en cours. Dans ce modèle, un ou plusieurs abonnés s’abonnent à une ou plusieurs publications sur un nœud de diffuseur de publication.

Pour des migrations de données homogènes de type **Change data capture (CDC)**, le point de départ natif est AWS DMS requis pour démarrer la réplication. Si vous indiquez le point de départ natif, AWS DMS capture les modifications à partir de ce point. Vous pouvez également choisir **Immédiatement** dans les paramètres de migration des données pour capturer automatiquement le point de départ de la réplication lorsque la migration des données commence réellement.

**Note**  
Pour qu’une migration de CDC uniquement fonctionne correctement, tous les schémas et objets de base de données source doivent déjà être présents dans la base de données cible. La cible peut toutefois contenir des objets qui ne sont pas présents sur la source.

Vous pouvez utiliser l’exemple de code suivant pour obtenir le point de départ natif dans la base de données PostgreSQL.

```
select confirmed_flush_lsn from pg_replication_slots where slot_name=‘migrate_to_target';
```

Cette requête utilise la vue `pg_replication_slots` de la base de données PostgreSQL pour capturer la valeur du numéro de séquence de journal (LSN).

**Une fois AWS DMS que le statut de votre migration homogène de données PostgreSQL est défini sur Arrêté**,** Échec **ou** Supprimé, l'éditeur et la réplication ne sont pas supprimés.** Si vous ne souhaitez pas reprendre la migration, supprimez l’emplacement de réplication et le diffuseur de publication à l’aide de la commande suivante.

```
SELECT pg_drop_replication_slot('migration_subscriber_{ARN}');
            DROP PUBLICATION publication_{ARN};
```

Le schéma suivant montre le processus d'utilisation de migrations de données homogènes AWS DMS pour migrer une base de données PostgreSQL vers RDS for PostgreSQL ou Aurora PostgreSQL.

![\[Diagramme d’architecture de la migration de données PostgreSQL avec les migrations de données homogènes DMS.\]](http://docs.aws.amazon.com/fr_fr/dms/latest/userguide/images/data-migrations-postgresql.png)


## Bonnes pratiques d'utilisation d'une base de données PostgreSQL comme source pour des migrations de données homogènes
<a name="dm-migrating-data-postgresql.bp"></a>
+ Pour accélérer la synchronisation initiale des données côté abonné pour la tâche FLCDC, vous devez ajuster `max_logical_replication_workers` et. `max_sync_workers_per_subscription` L'augmentation de ces valeurs améliore la vitesse de synchronisation des tables.
  + **max\$1logical\$1replication\$1workers — Spécifie le nombre maximal de travailleurs** de réplication logique. Cela inclut à la fois les travailleurs d'application du côté des abonnés et les travailleurs de synchronisation des tables. 
  + **max\$1sync\$1workers\$1per\$1subscription** — L'augmentation `max_sync_workers_per_subscription` n'affecte que le nombre de tables synchronisées en parallèle, et non le nombre de travailleurs par table.
**Note**  
`max_logical_replication_workers`ne doit pas dépasser `max_worker_processes` et `max_sync_workers_per_subscription` doit être inférieur ou égal à`max_logical_replication_workers`.
+ Pour migrer de grands tableaux, pensez à les diviser en tâches distinctes à l'aide de règles de sélection. Par exemple, vous pouvez diviser les grands tableaux en tâches individuelles distinctes et les petits tableaux en une seule tâche.
+ Surveillez l'utilisation du disque et du processeur côté abonné pour maintenir des performances optimales.