Flux de migration

Pour les migrations MySQL homogènes vers Cloud SQL, Database Migration Service se connecte à l'instance Cloud SQL de destination , puis gère le processus de migration en son nom. C'est l'instance de destination qui établit la connexion à votre instance source, mais c'est Database Migration Service qui supervise le processus.

Présentation du processus de migration MySQL
Figure 1. Déplacement des données lors des migrations de Database Migration Service pour MySQL. (cliquez pour agrandir)
Présentation du processus de migration MySQL

Pour les migrations MySQL homogènes vers Cloud SQL, Database Migration Service est compatible avec les flux de migration continus et ponctuels. Avec les migrations continues, vos données sont d'abord chargées à partir d'un vidage complet, puis mises à jour en continu en fonction des informations sur les modifications de données extraites des fichiers journaux de la base de données. De manière générale, les phases de migration se déroulent comme suit :

Migrations ponctuelles

  1. Lorsque vous créez le job de migration, Database Migration Service crée une instance d'orchestration temporaire pour gérer la réplication et transforme votre instance Cloud SQL de destination en réplica Cloud SQL. Aucun coût supplémentaire n'est associé à cette instance d'orchestration.

    Vue de l'instance de destination rétrogradée dans la console Cloud SQL. L'image montre comment l'instance de destination est gérée par l'instance d'orchestration temporaire.
    Figure 2. Instance de destination affichée sous l'instance d'orchestration temporaire dans la Google Cloud console.
    Vue de l'instance de destination rétrogradée dans la console Cloud SQL. L'image montre comment l'instance de destination est gérée par l'instance d'orchestration temporaire.

  2. Lorsque vous démarrez le job de migration, Database Migration Service lance la phase de vidage complet. Pour les migrations ponctuelles, il s'agit de la seule phase de migration.

    Lors du vidage complet, Database Migration Service se connecte à votre instance source lit le contenu des bases de données que vous avez sélectionnées pour la migration, puis charge les données dans l'instance de destination.

    Pour les migrations ponctuelles, nous vous recommandons de désactiver les écritures dans la base de données source pendant la phase de vidage complet. Vous pouvez ainsi éviter de perdre des données créées après le début du processus de migration.

    Vous pouvez également fournir vos propres fichiers de vidage pour Database Migration Service. Notez que toutes les données ajoutées à la base de données après la création des fichiers de dump ne seront pas migrées. La connexion réseau à votre base de données est toujours établie pour les vérifications de cohérence.

  3. Une fois la phase de vidage complet terminée, Database Migration Service promeut automatiquement la base de données de destination et termine la migration. Vous pouvez alors passer votre application à la nouvelle base de données de destination.

Migrations continues

  1. Lorsque vous créez le job de migration, Database Migration Service crée une instance d'orchestration temporaire pour gérer la réplication et transforme votre instance Cloud SQL de destination en réplica Cloud SQL. Aucun coût supplémentaire n'est associé à cette instance d'orchestration.

    Vue de l'instance de destination rétrogradée dans la console Cloud SQL. L'image montre comment l'instance de destination est gérée par l'instance d'orchestration temporaire.
    Figure 2. Instance de destination affichée sous l'instance d'orchestration temporaire dans la Google Cloud console.
    Vue de l'instance de destination rétrogradée dans la console Cloud SQL. L'image montre comment l'instance de destination est gérée par l'instance d'orchestration temporaire.

  2. Lorsque vous démarrez le job de migration, Database Migration Service lance la phase de vidage complet.

    Lors du vidage complet, Database Migration Service se connecte à votre instance source lit le contenu des bases de données que vous avez sélectionnées pour la migration, puis charge les données dans l'instance de destination.

    Vous pouvez également fournir vos propres fichiers de vidage pour Database Migration Service. Notez que toutes les données ajoutées à la base de données après la création des fichiers de dump ne seront pas migrées. La connexion réseau à votre base de données est toujours établie pour les vérifications de cohérence.

  3. Pour les migrations continues, une fois la phase de vidage complet terminée, Database Migration Service passe à la phase CDC. Pendant la phase CDC, Database Migration Service continue de surveiller les modifications apportées à vos bases de données sources, puis les réplique en continu sur l'instance de destination.

    Pendant la phase CDC, Database Migration Service ne copie pas les données réelles de vos tables sources . Au lieu de cela, il lit les informations extraites des fichiers journaux de la base de données pour répliquer les modifications dans la destination. Vous pouvez arrêter la réplication en cours et promouvoir le job de migration lorsque vous souhaitez passer votre application à l'instance de destination en tant que base de données de production.

Étape suivante