Google utilise la technologie IA pour traduire le contenu dans votre langue préférée. Les traductions générées par IA peuvent contenir des erreurs.

Configurer votre base de données PostgreSQL source pour les migrations continues

Cette page explique comment configurer vos instances de base de données sources pour les migrations PostgreSQL homogènes standards. Si vous souhaitez utiliser les migrations automatisées, suivez le guide Utiliser les migrations automatisées. Les migrations à démarrage rapide offrent un flux de migration simplifié qui utilise la réplication pgnative et une connectivité spécialisée basée sur les interfaces Private Service Connect. Pour en savoir plus, consultez À propos des migrations de démarrage rapide dans la documentation principale de Database Migration Service.

Cette page comprend des sections pour chaque source compatible :

PostgreSQL autogéré (sur site ou sur une VM Compute Engine)
Amazon RDS pour PostgreSQL
Amazon Aurora pour PostgreSQL
Microsoft Azure Database for PostgreSQL Flexible Server
Cloud SQL pour PostgreSQL

Configurer une source PostgreSQL autogérée

Pour configurer une instance source PostgreSQL autogérée (sur site ou hébergée sur une VM Compute Engine) pour votre processus de migration, procédez comme suit :

Pour les sources PostgreSQL autogérées, Database Migration Service migre toutes les bases de données de votre instance source, à l'exception des bases de données de modèles template0 et template1.
Assurez-vous que votre instance source inclut la base de données postgres par défaut. Si cette base de données n'existe pas, créez-la avant de configurer votre migration.
Configurez l'authentification du client réseau dans votre fichier pg_hba.conf. Ajoutez des entrées autorisant les connexions de réplication et l'accès à la base de données à partir de l'adresse IP sortante Cloud SQL de destination, de la plage CIDR du VPC ou de l'hôte bastion SSH inversé :
```
# Allow replication connections
host  replication  MIGRATION_USER_ACCOUNT_NAME  DESTINATION_IP_OR_CIDR  md5
# Allow database access
host  all          MIGRATION_USER_ACCOUNT_NAME  DESTINATION_IP_OR_CIDR  md5
```
Rechargez la configuration PostgreSQL pour appliquer les règles pg_hba.conf :
```
SELECT pg_reload_conf();
```
Vérifiez les extensions PostgreSQL installées sur vos bases de données sources. Database Migration Service ne migre pas les extensions non compatibles avec Cloud SQL. Vérifiez que les objets de votre base de données source et les requêtes d'application ne font pas référence à des extensions non compatibles. Avant de continuer, supprimez les extensions et les références non compatibles de vos bases de données sources.
L'extension pg_cron n'est pas migrée automatiquement par Database Migration Service, mais elle est compatible avec les destinations Cloud SQL pour PostgreSQL. Si vous utilisez pg_cron dans votre base de données source, réinstallez-le et configurez-le sur l'instance de destination après avoir promu la migration.
Créez un compte utilisateur dédié à la migration dans votre instance source et accordez-lui les droits nécessaires :
1. Connectez-vous à l'instance source à l'aide d'un compte administrateur, créez l'utilisateur et attribuez-lui le rôle de réplication :
```
CREATE USER MIGRATION_USER_ACCOUNT_NAME WITH PASSWORD 'PASSWORD';
ALTER USER MIGRATION_USER_ACCOUNT_NAME WITH REPLICATION;
```
2. Accordez au compte utilisateur de migration les autorisations requises pour la base de données postgres par défaut ainsi que pour chaque base de données que vous souhaitez migrer. Exécutez les commandes suivantes sur chaque base de données pour chaque schéma (à l'exception du schéma d'informations et des schémas commençant par pg_) :
```
GRANT USAGE ON SCHEMA SCHEMA_NAME TO "MIGRATION_USER_ACCOUNT_NAME";
GRANT USAGE ON SCHEMA pglogical TO PUBLIC;
GRANT SELECT ON ALL TABLES IN SCHEMA pglogical TO "MIGRATION_USER_ACCOUNT_NAME";
GRANT SELECT ON ALL TABLES IN SCHEMA SCHEMA_NAME TO "MIGRATION_USER_ACCOUNT_NAME";
GRANT SELECT ON ALL SEQUENCES IN SCHEMA SCHEMA_NAME TO "MIGRATION_USER_ACCOUNT_NAME";
```
Installez l'extension pglogical sur chaque base de données que vous souhaitez migrer, à l'exception de template0 et template1 :
- Pour PostgreSQL version 9.4 : exécutez la commande suivante :
```
CREATE EXTENSION IF NOT EXISTS pglogical;
CREATE EXTENSION IF NOT EXISTS pglogical_origin;
```
- Pour PostgreSQL 9.5 et versions ultérieures : exécutez la commande suivante :
```
CREATE EXTENSION IF NOT EXISTS pglogical;
```
Vérifiez que vos tables ont des clés primaires. Pour les migrations continues, la réplication logique PostgreSQL nécessite que les tables disposent de clés primaires pour répliquer les opérations UPDATE et DELETE pendant la phase de capture des données modifiées (CDC) :
- Les tables avec une clé primaire répliquent automatiquement toutes les opérations INSERT, UPDATE et DELETE.
- Pour les tables qui ne possèdent pas de clés primaires, Database Migration Service permet de migrer uniquement l'instantané initial ainsi que les instructions INSERT ultérieures pendant la phase de CDC. Vous devez migrer les instructions UPDATE et DELETE manuellement.
  Nous vous recommandons d'ajouter des clés primaires aux tables qui n'en ont pas avant de commencer la migration. Pour savoir comment générer une requête permettant de lister les tables d'une base de données PostgreSQL sans clés primaires, ou comment migrer manuellement les opérations UPDATE et DELETE, consultez Débogage et autres outils.
  
  Vous pouvez également essayer d'utiliser le flux de migration de démarrage rapide : un scénario de migration simplifié dans lequel vous pouvez utiliser REPLICA IDENTITY pour migrer des tables sans clé primaire. Pour en savoir plus, consultez le guide Utiliser les migrations à démarrage rapide.
