Fidélité des migrations

MySQL   |  PostgreSQL   |  PostgreSQL vers AlloyDB

Présentation

Lorsque vous migrez votre schéma, vos données et vos métadonnées d'une base de données source vers une base de données de destination, vous devez vous assurer que toutes ces informations sont migrées avec précision. Database Migration Service permet de migrer de manière extrêmement fiable les objets d'une base de données (y compris le schéma, les données et les métadonnées) d'une base de données à une autre.

Au cours du processus de migration, les données et les contraintes sont migrées séparément. Les données sont migrées en premier, et les contraintes telles que les clés primaires, les clés étrangères et les index sont recréées sur l'instance après la vidange et le chargement complets initiaux.

Tous 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 de toutes les bases de données et de tous les schémas, à l'exception des schémas suivants :

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

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

Schéma

• Dénomination

• Clé primaire

• Type de données

• Position ordinale

• Valeur par défaut

• Nullability

• Attributs d'incrémentation automatique

• Index secondaires

Métadonnées

• Procédures stockées

• Fonctions

• Déclencheurs

• Vues

• Contraintes de clé étrangère

Migration continue

Seules les modifications du langage de manipulation de données (LMD) sont mises à jour automatiquement lors des migrations continues. La gestion des modifications du langage de définition de données (LDD) afin que les bases de données source et de destination restent compatibles est la responsabilité de l'utilisateur. Vous pouvez procéder de deux manières différentes :

1. Arrêter les écritures dans la source et exécuter les commandes LDD dans la source et la destination. Avant d'exécuter les commandes LDD sur la destination, accordez cloudsqlexternalsync à l'utilisateur Cloud SQL qui applique les modifications LDD. Pour activer l'interrogation et la modification des données, accordez le cloudsqlexternalsync rôle aux utilisateurs Cloud SQL concernés.
2. Utiliser le pglogical.replicate_ddl_command pour autoriser l'exécution du LDD sur la source et la destination en un point cohérent. L'utilisateur qui exécute cette commande doit avoir le même nom d'utilisateur sur la source et la destination, et doit être le superutilisateur ou le propriétaire de l'artefact migré (par exemple, la table, la séquence, la vue ou la base de données).

   Voici quelques exemples d'utilisation de la commande pglogical.replicate_ddl_command.

   Remplacez :

   • [SCHEMA] par le nom du schéma de table que vous souhaitez utiliser
   • [TABLE_NAME] par le nom de la table
   • [NEW_NAME_FOR_TABLE] par le nouveau nom de la table lors de l'opération de changement de nom

   Ajouter une colonne à une table de base de données avec une clé primaire

   select pglogical.replicate_ddl_command(
     'ALTER TABLE [SCHEMA].[TABLE_NAME] add column surname varchar(20)',
     '{default}'
   );

   Ajouter une colonne à une table de base de données 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 de base de données avec une clé primaire

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

   Modifier le nom d'une table de base de données 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 de base de données avec une clé primaire

   Exécutez les commandes suivantes :

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

   2. select pglogical.replication_set_add_table('default', '[SCHEMA].[TABLE_NAME]');

   Créer une table de base de données sans clé primaire

   Exécutez les commandes suivantes :

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

   2. select pglogical.replication_set_add_table(
        'default_insert_only', '[SCHEMA].[TABLE_NAME]'
      );

Éléments non migrés

• Pour ajouter des utilisateurs à une instance de destination Cloud SQL, accédez à l'instance et ajoutez des utilisateurs depuis l'onglet Utilisateurs ou à partir d'un client PostgreSQL. En savoir plus sur la création et la gestion d'utilisateurs PostgreSQL.

• Database Migration Service ne migre pas les extensions non compatibles avec Cloud SQL. La présence de ces extensions ne bloque pas la migration, mais pour garantir un processus de migration fluide, vérifiez que vos objets ou applications ne font référence à aucune extension non compatible. Nous vous recommandons de supprimer ces extensions et références de votre base de données source avant de continuer.

• Les objets volumineux ne peuvent pas être répliqués, car la fonctionnalité de décodage logique de PostgreSQL n'est pas compatible avec le décodage des modifications apportées aux objets volumineux. Pour les tables dont le type de colonne oid fait référence à des objets volumineux, les lignes sont synchronisées et les nouvelles lignes sont répliquées. Toutefois, lorsque vous essayez d'accéder à l'objet volumineux dans la base de données de destination (lecture à l'aide de lo_get, exportation à l'aide de lo_export, ou vérification du catalogue pg_largeobject pour l' oid donné), l'opération échoue et un message indique que l'objet volumineux n' existe pas.

• 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 capture des données modifiées (CDC, Change Data Capture). Vous devez migrer manuellement les instructions UPDATE et DELETE.

• Database Migration Service ne migre pas les données des vues matérialisées, mais uniquement le schéma de la vue. Pour remplir les vues, exécutez la commande suivante : REFRESH MATERIALIZED VIEW view_name.

• Les états SEQUENCE (par exemple, last_value) de la nouvelle destination peuvent différer des états SEQUENCE de la source.

• Les espaces de table personnalisés ne sont pas compatibles avec l'instance Cloud SQL de destination. Toutes les données des espaces de table personnalisés sont migrées vers l'espace de table pg_default par défaut dans Cloud SQL.