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) d'une base de données PostgreSQL vers une autre.

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 l'instance 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 l'instance de destination. Pour en savoir plus, consultez Modifier un job de migration.

Schéma

  • Nommage des 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 instance de destination pour que vos bases de données restent compatibles. Vous pouvez effectuer les modifications 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, attribuez le rôle cloudsqlexternalsync à l'utilisateur Cloud SQL 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. L'utilisateur 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 PRIMARY KEY, 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. Pour configurer des utilisateurs sur l'instance de destination, utilisez l'onglet Utilisateurs de la console Google Cloud ou gérez-les à l'aide d'un client SQL. Pour en savoir plus, consultez Créer et gérer des utilisateurs dans la documentation Cloud SQL.

  • Extensions non compatibles : Database Migration Service ne migre pas les extensions non compatibles avec Cloud SQL. 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 PostgreSQL dans la documentation Cloud SQL.

  • 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 des vues matérialisées, mais pas les données mises en cache sous-jacentes. Pour renseigner 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 l'instance 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 : Cloud SQL 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 Cloud SQL.

Étapes suivantes