Sources exécutant PostgreSQL 9.5 et versions antérieures : la métrique de délai de réplication n'est pas disponible pour les instances sources exécutant des versions de PostgreSQL antérieures à 9.6. Si vous souhaitez utiliser cette métrique pour suivre la progression de la migration, consultez Activer le délai de réplication.
Installez le package pglogical et configurez les paramètres WAL et de réplication sur votre serveur PostgreSQL :
1. Installez le package pglogical sur le système d'exploitation hôte de votre serveur de base de données. Pour obtenir les packages et les instructions d'installation de votre distribution, consultez le dépôt GitHub pglogical.
2. Connectez-vous à votre instance PostgreSQL à l'aide d'un compte administrateur et définissez les paramètres suivants :
  1. Définissez shared_preload_libraries pour inclure 'pglogical' :
```
ALTER SYSTEM SET shared_preload_libraries = 'pglogical';
```
    Si d'autres bibliothèques sont déjà chargées dans votre instance, ajoutez 'pglogical' à la liste existante d'éléments séparés par une virgule. Pour afficher les bibliothèques existantes, exécutez SHOW shared_preload_libraries;.
  2. Définissez wal_level sur 'logical' :
```
ALTER SYSTEM SET wal_level = 'logical';
```
    Consultez wal_level dans la documentation PostgreSQL.
  3. Définissez wal_sender_timeout sur 0 :
```
ALTER SYSTEM SET wal_sender_timeout = 0;
```
    La valeur 0 désactive le mécanisme de délai avant expiration qui interrompt les connexions de réplication inactives. Consultez wal_sender_timeout.
  4. Définissez max_replication_slots sur au moins le nombre de bases de données à migrer multiplié par le nombre de jobs de migration, plus les réserves pour la synchronisation des tables :
    Par exemple, si l'instance source dispose de cinq bases de données et que vous créez deux jobs de migration pour cette source, le nombre d'emplacements de réplication doit être supérieur ou égal à 5 x 2 = 10, plus le nombre d'emplacements de réplication déjà utilisés sur la source par d'autres tâches. Si vous prévoyez d'utiliser des paramètres de parallélisme de vidage de données ajustés, veillez à augmenter le nombre d'emplacements de réplication et à vérifier votre configuration en exécutant le test du job de migration lorsque vous créez le job de migration.
```
ALTER SYSTEM SET max_replication_slots = MAX_REPLICATION_SLOTS;
```
    La valeur par défaut de ce paramètre est 10. Consultez max_replication_slots.
  5. Définissez max_wal_senders sur une valeur au moins égale à celle de max_replication_slots, en plus du nombre d'expéditeurs déjà utilisés sur votre instance :
    Par exemple, si le paramètre max_replication_slots est défini sur 10 et que vous utilisez déjà deux expéditeurs, le nombre de processus d'envoi WAL exécutés en même temps est de 10 + 2 = 12. Si vous prévoyez d'utiliser des paramètres de parallélisme de vidage de données ajustés, veillez à augmenter le nombre d'expéditeurs et à vérifier votre configuration en exécutant le test du job de migration lorsque vous créez le job de migration.
```
ALTER SYSTEM SET max_wal_senders = MAX_WAL_SENDERS;
```
    La valeur par défaut de ce paramètre est 10. Consultez max_wal_senders.
  6. Définissez max_worker_processes sur un nombre au moins égal à la somme du nombre de bases de données à migrer et du nombre de processus de calcul existants sur votre instance. Si vous prévoyez d'utiliser des paramètres de parallélisme de vidage de données ajustés, tenez compte de deux processus de nœud de calcul supplémentaires par connexion (jusqu'à 20 nœuds de calcul au maximum) :
```
ALTER SYSTEM SET max_worker_processes = MAX_WORKER_PROCESSES;
```
    La valeur par défaut de ce paramètre est 8. Consultez max_worker_processes.
  Vous pouvez également rendre ces modifications persistantes en ajoutant les paramètres directement à votre fichier de configuration postgresql.conf :
```
shared_preload_libraries = 'pglogical'
wal_level = 'logical'
wal_sender_timeout = 0
max_replication_slots = MAX_REPLICATION_SLOTS
max_wal_senders = MAX_WAL_SENDERS
max_worker_processes = MAX_WORKER_PROCESSES
```
Redémarrez votre serveur PostgreSQL pour que les modifications de configuration soient prises en compte.

