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 flux de migration MySQL
Figure 1. Transfert de données lors des migrations Database Migration Service pour MySQL. (cliquez sur l'image pour l'agrandir)
Présentation du flux de migration MySQL

Pour les migrations MySQL homogènes vers Cloud SQL, Database Migration Service accepte 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 de modification des données issues 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 instance répliquée Cloud SQL. Cette instance d'orchestration n'entraîne aucuns frais supplémentaires.

    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 console Google Cloud .
    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 lancez le job de migration, Database Migration Service commence 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 sur la base de données source pendant la phase de dump complet. Vous éviterez ainsi de perdre les données créées après le début du processus de migration.

    Vous pouvez également fournir vos propres fichiers de dump pour Database Migration Service. Notez que 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 contrôles 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. À ce stade, vous pouvez basculer votre application pour qu'elle utilise 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 instance répliquée Cloud SQL. Cette instance d'orchestration n'entraîne aucuns frais supplémentaires.

    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 console Google Cloud .
    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 dump pour Database Migration Service. Notez que 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 contrôles 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 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. À la place, 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 basculer votre application pour qu'elle utilise votre instance de destination comme base de données de production.

Étapes suivantes