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 lors de la migration continue ?
• Qu'est-ce qui n'est pas migré ?
• 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 facilite la migration de vos données vers Google Cloud. Database Migration Service vous aide à transférer vos charges de travail PostgreSQL vers AlloyDB.

Quelles sont les sources compatibles ?

• 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 et 17
• Cloud SQL 9.6, 10, 11, 12, 13, 14, 15, 16, 17

Quelles sont les destinations compatibles ?

• AlloyDB pour PostgreSQL 14, 15, 16, 17, 18

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

Database Migration Service permet de migrer de 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 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 sont les modifications répliquées lors de la migration continue ?

Seules les modifications LMD sont automatiquement mises à jour lors de la migration. L'utilisateur est responsable de la gestion du LDD pour que les bases de données source et de destination restent compatibles. 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 LDD. Pour activer l'interrogation et la modification des données, accordez le alloydbexternalsync rôle aux utilisateurs Cloud SQL concernés.

2. Utilisez le pglogical.replicate_ddl_command pour exécuter le LDD sur la source et la destination en un point cohérent point. 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.

   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 à des objets volumineux, les lignes sont toujours synchronisées et les nouvelles lignes sont répliquées. Toutefois, toute tentative d'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 ainsi que 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 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, vous devez établir une connectivité entre la source et l'instance de destination Cloud SQL. Plusieurs méthodes sont compatibles. 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 Google Cloud projet et une machine (par exemple, un ordinateur portable sur le réseau) 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 de configuration.	Facile à configurer. Ne nécessite aucune configuration personnalisée du pare-feu. Recommandé pour les scénarios de migration de courte durée (preuve de concept ou migrations de petites bases de données).	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 via 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 de configuration. Pertinent pour les migrations AlloyDB où la source utilise l'ancienne architecture réseau.	Facile à configurer. Ne nécessite aucune configuration personnalisée du pare-feu.	Vous possédez et gérez la VM bastion, ce qui 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é.	Applicable uniquement 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 Google Cloud le VPC 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é commes Google Cloud solutions ou par d'autres tiers.	Coût supplémentaire. 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 à volume élevé.	Coût supplémentaire. 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.