Configurer une source Amazon RDS pour PostgreSQL

Pour configurer une instance source Amazon RDS pour PostgreSQL pour votre processus de migration, procédez comme suit :

Pour les sources Amazon RDS pour PostgreSQL, Database Migration Service migre toutes les bases de données de votre instance source, à l'exception des bases de données de modèles template0, template1 et de la base de données interne AWS rdsadmin.
Assurez-vous que votre instance source inclut la base de données postgres par défaut. Si cette base de données n'existe pas, créez-la avant de configurer votre migration.
Configurez les règles entrantes du groupe de sécurité VPC Amazon RDS. Autorisez les connexions TCP entrantes sur le port 5432 à partir de l'adresse IP sortante Cloud SQL de destination, de la plage CIDR du VPC ou de la VM hôte bastion SSH inverse.
Vérifiez les extensions PostgreSQL installées sur vos bases de données sources. Database Migration Service ne migre pas les extensions non compatibles avec Cloud SQL. Vérifiez que les objets de votre base de données source et les requêtes d'application ne font pas référence à des extensions non compatibles. Avant de continuer, supprimez les extensions et les références non compatibles de vos bases de données sources.
L'extension pg_cron n'est pas migrée automatiquement par Database Migration Service, mais elle est compatible avec les destinations Cloud SQL pour PostgreSQL. Si vous utilisez pg_cron dans votre base de données source, réinstallez-le et configurez-le sur l'instance de destination après avoir promu la migration.
Créez un compte utilisateur dédié à la migration dans votre instance source et accordez-lui les droits nécessaires :
1. Connectez-vous à l'instance source à l'aide d'un compte administrateur, créez l'utilisateur et accordez le rôle rds_replication géré par AWS :
```
CREATE USER MIGRATION_USER_ACCOUNT_NAME WITH PASSWORD 'PASSWORD';
GRANT rds_replication TO "MIGRATION_USER_ACCOUNT_NAME";
```
2. Accordez au compte utilisateur de migration les autorisations requises pour la base de données postgres par défaut ainsi que pour chaque base de données que vous souhaitez migrer. Exécutez les commandes suivantes sur chaque base de données pour chaque schéma (à l'exception du schéma d'informations et des schémas commençant par pg_) :
```
GRANT USAGE ON SCHEMA SCHEMA_NAME TO "MIGRATION_USER_ACCOUNT_NAME";
GRANT USAGE ON SCHEMA pglogical TO PUBLIC;
GRANT SELECT ON ALL TABLES IN SCHEMA pglogical TO "MIGRATION_USER_ACCOUNT_NAME";
GRANT SELECT ON ALL TABLES IN SCHEMA SCHEMA_NAME TO "MIGRATION_USER_ACCOUNT_NAME";
GRANT SELECT ON ALL SEQUENCES IN SCHEMA SCHEMA_NAME TO "MIGRATION_USER_ACCOUNT_NAME";
```
Installez l'extension pglogical sur chaque base de données que vous souhaitez migrer, à l'exception de template0, template1 et rdsadmin :
- Pour PostgreSQL version 9.4 : exécutez la commande suivante :
```
CREATE EXTENSION IF NOT EXISTS pglogical;
CREATE EXTENSION IF NOT EXISTS pglogical_origin;
```
- Pour PostgreSQL 9.5 et versions ultérieures : exécutez la commande suivante :
```
CREATE EXTENSION IF NOT EXISTS pglogical;
```
Pour en savoir plus sur les exigences, consultez Utiliser des extensions PostgreSQL avec Amazon RDS pour PostgreSQL dans la documentation AWS.

Remarque : L'extension pglogical peut consigner les identifiants de connexion en texte brut dans les journaux de base de données sur l'instance source. Il s'agit d'un comportement connu de l'extension elle-même, qui n'est pas lié à Database Migration Service ni à Cloud SQL.
Vérifiez que vos tables ont des clés primaires. Pour les migrations continues, la réplication logique PostgreSQL nécessite que les tables disposent de clés primaires pour répliquer les opérations UPDATE et DELETE pendant la phase de capture des données modifiées (CDC) :
- Les tables avec une clé primaire répliquent automatiquement toutes les opérations INSERT, UPDATE et DELETE.
- Pour les tables qui ne possèdent pas de clés primaires, Database Migration Service permet de migrer uniquement l'instantané initial ainsi que les instructions INSERT ultérieures pendant la phase de CDC. Vous devez migrer les instructions UPDATE et DELETE manuellement.
  Nous vous recommandons d'ajouter des clés primaires aux tables qui n'en ont pas avant de commencer la migration. Pour savoir comment générer une requête permettant de lister les tables d'une base de données PostgreSQL sans clés primaires, ou comment migrer manuellement les opérations UPDATE et DELETE, consultez Débogage et autres outils.
  
  Vous pouvez également essayer d'utiliser le flux de migration de démarrage rapide : un scénario de migration simplifié dans lequel vous pouvez utiliser REPLICA IDENTITY pour migrer des tables sans clé primaire. Pour en savoir plus, consultez le guide Utiliser les migrations à démarrage rapide.
