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 offre un moyen haute fidélité de 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 à une autre.

Tous les composants de données, de schéma et de métadonnées suivants sont migrés lors 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:

  • 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 la section 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 automatiquement mises à jour lors des migrations continues. La gestion des modifications du langage de définition de données (LDD) pour que les bases de données source et de destination restent compatibles est de la responsabilité de l'utilisateur. Vous pouvez procéder de deux manières différentes:

1. Arrêter les opérations d'écriture sur la source et exécuter les commandes LDD sur la source et la destination. Avant d'exécuter les commandes LDD sur la destination, accordez alloydbexternalsync à l'utilisateur AlloyDB qui applique les modifications LDD. Pour activer l'interrogation et la modification des données, accordez le rôle alloydbexternalsync aux utilisateurs AlloyDB concernés.
2. Utilisation de 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 à la source et à la destination, et doit être le super-utilisateur 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 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] avec le nouveau nom de la table lors de l'opération de renommage

   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

• 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 est oid et qui font référence à de grands objets, les lignes sont synchronisées et les nouvelles lignes sont répliquées. Toutefois, l'accès à 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 le oid donné) é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). Vous devez migrer les instructions UPDATE et DELETE manuellement.

• Database Migration Service ne migre pas les données des vues matérialisées, mais uniquement le schéma de la vue. Pour renseigner 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.