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

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 :

  • 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 à 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 incombe à l'utilisateur. Vous pouvez procéder de deux manières :

1. Arrêtez les opérations d'écriture sur la source, puis exécutez 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. Utilisez 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 dans la source et la destination. Il doit également ê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 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}'
   );

   Renommer 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 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 au grand objet 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é), l'opération échoue et un message indique que le grand objet 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 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 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 être différents de ceux de la source.SEQUENCE

• 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.