Sources exécutant PostgreSQL 9.5 et versions antérieures : la métrique de délai de réplication n'est pas disponible pour les instances sources exécutant des versions de PostgreSQL antérieures à 9.6. Si vous souhaitez utiliser cette métrique pour suivre la progression de la migration, consultez Activer le délai de réplication.
Configurez un groupe de paramètres de base de données personnalisé et associez-le à votre instance :
1. Créez un groupe de paramètres personnalisé (consultez Utiliser des groupes de paramètres de base de données dans la documentation AWS) et configurez les paramètres suivants :
  1. Définissez shared_preload_libraries pour inclure pglogical.
  2. Définissez rds.logical_replication sur 1. Ce paramètre active la journalisation WAL logique dans Amazon RDS. Consultez Réplication logique pour Amazon RDS pour PostgreSQL.
  3. Définissez wal_sender_timeout sur 0. La valeur 0 désactive le mécanisme de délai avant expiration qui interrompt les connexions de réplication inactives.
  4. Définissez max_replication_slots sur au moins le nombre de bases de données à migrer multiplié par le nombre de jobs de migration, plus les réserves pour la synchronisation des tables :
    Par exemple, si l'instance source dispose de cinq bases de données et que vous créez deux jobs de migration pour cette source, le nombre d'emplacements de réplication doit être supérieur ou égal à 5 x 2 = 10, plus le nombre d'emplacements de réplication déjà utilisés sur la source par d'autres tâches. Si vous prévoyez d'utiliser des paramètres de parallélisme de vidage de données ajustés, veillez à augmenter le nombre d'emplacements de réplication et à vérifier votre configuration en exécutant le test du job de migration lorsque vous créez le job de migration.
    
    La valeur par défaut de ce paramètre est 10.
  5. Définissez max_wal_senders sur une valeur au moins égale à celle de max_replication_slots, en plus du nombre d'expéditeurs déjà utilisés sur votre instance :
    Par exemple, si le paramètre max_replication_slots est défini sur 10 et que vous utilisez déjà deux expéditeurs, le nombre de processus d'envoi WAL exécutés en même temps est de 10 + 2 = 12. Si vous prévoyez d'utiliser des paramètres de parallélisme de vidage de données ajustés, veillez à augmenter le nombre d'expéditeurs et à vérifier votre configuration en exécutant le test du job de migration lorsque vous créez le job de migration.
    
    La valeur par défaut de ce paramètre est 10.
  6. Définissez max_worker_processes sur un nombre au moins égal à la somme du nombre de bases de données à migrer et du nombre de processus de calcul existants sur votre instance. Si vous prévoyez d'utiliser des paramètres de parallélisme de vidage de données ajustés, tenez compte de deux processus de nœud de calcul supplémentaires par connexion (jusqu'à 20 nœuds de calcul au maximum) :
    La valeur par défaut de ce paramètre est 8.
2. Associez le groupe de paramètres à votre instance de base de données RDS. Si vous créez une instance, vous trouverez cette option sous Configuration supplémentaire. Sinon, modifiez l'instance pour associer le groupe de paramètres.
Redémarrez votre instance Amazon RDS pour que les modifications du groupe de paramètres soient prises en compte.

Configurer une source Amazon Aurora pour PostgreSQL

Pour configurer un cluster source Amazon Aurora PostgreSQL pour votre processus de migration, procédez comme suit :

