Questions fréquentes sur Database Migration Service pour AlloyDB

MySQL   |  PostgreSQL   |  PostgreSQL vers AlloyDB

• Qu'est-ce que Database Migration Service ?
• Quelles sont les sources compatibles ?
• La compatibilité entre versions est-elle assurée ?
• Quels sont les composants de données, de schéma et de métadonnées migrés ?
• Quelles sont les modifications 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 acceptées ?

• Amazon RDS 9.6.10+, 10.5+, 11.1+, 12, 13, 14, 15, 16, 17
• Amazon Aurora 10.11+, 11.6+, 12.4+, 13.3+, 14, 15, 16, 17
• 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, 16, 17
• Cloud SQL 9.6, 10, 11, 12, 13, 14, 15, 16, 17

Quelles destinations sont acceptées ?

• AlloyDB pour PostgreSQL 14, 15, 16, 17

La compatibilité entre les versions est-elle assurée ?

Database Migration Service permet de migrer PostgreSQL vers AlloyDB à partir de n'importe quelle version de base de données source compatible.

Quels sont les composants de données, de schéma et de métadonnées 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 dans le cadre 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 du schéma

• Dénomination
• Clé primaire
• Type de données
• Position ordinale
• Valeur par défaut
• Nullability
• Attributs à 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 LDD pour 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 :

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

   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]');

Quels éléments ne sont pas migrés ?

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, 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 l'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 AlloyDB peuvent être différents de ceux de la source.SEQUENCE

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

Pour créer une migration dans Database Migration Service, la connectivité doit être établie entre la source et l'instance Cloud SQL de destination. Plusieurs méthodes sont acceptées. Choisissez celui 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 vers 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) qui est connectée à la source. Database Migration Service collecte les informations requises lors de la création de la migration et génère automatiquement le script pour la configurer.	Facile à configurer. Aucune configuration de pare-feu personnalisée n'est requise. Recommandé pour les scénarios de migration de courte durée (migrations de bases de données de petite taille ou de validation de concept).	Vous possédez et gérez la VM bastion. Peut entraîner des coûts supplémentaires.
Proxy TCP via une VM hébergée dans le cloud	Établit la connectivité de la destination à la source via un proxy TCP sur une VM hébergée dans le cloud. Database Migration Service collecte les informations requises lors de la création de la migration et génère automatiquement le script pour la configurer. Concerne les migrations AlloyDB dont la source utilise l'ancienne architecture réseau.	Facile à configurer. Aucune configuration de pare-feu personnalisée n'est requise.	La VM bastion vous appartient et est gérée par vous. 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 Google Cloud native. Facile à configurer. Bande passante élevée Recommandé pour les migrations de longue durée ou à volume élevé.	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 qui connecte le réseau interne et le VPC Google Cloud via une connexion sécurisée sur l'Internet public. Utilisez Google Cloud  VPN ou toute solution VPN configurée pour le réseau interne.	Solution de connectivité robuste et évolutive. Bande passante moyenne à élevée. Sécurité intégrée. Proposé en tant que solutions Google Cloud ou par d'autres tiers.	Des frais supplémentaires s'appliquent. Configuration non triviale (sauf si elle est déjà en place).
Cloud Interconnect	Utilise une connexion à disponibilité élevée et à faible latence 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 à volume élevé.	Des frais supplémentaires s'appliquent. 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 les limitations connues.