Cette page a été traduite par l'API Cloud Translation.

Configurer votre source

MySQL | PostgreSQL | PostgreSQL vers AlloyDB

Présentation

Database Migration Service permet d'effectuer des migrations continues à partir de bases de données sources vers des bases de données de destination AlloyDB.

Les bases de données sources compatibles avec PostgreSQL incluent :

Amazon RDS 9.6.10+, 10.5+, 11.1+, 12, 13, 14 et 15
Amazon Aurora 10.11+, 11.6+, 12.4+, 13.3+, 14 et 15
PostgreSQL autogéré (sur site ou sur une VM cloud que vous contrôlez entièrement) 9.4, 9.5, 9.6, 10, 11, 12, 13, 14, 15
Cloud SQL 9.6, 10, 11, 12, 13, 14, 15

Pour configurer votre source, vous devez configurer à la fois l'instance source et les bases de données sources sous-jacentes.

Configurer l'instance source

Pour configurer votre instance source, procédez comme suit:

Votre instance source doit inclure la base de données postgres. Si vous ne possédez pas cette base de données, créez-la.
Installez le package pglogical sur l'instance source et assurez-vous qu'il est inclus dans la variable shared_preload_libraries.
1. Pour votre environnement, consultez Installer le package pglogical sur l'instance source.

Configurer vos bases de données sources

Database Migration Service migre toutes les bases de données de votre instance source autres que les bases de données suivantes:

Pour les sources sur site: bases de données de modèles template0 et template1
Pour les sources Amazon RDS: template0, template1 et rdsadmin
Pour les sources Cloud SQL: bases de données de modèles template0 et template1

Procédez comme suit sur chaque base de données de votre instance source non mentionnée ci-dessus:

Pour les sources PostgreSQL version 9.4 uniquement, installez les extensions pglogical suivantes sur chaque base de données de votre instance source:
- CREATE EXTENSION IF NOT EXISTS pglogical;
- CREATE EXTENSION IF NOT EXISTS pglogical_origin;
Pour toutes les autres versions, n'installez que l'extension pglogical sur chaque base de données de votre instance source: CREATE EXTENSION IF NOT EXISTS pglogical.
Pour les tables qui ne possèdent pas de clés primaires, Database Migration Service permet de migrer l'instantané initial et les instructions INSERT pendant la phase de CDC. Vous devez migrer les instructions UPDATE et DELETE manuellement.