Pour les sources Amazon Aurora pour PostgreSQL, Database Migration Service migre toutes les bases de données de votre cluster source, à l'exception des bases de données de modèles template0, template1 et de la base de données interne AWS rdsadmin.
Assurez-vous que votre cluster source inclut la base de données postgres par défaut. Si cette base de données n'existe pas, créez-la avant de configurer votre migration.
Configurez les règles entrantes du groupe de sécurité VPC de votre cluster Amazon Aurora. Autorisez les connexions TCP entrantes sur le port 5432 à partir de l'adresse IP sortante Cloud SQL de destination, de la plage CIDR du VPC ou de la VM hôte bastion SSH inverse.
Vérifiez les extensions PostgreSQL installées sur vos bases de données sources. Database Migration Service ne migre pas les extensions non compatibles avec Cloud SQL. Vérifiez que les objets de votre base de données source et les requêtes d'application ne font pas référence à des extensions non compatibles. Avant de continuer, supprimez les extensions et les références non compatibles de vos bases de données sources.
L'extension pg_cron n'est pas migrée automatiquement par Database Migration Service, mais elle est compatible avec les destinations Cloud SQL pour PostgreSQL. Si vous utilisez pg_cron dans votre base de données source, réinstallez-le et configurez-le sur l'instance de destination après avoir promu la migration.
Créez un compte utilisateur dédié à la migration dans votre cluster source et accordez-lui les droits nécessaires :
1. Connectez-vous au cluster source à l'aide d'un compte administrateur, créez l'utilisateur et accordez-lui le rôle rds_replication géré par AWS :
```
CREATE USER MIGRATION_USER_ACCOUNT_NAME WITH PASSWORD 'PASSWORD';
GRANT rds_replication TO "MIGRATION_USER_ACCOUNT_NAME";
```
2. Accordez au compte utilisateur de migration les autorisations requises pour la base de données postgres par défaut ainsi que pour chaque base de données que vous souhaitez migrer. Exécutez les commandes suivantes sur chaque base de données pour chaque schéma (à l'exception du schéma d'informations et des schémas commençant par pg_) :
```
GRANT USAGE ON SCHEMA SCHEMA_NAME TO "MIGRATION_USER_ACCOUNT_NAME";
GRANT USAGE ON SCHEMA pglogical TO PUBLIC;
GRANT SELECT ON ALL TABLES IN SCHEMA pglogical TO "MIGRATION_USER_ACCOUNT_NAME";
GRANT SELECT ON ALL TABLES IN SCHEMA SCHEMA_NAME TO "MIGRATION_USER_ACCOUNT_NAME";
GRANT SELECT ON ALL SEQUENCES IN SCHEMA SCHEMA_NAME TO "MIGRATION_USER_ACCOUNT_NAME";
```
Installez l'extension pglogical sur chaque base de données que vous souhaitez migrer, à l'exception de template0, template1 et rdsadmin :
```
CREATE EXTENSION IF NOT EXISTS pglogical;
```
Remarque : L'extension pglogical peut consigner les identifiants de connexion en texte brut dans les journaux de base de données sur l'instance source. Il s'agit d'un comportement connu de l'extension elle-même, qui n'est pas lié à Database Migration Service ni à Cloud SQL.
Vérifiez que vos tables ont des clés primaires. Pour les migrations continues, la réplication logique PostgreSQL nécessite que les tables disposent de clés primaires pour répliquer les opérations UPDATE et DELETE pendant la phase de capture des données modifiées (CDC) :
- Les tables avec une clé primaire répliquent automatiquement toutes les opérations INSERT, UPDATE et DELETE.
- Pour les tables qui ne possèdent pas de clés primaires, Database Migration Service permet de migrer uniquement l'instantané initial ainsi que les instructions INSERT ultérieures pendant la phase de CDC. Vous devez migrer les instructions UPDATE et DELETE manuellement.
  Nous vous recommandons d'ajouter des clés primaires aux tables qui n'en ont pas avant de commencer la migration. Pour savoir comment générer une requête permettant de lister les tables d'une base de données PostgreSQL sans clés primaires, ou comment migrer manuellement les opérations UPDATE et DELETE, consultez Débogage et autres outils.
  
  Vous pouvez également essayer d'utiliser le flux de migration de démarrage rapide : un scénario de migration simplifié dans lequel vous pouvez utiliser REPLICA IDENTITY pour migrer des tables sans clé primaire. Pour en savoir plus, consultez le guide Utiliser les migrations à démarrage rapide.
Configurez un groupe de paramètres de cluster de bases de données personnalisé et associez-le à votre cluster :
1. Créez un groupe de paramètres de cluster de bases de données personnalisé et configurez les paramètres suivants :
  1. Définissez shared_preload_libraries pour inclure pglogical.
  2. Définissez rds.logical_replication sur 1. Ce paramètre active la journalisation WAL logique.
  3. Définissez wal_sender_timeout sur 0. La valeur 0 désactive le mécanisme de délai avant expiration qui interrompt les connexions de réplication inactives.
  4. Définissez max_replication_slots sur au moins le nombre de bases de données à migrer multiplié par le nombre de jobs de migration, plus les réserves pour la synchronisation des tables :
    Par exemple, si l'instance source dispose de cinq bases de données et que vous créez deux jobs de migration pour cette source, le nombre d'emplacements de réplication doit être supérieur ou égal à 5 x 2 = 10, plus le nombre d'emplacements de réplication déjà utilisés sur la source par d'autres tâches. Si vous prévoyez d'utiliser des paramètres de parallélisme de vidage de données ajustés, veillez à augmenter le nombre d'emplacements de réplication et à vérifier votre configuration en exécutant le test du job de migration lorsque vous créez le job de migration.
    
    La valeur par défaut de ce paramètre est 10.
  5. Définissez max_wal_senders sur une valeur au moins égale à celle de max_replication_slots, en plus du nombre d'expéditeurs déjà utilisés sur votre instance :
    Par exemple, si le paramètre max_replication_slots est défini sur 10 et que vous utilisez déjà deux expéditeurs, le nombre de processus d'envoi WAL exécutés en même temps est de 10 + 2 = 12. Si vous prévoyez d'utiliser des paramètres de parallélisme de vidage de données ajustés, veillez à augmenter le nombre d'expéditeurs et à vérifier votre configuration en exécutant le test du job de migration lorsque vous créez le job de migration.
    
    La valeur par défaut de ce paramètre est 10.
  6. Définissez max_worker_processes sur un nombre au moins égal à la somme du nombre de bases de données à migrer et du nombre de processus de calcul existants sur votre instance. Si vous prévoyez d'utiliser des paramètres de parallélisme de vidage de données ajustés, tenez compte de deux processus de nœud de calcul supplémentaires par connexion (jusqu'à 20 nœuds de calcul au maximum) :
    La valeur par défaut de ce paramètre est 8.
2. Associez le groupe de paramètres du cluster de bases de données au cluster de bases de données Aurora.
Redémarrez votre cluster de bases de données Amazon Aurora pour que les modifications du groupe de paramètres soient prises en compte.

Configurer une source Microsoft Azure Database for PostgreSQL Flexible Server

