Fidélité des migrations

Lorsque vous migrez un schéma, des données et des métadonnées d'une base de données source vers une base de données de destination, vous devez vous assurer que toutes les informations sont migrées avec précision. Database Migration Service fournit un mécanisme extrêmement fiable pour migrer des objets de base de données (y compris le schéma, les données et les métadonnées) de PostgreSQL vers AlloyDB pour PostgreSQL.

Au cours du processus de migration, les données et les contraintes sont migrées par phases structurées. Les données sont d'abord migrées lors du chargement de l'instantané initial, et les contraintes telles que les clés primaires, les clés étrangères et les index sont recréées sur le cluster de destination une fois le chargement initial terminé.

Les composants de données, de schéma et de métadonnées suivants sont migrés dans le cadre de la migration de la base de données :

Données

  • Toutes les tables et tous les schémas des bases de données sélectionnées pour la migration, à l'exception des schémas système suivants :

    • Le schéma d'informations (information_schema)
    • Tous les schémas commençant par pg_ (par exemple, pg_catalog, pg_toast)

    Pour en savoir plus sur ces schémas système, consultez Limites connues.

    Vous pouvez ajouter ou supprimer des bases de données d'un job de migration pendant une migration en cours. La suppression d'une base de données arrête la réplication pour cette base de données sans supprimer la base de données déjà migrée sur le cluster de destination. Pour en savoir plus, consultez Modifier un job de migration.

Schéma

  • Nommer les objets

  • Clés primaires

  • Types de données

  • Positions ordinales des colonnes

  • Valeurs par défaut

  • Nullability

  • Attributs d'identité et de série

  • Index secondaires

Métadonnées

  • Procédures stockées

  • Fonctions

  • Déclencheurs

  • Vues

  • Contraintes de clé étrangère

Migration continue

