Questions fréquentes sur Database Migration Service pour AlloyDB

MySQL   |  PostgreSQL   |  PostgreSQL vers AlloyDB

• Qu'est-ce que Database Migration Service ?
• Quelles sources sont acceptées ?
• La fonctionnalité est-elle compatible entre les versions ?
• Quels sont les composants de données, de schéma et de métadonnées migrés ?
• Quelles modifications sont répliquées pendant la migration continue ?
• Quels éléments ne sont pas migrés ?
• Quelles méthodes de mise en réseau sont utilisées ?
• Quelles sont les limites connues ?

Qu'est-ce que Database Migration Service ?

Database Migration Service est un service qui vous permet de migrer plus facilement vos données vers Google Cloud. Database Migration Service vous aide à effectuer la migration Lift and Shift de vos charges de travail PostgreSQL vers AlloyDB.

Quelles sources sont compatibles ?

• Amazon RDS 9.6.10+, 10.5+, 11.1+, 12, 13, 14 et 15
• Amazon Aurora 10.11+, 11.6+, 12.4+, 13.3+, 14 et 15
• PostgreSQL autogéré (sur site ou sur une VM cloud que vous contrôlez entièrement) 9.4, 9.5, 9.6, 10, 11, 12, 13, 14, 15
• Cloud SQL 9.6, 10, 11, 12, 13, 14, 15

Quelles destinations sont acceptées ?

• AlloyDB pour PostgreSQL 14, 15, 16

La compatibilité entre les versions est-elle possible ?

Database Migration Service prend en charge les migrations de PostgreSQL vers AlloyDB à partir de n'importe quelle version de base de données source compatible.

Quels composants de données, de schéma et de métadonnées sont migrés ?

Database Migration Service migre le schéma, les données et les métadonnées de la source vers la destination. 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:

Migration des données

• Tous les schémas et toutes les tables de la base de données sélectionnée.

Migration de schéma

• Dénomination
• Clé primaire
• Type de données
• Position ordinale
• Valeur par défaut
• Nullability
• Attributs d'incrémentation automatique
• Index secondaires

Migration des métadonnées

• Procédures stockées
• Fonctions
• Déclencheurs
• Vues
• Contraintes de clé étrangère

Quelles modifications sont répliquées pendant la migration continue ?

Seules les modifications LMD sont automatiquement mises à jour lors de la migration. La gestion 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ê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 le rôle alloydbexternalsync à l'utilisateur Cloud SQL qui applique les modifications apportées au LDD. Pour activer l'interrogation et la modification des données, accordez le rôle alloydbexternalsync aux utilisateurs Cloud SQL concernés.

2. Utilisez pglogical.replicate_ddl_command pour exécuter le 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. Il doit également être super-utilisateur ou 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.

   Pour ajouter une colonne à une table de base de données, exécutez la commande suivante:

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

   Pour modifier le nom d'une table de base de données, exécutez la commande suivante:

   select pglogical.replicate_ddl_command('ALTER TABLE [schema].[table] RENAME TO [table_name]','{default}');

   Pour créer une table de base de données, exécutez les commandes suivantes:

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

Qu'est-ce qui n'est pas migré ?

Pour ajouter des utilisateurs à l'instance de destination AlloyDB, ajoutez-les à partir du client PostgreSQL. Découvrez comment créer et gérer des utilisateurs PostgreSQL.

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 à de grands objets, les lignes sont toujours 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 l'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 AlloyDB peuvent différer des états SEQUENCE de la source.

Quelles méthodes de mise en réseau sont utilisées ?

Pour créer une migration dans Database Migration Service, une connectivité doit être établie entre la source et l'instance de destination Cloud SQL. Plusieurs méthodes sont prises en charge. Choisissez celle qui convient le mieux à la charge de travail spécifique.

Méthode de mise en réseau	Description	Avantages	Inconvénients
Tunnel SSH inversé via une VM hébergée dans le cloud	Établit la connectivité de la destination à la source via un tunnel SSH inversé sécurisé. Nécessite une VM hôte bastion dans le projet Google Cloud et une machine (par exemple, un ordinateur portable sur le réseau) connectée à la source. Database Migration Service collecte les informations requises au moment de la création de la migration et génère automatiquement le script de configuration.	Facile à configurer. Aucune configuration personnalisée du pare-feu n'est requise. Recommandé pour les scénarios de migration de courte durée (POC ou migrations de petites bases de données).	Vous possédez et gérez la VM bastion. Des coûts supplémentaires peuvent s'appliquer.
Proxy TCP via une VM hébergée dans le cloud	Établit une connectivité entre la destination et la source via un proxy TCP via une VM hébergée dans le cloud. Database Migration Service collecte les informations requises au moment de la création de la migration et génère automatiquement le script de configuration. Pertinent pour les migrations AlloyDB où la source se trouve sur l'ancienne architecture réseau.	Facile à configurer. Aucune configuration personnalisée du pare-feu n'est requise.	La VM Bastion vous appartient et vous la gérez. Elle peut entraîner des coûts supplémentaires.
Appairage de VPC	Cette méthode consiste à configurer les VPC pour qu'ils communiquent entre eux.	Solution native Google Cloud Facile à configurer. Haute bande passante Recommandé pour les migrations de longue durée ou à fort volume.	Ne s'applique que si les bases de données source et de destination sont hébergées dans Google Cloud.
VPN	Configure un tunnel VPN IPsec reliant le réseau interne et le VPC Google Cloud via une connexion sécurisée sur Internet public. Utilisez le VPN Google Cloud ou toute solution VPN configurée pour le réseau interne.	Une solution de connectivité robuste et évolutive Bande passante moyenne à élevée. Sécurité intégrée. Disponibles en tant que solutions Google Cloud ou d'autres tiers.	Frais supplémentaires. Configuration non triviale (sauf si elle est déjà en place).
Cloud Interconnect	Utilise une connexion à faible latence et disponibilité élevée entre le réseau sur site et Google Cloud.	Bande passante la plus élevée, idéale pour les migrations de longue durée et à fort volume.	Frais supplémentaires. La connexion n'est pas sécurisée par défaut. Configuration non triviale (sauf si elle est déjà en place).

Quelles sont les limites connues ?

Consultez la section Limitations connues.