Pour configurer une instance source Microsoft Azure Database for PostgreSQL Flexible Server pour votre processus de migration, procédez comme suit :

Pour les sources Microsoft Azure Database pour PostgreSQL Flexible Server, Database Migration Service migre toutes les bases de données de votre instance source, à l'exception des bases de données système et de modèles Azure : azure_maintenance, azure_sys, template0 et template1.
Assurez-vous que votre instance source inclut la base de données postgres par défaut. Si cette base de données n'existe pas, créez-la avant de configurer votre migration.
Configurez les paramètres du pare-feu Azure et SSL/TLS :
1. Dans les paramètres réseau Azure, ajoutez des règles de pare-feu autorisant les connexions TCP entrantes sur le port 5432 à partir de l'adresse IP sortante Cloud SQL de destination, de la plage CIDR du VPC ou de la VM bastion SSH inverse.
2. Vérifiez la valeur du paramètre de serveur require_secure_transport. Par défaut, les bases de données Azure exigent le chiffrement SSL/TLS pour les connexions entrantes. En fonction du paramètre require_secure_transport, sélectionnez l'un des paramètres de chiffrement suivants lorsque vous créez le profil de connexion source :
  - Si require_secure_transport est défini sur on, sélectionnez Basic, TLS ou mTLS.
  - Si require_secure_transport est défini sur off, sélectionnez Aucun.
Vérifiez les extensions PostgreSQL installées sur vos bases de données sources. Database Migration Service ne migre pas les extensions non compatibles avec Cloud SQL. Vérifiez que les objets de votre base de données source et les requêtes d'application ne font pas référence à des extensions non compatibles. Avant de continuer, supprimez les extensions et les références non compatibles de vos bases de données sources.
L'extension pg_cron n'est pas migrée automatiquement par Database Migration Service, mais elle est compatible avec les destinations Cloud SQL pour PostgreSQL. Si vous utilisez pg_cron dans votre base de données source, réinstallez-le et configurez-le sur l'instance de destination après avoir promu la migration.
Créez un compte utilisateur dédié à la migration dans votre instance source et accordez-lui les droits nécessaires :
1. Connectez-vous à l'instance source à l'aide d'un compte administrateur, créez l'utilisateur et attribuez-lui le rôle de réplication :
```
CREATE USER MIGRATION_USER_ACCOUNT_NAME WITH PASSWORD 'PASSWORD';
ALTER USER MIGRATION_USER_ACCOUNT_NAME WITH REPLICATION;
```
2. Accordez au compte utilisateur de migration les autorisations requises pour la base de données postgres par défaut ainsi que pour chaque base de données que vous souhaitez migrer. Exécutez les commandes suivantes sur chaque base de données pour chaque schéma (à l'exception du schéma d'informations et des schémas commençant par pg_) :
```
GRANT USAGE ON SCHEMA SCHEMA_NAME TO "MIGRATION_USER_ACCOUNT_NAME";
GRANT USAGE ON SCHEMA pglogical TO PUBLIC;
GRANT SELECT ON ALL TABLES IN SCHEMA pglogical TO "MIGRATION_USER_ACCOUNT_NAME";
GRANT SELECT ON ALL TABLES IN SCHEMA SCHEMA_NAME TO "MIGRATION_USER_ACCOUNT_NAME";
GRANT SELECT ON ALL SEQUENCES IN SCHEMA SCHEMA_NAME TO "MIGRATION_USER_ACCOUNT_NAME";
```
Installez l'extension pglogical sur chaque base de données que vous souhaitez migrer, à l'exception de azure_maintenance, azure_sys, template0 et template1 :
- Pour PostgreSQL version 9.4 : exécutez la commande suivante :
```
CREATE EXTENSION IF NOT EXISTS pglogical;
CREATE EXTENSION IF NOT EXISTS pglogical_origin;
```
- Pour PostgreSQL 9.5 et versions ultérieures : exécutez la commande suivante :
```
CREATE EXTENSION IF NOT EXISTS pglogical;
```
Vérifiez que vos tables ont des clés primaires. Pour les migrations continues, la réplication logique PostgreSQL nécessite que les tables disposent de clés primaires pour répliquer les opérations UPDATE et DELETE pendant la phase de capture des données modifiées (CDC) :
- Les tables avec une clé primaire répliquent automatiquement toutes les opérations INSERT, UPDATE et DELETE.
- Pour les tables qui ne possèdent pas de clés primaires, Database Migration Service permet de migrer uniquement l'instantané initial ainsi que les instructions INSERT ultérieures pendant la phase de CDC. Vous devez migrer les instructions UPDATE et DELETE manuellement.
  Nous vous recommandons d'ajouter des clés primaires aux tables qui n'en ont pas avant de commencer la migration. Pour savoir comment générer une requête permettant de lister les tables d'une base de données PostgreSQL sans clés primaires, ou comment migrer manuellement les opérations UPDATE et DELETE, consultez Débogage et autres outils.
  
  Vous pouvez également essayer d'utiliser le flux de migration de démarrage rapide : un scénario de migration simplifié dans lequel vous pouvez utiliser REPLICA IDENTITY pour migrer des tables sans clé primaire. Pour en savoir plus, consultez le guide Utiliser les migrations à démarrage rapide.