Les modifications du langage de manipulation de données (LMD) (telles que les opérations INSERT, UPDATE et DELETE sur les tables avec une clé primaire ou une identité d'instance dupliquée) sont automatiquement répliquées lors des migrations continues.

Si des modifications du langage de définition de données (LDD) sont apportées à votre base de données source pendant le processus de migration, vous devez mettre à jour votre cluster de destination afin que vos bases de données restent compatibles. Vous pouvez effectuer les modifications de LDD de l'une des manières suivantes :

  1. Exécution manuelle du LDD : arrêtez les écritures dans la base de données source, exécutez les commandes LDD sur la base de données source, puis exécutez les commandes LDD correspondantes sur la base de données de destination. Avant d'exécuter des commandes LDD sur la destination, accordez le rôle alloydbexternalsync à l'utilisateur AlloyDB pour PostgreSQL qui applique les modifications.

  2. Commandes LDD répliquées avec pglogical : vous pouvez utiliser pglogical.replicate_ddl_command pour exécuter des commandes LDD sur les bases de données source et de destination à un point cohérent du flux de réplication. Le compte qui exécute cette commande doit disposer d'identifiants correspondants sur les instances source et de destination, et doit être un super-utilisateur ou le propriétaire de l'objet modifié.

Les onglets suivants fournissent des exemples de commandes SQL pour les opérations LDD courantes à l'aide de pglogical.replicate_ddl_command :

Tables avec clés primaires

Ajouter une colonne à une table avec une clé primaire

SELECT pglogical.replicate_ddl_command(
  'ALTER TABLE [SCHEMA].[TABLE_NAME] ADD COLUMN surname varchar(20)',
  '{default}'
);

Modifier le nom d'une table avec une clé primaire

SELECT pglogical.replicate_ddl_command(
  'ALTER TABLE [SCHEMA].[TABLE_NAME] RENAME TO [NEW_NAME_FOR_TABLE]',
  '{default}'
);

Créer une table avec une clé primaire

Exécutez les commandes suivantes sur la base de données source :

SELECT pglogical.replicate_ddl_command(
  command := 'CREATE TABLE [SCHEMA].[TABLE_NAME] (id INTEGER PRIMARY KEY, name VARCHAR);',
  replication_sets := ARRAY['default']
);
SELECT pglogical.replication_set_add_table('default', '[SCHEMA].[TABLE_NAME]');

Tables sans clé primaire

Ajouter une colonne à une table sans clé primaire

SELECT pglogical.replicate_ddl_command(
  'ALTER TABLE [SCHEMA].[TABLE_NAME] ADD COLUMN surname varchar(20)',
  '{default_insert_only}'
);

Modifier le nom d'une table sans clé primaire

SELECT pglogical.replicate_ddl_command(
  'ALTER TABLE [SCHEMA].[TABLE_NAME] RENAME TO [NEW_NAME_FOR_TABLE]',
  '{default_insert_only}'
);

Créer une table sans clé primaire

Exécutez les commandes suivantes sur la base de données source :

SELECT pglogical.replicate_ddl_command(
  command := 'CREATE TABLE [SCHEMA].[TABLE_NAME] (id INTEGER, name VARCHAR);',
  replication_sets := ARRAY['default_insert_only']
);
SELECT pglogical.replication_set_add_table('default_insert_only', '[SCHEMA].[TABLE_NAME]');

Éléments non migrés

  • Utilisateurs et droits : les identifiants de connexion et les rôles des utilisateurs ne sont pas migrés. La première fois que vous vous connectez à un nouveau cluster de destination, utilisez le compte postgres. Comme il s'agit d'un service géré, AlloyDB pour PostgreSQL n'autorise pas les utilisateurs PostgreSQL à disposer de droits SUPERUSER. Pour en savoir plus, consultez Gérer les utilisateurs de base de données dans la documentation d'AlloyDB pour PostgreSQL.

  • Extensions non compatibles : Database Migration Service ne migre pas les extensions non compatibles avec AlloyDB pour PostgreSQL. La présence de ces extensions ne bloque pas le job de migration, mais les applications qui font référence à des extensions non compatibles peuvent rencontrer des erreurs. Pour obtenir la liste des extensions compatibles, consultez Extensions de base de données compatibles dans la documentation AlloyDB pour PostgreSQL.

  • Objets volumineux : les objets volumineux PostgreSQL (type de données oid faisant référence à pg_largeobject) ne sont pas répliqués par le décodage logique.

  • Tables sans clé primaire : Database Migration Service migre l'instantané initial et réplique les instructions INSERT pendant la phase de CDC. Pour les instructions UPDATE et DELETE :

    • Migrations standards : les migrations standards nécessitent que vos tables disposent de clés primaires pour répliquer les instructions UPDATE et DELETE.

    • Migrations à démarrage rapide : avec les migrations à démarrage rapide, les clés primaires ne sont pas requises pour répliquer les opérations UPDATE et DELETE si vous définissez l'identité de l'instance répliquée sur INDEX ou FULL. La configuration de REPLICA IDENTITY FULL augmente le volume du journal WAL (Write-Ahead Logging) et la surcharge des ressources. Nous vous recommandons d'ajouter une clé primaire dans la mesure du possible. Pour en savoir plus, consultez la documentation sur l'identité de l'instance répliquée PostgreSQL et le guide de démarrage rapide des migrations.

  • Vues matérialisées : Database Migration Service migre les définitions de vues matérialisées, mais pas les données mises en cache sous-jacentes. Pour remplir les vues matérialisées sur la destination, exécutez REFRESH MATERIALIZED VIEW view_name après la migration.

  • États des séquences : les valeurs actuelles des séquences (telles que last_value) sur le cluster de destination peuvent différer de la source pendant la CDC en cours. Les valeurs de séquence sont synchronisées lors de l'étape de promotion finale.

  • Espaces de table personnalisés : AlloyDB pour PostgreSQL n'est pas compatible avec les espaces de table personnalisés. Les objets définis dans des espaces de table personnalisés sont automatiquement remappés vers l'espace de table pg_default par défaut dans AlloyDB pour PostgreSQL.

Étapes suivantes