Consultez la section Débogage et autres outils pour savoir comment générer une requête permettant de répertorier les tables dans une base de données PostgreSQL sans clés primaires. Pour chaque table de base de données sans clé primaire et devant être migrée, vous devez modifier la table de sorte qu'elle contienne une clé primaire ou suivre ce processus. Pour les tables sans clés primaires, seuls l'instantané initial et les instructions INSERT sont migrés.
L'USER que vous utilisez pour vous connecter à l'instance source (qui sera configuré en tant qu'utilisateur sur la page Profils de connexion) doit disposer de certains droits sur chacune des bases de données migrées, ainsi que sur la base de données postgres par défaut. Vous pouvez créer un utilisateur ou réutiliser un utilisateur existant. Pour définir ces droits, connectez-vous à l'instance et exécutez les commandes suivantes :
1. GRANT USAGE on SCHEMA SCHEMA to USER sur tous les schémas (à l'exception du schéma d'informations et des schémas commençant par "pg_") sur chaque base de données à migrer.
2. GRANT USAGE on SCHEMA pglogical to PUBLIC; sur chaque base de données à migrer.
3. GRANT SELECT on ALL TABLES in SCHEMA pglogical to USER sur toutes les bases de données afin d'obtenir des informations de réplication à partir des bases de données sources.
4. GRANT SELECT on ALL TABLES in SCHEMA SCHEMA to USER sur tous les schémas (à l'exception du schéma d'informations et des schémas commençant par "pg_") sur chaque base de données à migrer.
5. GRANT SELECT on ALL SEQUENCES in SCHEMA SCHEMA to USER sur tous les schémas (à l'exception du schéma d'informations et des schémas commençant par "pg_") sur chaque base de données à migrer.
6. Si votre source est Amazon RDS, exécutez la commande suivante :
  1. GRANT rds_replication to USER
7. Si votre source n'est pas Amazon RDS, exécutez la commande suivante :
  1. Rôle ALTER USER USER with REPLICATION

Installer le package `pglogical` sur l'instance source

Cette section explique comment configurer le package pglogical, y compris la configuration des paramètres max_replication_slots, max_wal_senders et max_worker_processes. Vous pouvez également obtenir les valeurs correctes pour ces paramètres en exécutant un test de tâche de migration lorsque vous créez la tâche de migration. Au cours de ce test, Database Migration Service peut vérifier vos paramètres et suggérer les valeurs appropriées.

PostgreSQL sur site ou autogéré

Installez le package pglogical sur le serveur.
Connectez-vous à l'instance et définissez les paramètres suivants, si nécessaire :
- shared_preload_libraries doit inclure pglogical.
  Pour définir ce paramètre, exécutez la commande ALTER SYSTEM SET shared_preload_libraries = 'pglogical,[any other libraries in your instance]';.
  
  Pour obtenir les bibliothèques existantes de votre instance, exécutez la commande show shared_preload_libraries.
- Définissez wal_level sur logical.
  Pour définir ce paramètre, exécutez la commande ALTER SYSTEM SET wal_level = 'logical';.
- Définissez wal_sender_timeout sur 0.
  
  Pour définir ce paramètre, exécutez la commande ALTER SYSTEM SET wal_sender_timeout = 0;, où 0 désactive le mécanisme de délai avant expiration utilisé pour interrompre les connexions de réplication inactives.
- max_replication_slots définit le nombre maximal d'emplacements de réplication que l'instance source peut accepter. Il doit être défini sur au moins le nombre d'abonnements attendus, plus certaines réserves pour la synchronisation des tables.
  
  Database Migration Service nécessite un emplacement pour chaque base de données migrée (soit toutes les bases de données de l'instance source).
  
  Par exemple, si l'instance source dispose de cinq bases de données et que deux tâches de migration sont créées pour cette source, le nombre d'emplacements de réplication doit être supérieur ou égal à 5 x 2 = 10, en plus du nombre d'emplacements de réplication que vous utilisez déjà. 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.
  
  Pour définir ce paramètre, exécutez la commande ALTER SYSTEM SET max_replication_slots = #;, où # représente le nombre maximal d'emplacements de réplication.
- Vous devez définir max_wal_senders sur une valeur au moins égale à celle de max_replication_slots, plus le 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 de la tâche de migration lorsque vous créez la tâche de migration.
  Pour définir ce paramètre, exécutez la commande ALTER SYSTEM SET max_wal_senders = #;, où # représente le nombre de processus d'envoi WAL exécutés simultanément.
- max_worker_processes doit être défini sur une valeur au moins égale au nombre de bases de données que Database Migration Service va migrer (soit toutes les bases de données de l'instance source), plus le nombre de max_worker_processes déjà utilisés sur votre instance.
  
  Si vous prévoyez d'utiliser des paramètres de parallélisme de vidage de données ajustés, veillez à augmenter le nombre de processus de travail et à vérifier votre configuration en exécutant le test de la tâche de migration lorsque vous créez la tâche de migration.
  
  Pour définir ce paramètre, exécutez la commande ALTER SYSTEM SET max_worker_processes = #;, où # représente le nombre de bases de données à migrer.
Les paramètres que vous définissez à cette étape s'appliquent à un serveur de base de données PostgreSQL en cours d'exécution. Vous pouvez également rendre ces modifications persistantes en ajoutant les lignes de code suivantes au fichier postgresql.conf:
- shared_preload_libraries = 'pglogical';
- wal_level = 'logical';
- wal_sender_timeout = 0;
- max_replication_slots = #;
- max_wal_senders = #;
- max_worker_processes = #;
Pour appliquer les modifications de configuration, redémarrez l'instance source.

Amazon RDS PostgreSQL

Installez l'extension pglogical sur votre base de données source. Pour en savoir plus, consultez la section Utiliser des extensions PostgreSQL avec Amazon RDS pour PostgreSQL dans la documentation Amazon RDS.
Configurez l'instance source à l'aide de groupes de paramètres.
- Créez un groupe de paramètres. Dans le groupe de paramètres:
Associez le groupe de paramètres à l'instance. Si vous créez une instance, vous trouverez cette option sous Configuration supplémentaire. Sinon, modifiez l'instance pour joindre le groupe de paramètres.
Pour appliquer les modifications de configuration, redémarrez l'instance source.

Remarque: L'extension pglogical peut consigner les identifiants en texte brut sur l'instance source. Ce comportement est dû à l'extension elle-même et n'est pas lié à Database Migration Service ni à Cloud SQL.

Cloud SQL pour PostgreSQL

Activez la réplication logique et le décodage pour la base de données source en configurant les options suivantes.

Définissez les indicateurs cloudsql.logical_decoding et cloudsql.enable_pglogical sur on.
Définissez l'indicateur max_replication_slots. Cet indicateur définit le nombre maximal d'emplacements de réplication que l'instance source peut accepter. Il doit être défini sur au moins le nombre d'abonnements attendus, plus certaines réserves pour la synchronisation des tables.

Database Migration Service nécessite un emplacement pour chaque base de données migrée (soit toutes les bases de données de l'instance source).

Par exemple, si l'instance source dispose de cinq bases de données et que deux tâches de migration sont créées pour cette source, le nombre d'emplacements de réplication doit être supérieur ou égal à 5 x 2 = 10, en plus du nombre d'emplacements de réplication que vous utilisez déjà. 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 cet indicateur est 10.
Définissez l'indicateur 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'indicateur 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 de la tâche de migration lorsque vous créez la tâche de migration.

La valeur par défaut de cet indicateur est 10.
Définissez l'indicateur source max_worker_processes sur un nombre au moins égal au nombre de bases de données que Database Migration Service va migrer (soit toutes les bases de données de l'instance source), plus le nombre de max_worker_processes déjà utilisés sur votre instance. Si vous prévoyez d'utiliser des paramètres de parallélisme de vidage de données ajustés, prévoyez deux processus de nœuds de calcul supplémentaires par connexion (jusqu'à 20 nœuds de calcul maximum).

La valeur par défaut de cet indicateur est 8.
Redémarrez votre instance source pour que les modifications de configuration apportées aux options soient prises en compte.

Activer la surveillance du délai de réplication pour les versions PostgreSQL antérieures à 9.6

Si vous effectuez une migration depuis une version PostgreSQL antérieure à 9.6, la métrique de délai de réplication n'est pas disponible par défaut. Vous disposez de trois options pour activer le suivi de cette métrique afin de minimiser le temps d'arrêt lorsque vous promouvez la base de données:

Option 1: Activez Database Migration Service pour suivre le délai de réplication en accordant l'accès à une requête spécifique. À l'aide d'un utilisateur disposant du droit SUPERUSER, procédez comme suit:

Définissez la fonction suivante pour permettre au service de migration de base de données d'interroger le délai de réplication.

CREATE OR REPLACE FUNCTION pg_stat_replication_user()
RETURNS TABLE (
pid               integer                  ,
usesysid          oid                      ,
username          name                    ,
application_name  text                     ,
client_addr       inet                     ,
client_hostname   text                     ,
client_port       integer                  ,
backend_start     timestamp with time zone ,
backend_xmin      xid                      ,
state             text                     ,
sent_location     pg_lsn                   ,
write_location    pg_lsn                   ,
flush_location    pg_lsn                   ,
replay_location   pg_lsn                   ,
sync_priority     integer                  ,
sync_state        text
)
LANGUAGE SQL
SECURITY DEFINER
AS $$
 SELECT *
 FROM pg_catalog.pg_stat_replication;
$$;

Accordez l'autorisation EXECUTE à USER en exécutant les commandes suivantes:
1. REVOKE EXECUTE ON FUNCTION pg_stat_replication_user() FROM public;
2. GRANT EXECUTE ON FUNCTION pg_stat_replication_user() to {replication_user};

Option 2: accordez le privilège SUPERUSER directement à l'USER utilisé pour se connecter à l'instance source. Cela permettra à Database Migration Service de lire directement le délai de réplication.

Option 3: Suivez le délai de réplication indépendamment à l'aide de la requête suivante:

Pour les versions de PostgreSQL antérieures à la version 10, exécutez cette commande en tant que superuser.

    SELECT current_timestamp, application_name,
    pg_xlog_location_diff(pg_current_xlog_location(), pg_stat_replication.sent_location) AS sent_location_lag,
    pg_xlog_location_diff(pg_current_xlog_location(), pg_stat_replication.write_location) AS write_location_lag,
    pg_xlog_location_diff(pg_current_xlog_location(), pg_stat_replication.flush_location) AS flush_location_lag,
    pg_xlog_location_diff(pg_current_xlog_location(), pg_stat_replication.replay_location) AS replay_location_lag
    FROM pg_stat_replication
    WHERE application_name like 'cloudsql%';

Dans cette option, Database Migration Service ne reflète pas la métrique de délai de réplication dans les graphiques ou les réponses de l'API.

Se lancer

Créer un profil de connexion source