Sources exécutant PostgreSQL 9.5 et versions antérieures : la métrique de délai de réplication n'est pas disponible pour les instances sources exécutant des versions de PostgreSQL antérieures à 9.6. Si vous souhaitez utiliser cette métrique pour suivre la progression de la migration, consultez Activer le délai de réplication.
Configurez les paramètres de serveur suivants dans Azure. Pour en savoir plus, consultez Configurer les paramètres du serveur dans Azure Database pour PostgreSQL.
1. Définissez shared_preload_libraries pour inclure pglogical.
2. Définissez azure.extensions pour inclure pglogical.
3. Définissez wal_level sur logical.
4. Définissez wal_sender_timeout sur 0. La valeur 0 désactive le mécanisme de délai avant expiration qui interrompt les connexions de réplication inactives.
5. Définissez max_replication_slots sur au moins le nombre de bases de données à migrer multiplié par le nombre de jobs de migration, plus les réserves pour la synchronisation des tables :
  Par exemple, si l'instance source dispose de cinq bases de données et que vous créez deux jobs de migration pour cette source, le nombre d'emplacements de réplication doit être supérieur ou égal à 5 x 2 = 10, plus le nombre d'emplacements de réplication déjà utilisés sur la source par d'autres tâches. Si vous prévoyez d'utiliser des paramètres de parallélisme de vidage de données ajustés, veillez à augmenter le nombre d'emplacements de réplication et à vérifier votre configuration en exécutant le test du job de migration lorsque vous créez le job de migration.
  
  La valeur par défaut de ce paramètre est 10.
6. Définissez max_wal_senders sur une valeur au moins égale à celle de max_replication_slots, en plus du nombre d'expéditeurs déjà utilisés sur votre instance :
  Par exemple, si le paramètre max_replication_slots est défini sur 10 et que vous utilisez déjà deux expéditeurs, le nombre de processus d'envoi WAL exécutés en même temps est de 10 + 2 = 12. Si vous prévoyez d'utiliser des paramètres de parallélisme de vidage de données ajustés, veillez à augmenter le nombre d'expéditeurs et à vérifier votre configuration en exécutant le test du job de migration lorsque vous créez le job de migration.
  
  La valeur par défaut de ce paramètre est 10.
7. Définissez max_worker_processes sur un nombre au moins égal à la somme du nombre de bases de données à migrer et du nombre de processus de calcul existants sur votre instance. Si vous prévoyez d'utiliser des paramètres de parallélisme de vidage de données ajustés, tenez compte de deux processus de nœud de calcul supplémentaires par connexion (jusqu'à 20 nœuds de calcul au maximum) :
  La valeur par défaut de ce paramètre est 8.
Pour en savoir plus sur les paramètres, consultez la liste de tous les paramètres de serveur dans Azure Database pour PostgreSQL dans la documentation Microsoft.
Redémarrez votre instance Microsoft Azure Database for PostgreSQL Flexible Server pour que les modifications des paramètres du serveur prennent effet.

Configurer une source Cloud SQL pour PostgreSQL

Pour configurer une instance source Cloud SQL pour PostgreSQL pour votre processus de migration, procédez comme suit :

Pour les sources Cloud SQL pour PostgreSQL, Database Migration Service migre toutes les bases de données de votre instance source, à l'exception des bases de données de modèles template0 et template1.
Assurez-vous que votre instance source inclut la base de données postgres par défaut. Si cette base de données n'existe pas, créez-la avant de configurer votre migration.
Si vous migrez d'une instance source Cloud SQL configurée avec une adresse IP privée vers une instance de destination Cloud SQL qui utilise une plage d'adresses IP non-RFC 1918, ajoutez la plage non-RFC 1918 aux réseaux autorisés de votre instance source. Pour en savoir plus, consultez Configurer des réseaux autorisés.
Vérifiez les extensions PostgreSQL installées sur vos bases de données sources. Database Migration Service ne migre pas les extensions non compatibles avec Cloud SQL. Vérifiez que les objets de votre base de données source et les requêtes d'application ne font pas référence à des extensions non compatibles. Supprimez les extensions et les références non compatibles de vos bases de données sources avant de continuer.
L' extension pg_cron n'est pas migrée automatiquement par Database Migration Service, mais elle est compatible avec les destinations Cloud SQL pour PostgreSQL. Si vous utilisez pg_cron dans votre base de données source, réinstallez-le et configurez-le sur l'instance de destination après avoir promu la migration.
Créez un compte utilisateur dédié à la migration dans votre instance source et accordez-lui les droits nécessaires :
1. Suivez la procédure décrite sur la page Créer un utilisateur de la documentation Cloud SQL.
2. Accordez au compte utilisateur de migration les autorisations requises pour la base de données postgres par défaut ainsi que pour chaque base de données que vous souhaitez migrer. Exécutez les commandes suivantes sur chaque base de données pour chaque schéma (à l'exception du schéma d'informations et des schémas commençant par pg_) :
```
GRANT USAGE ON SCHEMA SCHEMA_NAME TO "MIGRATION_USER_ACCOUNT_NAME";
GRANT USAGE ON SCHEMA pglogical TO PUBLIC;
GRANT SELECT ON ALL TABLES IN SCHEMA pglogical TO "MIGRATION_USER_ACCOUNT_NAME";
GRANT SELECT ON ALL TABLES IN SCHEMA SCHEMA_NAME TO "MIGRATION_USER_ACCOUNT_NAME";
GRANT SELECT ON ALL SEQUENCES IN SCHEMA SCHEMA_NAME TO "MIGRATION_USER_ACCOUNT_NAME";
```
Installez l'extension pglogical sur chaque base de données que vous souhaitez migrer, à l'exception de template0 et template1 :
- Pour PostgreSQL version 9.4 : exécutez la commande suivante :
```
CREATE EXTENSION IF NOT EXISTS pglogical;
CREATE EXTENSION IF NOT EXISTS pglogical_origin;
```
- Pour PostgreSQL 9.5 et versions ultérieures : exécutez la commande suivante :
```
CREATE EXTENSION IF NOT EXISTS pglogical;
```
Vérifiez que vos tables ont des clés primaires. Pour les migrations continues, la réplication logique PostgreSQL nécessite que les tables disposent de clés primaires pour répliquer les opérations UPDATE et DELETE pendant la phase de capture des données modifiées (CDC) :
- Les tables avec une clé primaire répliquent automatiquement toutes les opérations INSERT, UPDATE et DELETE.
- Pour les tables qui ne possèdent pas de clés primaires, Database Migration Service migre l'instantané initial ainsi que les instructions INSERT ultérieures pendant la phase de CDC. Vous devez migrer les instructions UPDATE et DELETE manuellement.
  Nous vous recommandons d'ajouter des clés primaires aux tables qui n'en ont pas avant de commencer la migration. Pour savoir comment générer une requête permettant de lister les tables d'une base de données PostgreSQL sans clés primaires, ou comment migrer manuellement les opérations UPDATE et DELETE, consultez Débogage et autres outils.
  
  Vous pouvez également essayer d'utiliser le flux de migration de démarrage rapide : un scénario de migration simplifié dans lequel vous pouvez utiliser REPLICA IDENTITY pour migrer des tables sans clé primaire. Pour en savoir plus, consultez le guide Utiliser les migrations à démarrage rapide.
Sources exécutant PostgreSQL 9.5 et versions antérieures : la métrique de délai de réplication n'est pas disponible pour les instances sources exécutant des versions de PostgreSQL antérieures à 9.6. Si vous souhaitez utiliser cette métrique pour suivre la progression de la migration, consultez Activer le délai de réplication.
Configurez les indicateurs de base de données suivants sur votre instance source Cloud SQL :
1. Définissez cloudsql.logical_decoding sur on.
2. Définissez cloudsql.enable_pglogical sur on.
3. Définissez wal_sender_timeout sur 0. La valeur 0 désactive le mécanisme de délai avant expiration qui interrompt les connexions de réplication inactives.
4. Définissez max_replication_slots sur au moins le nombre de bases de données à migrer multiplié par le nombre de jobs de migration, plus les réserves pour la synchronisation des tables.
  Par exemple, si l'instance source dispose de cinq bases de données et que vous créez deux jobs de migration pour cette source, le nombre d'emplacements de réplication doit être supérieur ou égal à 5 x 2 = 10, plus le nombre d'emplacements de réplication déjà utilisés sur la source par d'autres tâches. Si vous prévoyez d'utiliser des paramètres de parallélisme de vidage de données ajustés, veillez à augmenter le nombre d'emplacements de réplication et à vérifier votre configuration en exécutant le test du job de migration lorsque vous créez le job de migration.
  
  La valeur par défaut de cette option est 10.
5. Définissez max_wal_senders sur une valeur au moins égale à celle de max_replication_slots, en plus du nombre d'expéditeurs déjà utilisés sur votre instance.
  Par exemple, si l'option max_replication_slots est définie sur 10 et que vous utilisez déjà deux expéditeurs, le nombre de processus d'envoi WAL exécutés en même temps est de 10 + 2 = 12. Si vous prévoyez d'utiliser des paramètres de parallélisme de vidage de données ajustés, veillez à augmenter le nombre d'expéditeurs et à vérifier votre configuration en exécutant le test du job de migration lorsque vous créez le job de migration.
  
  La valeur par défaut de cette option est 10.
6. Définissez max_worker_processes sur un nombre au moins égal à la somme du nombre de bases de données à migrer et du nombre de processus de calcul existants sur votre instance. Si vous prévoyez d'utiliser des paramètres de parallélisme de vidage de données ajustés, tenez compte de deux processus de nœud de calcul supplémentaires par connexion (jusqu'à 20 nœuds de calcul au maximum).
  
  La valeur par défaut de cette option est 8.
Pour en savoir plus sur la modification des options, consultez Configurer des options de base de données dans la documentation Cloud SQL.
Redémarrez votre instance Cloud SQL source pour que les modifications apportées aux indicateurs de base de données soient prises en compte.

Étapes suivantes

Pour obtenir des instructions de migration complètes, consultez Premiers pas avec les migrations Cloud SQL pour PostgreSQL.
Pour planifier la connectivité réseau entre vos instances source et de destination, consultez Présentation de la mise en réseau.