Migrer depuis AWS vers Google Cloud: migrer depuis Amazon RDS et Amazon Aurora pour MySQL vers Cloud SQL pour MySQL

Last reviewed 2024-08-16 UTC

Google Cloud fournit des outils, des produits, des conseils et des services professionnels pour migrer d'Amazon Relational Database Service (RDS) ou d'Amazon Aurora vers Cloud SQL pour MySQL.

Ce document est destiné aux administrateurs cloud et de bases de données qui souhaitent planifier, implémenter et valider un projet de migration de base de données. Il s'adresse également aux décideurs qui évaluent l'opportunité d'effectuer une migration et qui souhaitent découvrir en quoi elle pourrait consister.

Ce document se concentre sur une migration de base de données homogène, c'est-à-dire une migration dans laquelle les bases de données source et cible utilisent la même technologie de base de données. Dans ce guide de migration, la source est Amazon RDS ou Amazon Aurora pour MySQL, et la destination est Cloud SQL pour MySQL.

Ce document fait partie d'une série d'articles sur la migration depuis AWS vers Google Cloud, qui comprend les documents suivants :

Pour cette migration vers Google Cloud, nous vous recommandons de suivre le framework de migration décrit dans la section Migrer vers Google Cloud : premiers pas.

Le diagramme suivant illustre le parcours de votre migration.

Chemin de migration en quatre phases.

Vous pouvez migrer depuis votre environnement source vers Google Cloud dans une série d'itérations. Par exemple, vous pouvez commencer par migrer certaines charges de travail, et en migrer d'autres ultérieurement. Pour chaque itération de migration distincte, vous suivez les phases du framework de migration général :

  1. Évaluer et découvrir vos charges de travail et vos données
  2. Planifier et établir vos fondations sur Google Cloud
  3. Migrer vos charges de travail et vos données vers Google Cloud
  4. Optimiser votre environnement Google Cloud

Pour en savoir plus sur les phases de ce framework, consultez la page Migrer vers Google Cloud : premiers pas.

Pour concevoir un plan de migration efficace, nous vous recommandons de valider chaque étape du plan et de vous assurer de disposer d'une stratégie de rollback. Pour vous aider à valider votre plan de migration, consultez la page Migrer vers Google Cloud : bonnes pratiques pour valider un plan de migration.

Évaluer l'environnement source

Au cours de la phase d'évaluation, vous déterminez les exigences et les dépendances pour migrer votre environnement source vers Google Cloud.

La phase d’évaluation est cruciale pour la réussite de votre migration. Vous devez acquérir une connaissance approfondie des charges de travail que vous souhaitez migrer, de leurs exigences, de leurs dépendances et de votre environnement actuel. Vous devez comprendre votre point de départ pour planifier et exécuter avec succès une migration Google Cloud.

La phase d'évaluation comprend les tâches suivantes :

  1. Dresser un inventaire complet de vos applications
  2. Cataloguer vos charges de travail en fonction de leurs propriétés et de leurs dépendances
  3. Former et préparer vos équipes sur Google Cloud
  4. Créer des tests et des démonstrations de faisabilité sur Google Cloud
  5. Calculer le coût total de possession (TCO) de l'environnement cible
  6. Choisissez la stratégie de migration pour vos charges de travail.
  7. Choisissez vos outils de migration.
  8. Définissez le plan de migration et le calendrier.
  9. Validez votre plan de migration.

La phase d'évaluation de la base de données vous aide à choisir la taille et les spécifications de votre instance de base de données Cloud SQL cible qui correspondent à la source pour des besoins de performances similaires. Portez une attention particulière à la taille et au débit du disque, aux IOPS et au nombre de processeurs virtuels. Les migrations peuvent rencontrer des difficultés ou échouer en raison d'une taille incorrecte de l'instance de base de données cible. Une taille incorrecte peut entraîner de longs délais de migration, des problèmes de performances de la base de données, des erreurs de base de données et des problèmes de performances de l'application. Lorsque vous choisissez une instance Cloud SQL, n'oubliez pas que les performances des disques sont basées sur la taille des disques et le nombre de processeurs virtuels.

Les sections suivantes s'appuient sur Migrer vers Google Cloud: évaluer et découvrir vos charges de travail et intègrent les informations de ce document.

Dresser l'inventaire de vos instances Amazon RDS ou Amazon Aurora

Pour définir le champ d'application de votre migration, vous devez créer un inventaire et collecter des informations sur vos instances Amazon RDS ou Amazon Aurora. Nous vous recommandons d'automatiser ce processus à l'aide d'outils spécialisés, car les approches manuelles sont sujettes aux erreurs et peuvent conduire à des hypothèses incorrectes.

Amazon RDS ou Amazon Aurora et Cloud SQL peuvent ne pas avoir de fonctionnalités, de spécifications d'instance ou d'opérations similaires. Certaines fonctionnalités peuvent être implémentées différemment ou être indisponibles. Les domaines de différences peuvent inclure l'infrastructure, le stockage, l'authentification et la sécurité, la réplication, la sauvegarde, la haute disponibilité, le modèle de capacité des ressources, ainsi que les intégrations et les extensions de fonctionnalités spécifiques du moteur de base de données. En fonction du type de moteur de base de données, de la taille de l'instance et de l'architecture, les valeurs par défaut des paramètres de base de données peuvent également varier.

Le benchmarking peut vous aider à mieux comprendre les charges de travail à migrer et à définir l'architecture appropriée de l'environnement cible de migration. Il est important de collecter des informations sur les performances pour estimer les besoins de l'environnement cible Google Cloud. Les concepts et outils d'analyse comparative sont détaillés dans la phase Effectuer des tests et des validations du processus de migration, mais ils s'appliquent également à l'étape de création de l'inventaire.

Outils d'évaluation

Pour une évaluation initiale de votre infrastructure actuelle, nous vous recommandons d'utiliser Google Cloud Migration Center ainsi que d'autres outils d'évaluation de base de données spécialisés tels que migVisor et l'outil d'évaluation de la migration de base de données (DMA).

Avec Migration Center, vous pouvez effectuer une évaluation complète de votre environnement d'applications et de bases de données, y compris l'adéquation technique pour une migration de base de données vers Google Cloud. Vous recevez des recommandations de taille et de configuration pour chaque base de données source, et vous créez un rapport sur le coût total de possession (TCO) pour les serveurs et les bases de données.

Pour en savoir plus sur l'évaluation de votre environnement AWS à l'aide de Migration Center, consultez la section Importer des données depuis d'autres fournisseurs cloud.

En plus de Migration Center, vous pouvez utiliser l'outil spécialisé migVisor. migVisor est compatible avec différents moteurs de base de données et est particulièrement adapté aux migrations hétérogènes. Pour en savoir plus sur migVisor, consultez la présentation de migVisor.

migVisor peut identifier les artefacts et les fonctionnalités de base de données propriétaires incompatibles susceptibles de provoquer la migration par défaut, et peut indiquer des solutions de contournement. migVisor peut également recommander une solution Google Cloud cible, y compris la taille et l'architecture initiales.

Le résultat de l'évaluation de la base de données migVisor fournit les informations suivantes :

  • Découverte et analyse complètes des déploiements de bases de données actuels.
  • Rapport détaillé sur la complexité de la migration, basé sur les fonctionnalités propriétaires utilisées par votre base de données.
  • Rapport financier avec des informations sur les économies de coûts après la migration, les coûts de migration et le nouveau budget d'exploitation.
  • Plan de migration par étapes pour déplacer les bases de données et les applications associées avec un minimum de perturbation pour l'entreprise.

Pour voir des exemples de résultats d'évaluation, consultez la page migVisor : outil d'évaluation de la migration vers le cloud.

Notez que migVisor augmente temporairement l'utilisation du serveur de base de données. En règle générale, cette charge supplémentaire est inférieure à 3 % et peut être exécutée en dehors des heures de pointe.

Le résultat de l'évaluation migVisor vous aide à créer un inventaire complet de vos instances RDS. Le rapport inclut des propriétés génériques (version et édition du moteur de base de données, CPU et taille de la mémoire), ainsi que des informations sur la topologie de la base de données, les règles de sauvegarde, les paramètres de paramètre et les personnalisations spéciales utilisées.

Si vous préférez utiliser des outils Open Source, vous pouvez utiliser des scripts de collecte de données avec (ou à la place) les outils mentionnés. Ces scripts peuvent vous aider à collecter des informations détaillées (sur les charges de travail, les fonctionnalités, les objets de base de données et le code de base de données) et à créer votre inventaire de bases de données. De plus, les scripts fournissent généralement une évaluation détaillée de la migration de la base de données, y compris une estimation de l'effort de migration.

Nous vous recommandons l'outil Open Source DMA, conçu par des ingénieurs Google. Il offre une évaluation complète et précise de la base de données, y compris des fonctionnalités utilisées, de la logique de base de données et des objets de base de données (y compris les schémas, les tables, les vues, les fonctions, les déclencheurs et les procédures stockées).

Pour utiliser l'outil DMA, téléchargez les scripts de collecte pour votre moteur de base de données à partir du dépôt Git, puis suivez les instructions. Envoyez les fichiers de sortie à Google Cloud pour analyse. Google Cloud crée et fournit un rapport d'évaluation de la base de données, ainsi que les prochaines étapes du processus de migration.

Identifier et documenter le champ d'application de la migration et les temps d'arrêt abordables

À ce stade, vous devez documenter les informations essentielles qui ont une incidence sur votre stratégie et vos outils de migration. À ce stade, vous pouvez répondre aux questions suivantes:

  • Vos bases de données ont-elles une taille supérieure à 5 To ?
  • Votre base de données contient-elle des tables volumineuses ? Leur taille est-elle supérieure à 16 To ?
  • Où sont situées les bases de données (régions et zones) et quelle est leur proximité avec les applications ?
  • À quelle fréquence les données changent-elles ?
  • Quel est votre modèle de cohérence des données ?
  • Quelles sont les options de bases de données de destination ?
  • Quelle est la compatibilité des bases de données source et de destination ?
  • Les données doivent-elles se trouver dans certains emplacements physiques ?
  • Existe-t-il des données qui peuvent être compressées et archivées, ou des données qui n'ont pas du tout besoin d'être migrées ?

Pour définir le champ d'application de la migration, décidez des données à conserver et à migrer. Migrer toutes vos bases de données peut prendre beaucoup de temps et d'efforts. Certaines données peuvent rester dans les sauvegardes de vos bases de données sources. Par exemple, les anciennes tables de journalisation ou les données d'archivage peuvent ne pas être nécessaires. Vous pouvez également décider de déplacer les données après le processus de migration, en fonction de votre stratégie et de vos outils.

Établissez des bases de référence pour la migration de données qui vous aideront à comparer et à évaluer vos résultats et impacts. Ces références sont des points de référence qui représentent l'état de vos données avant et après la migration, et qui vous aident à prendre des décisions. Il est important de prendre des mesures sur l'environnement source qui peuvent vous aider à évaluer la réussite de votre migration de données. Ces mesures incluent les suivantes:

  • La taille et la structure de vos données
  • l'exhaustivité et la cohérence de vos données ;
  • La durée et les performances des transactions et des processus commerciaux les plus importants.

Déterminez le temps d'arrêt que vous pouvez vous permettre. Quels sont les impacts commerciaux des temps d'arrêt ? Existe-t-il des périodes d'activité faible de la base de données, pendant lesquelles moins d'utilisateurs sont affectés par les temps d'arrêt ? Si oui, pendant combien de temps et quand ces périodes se produisent-elles ? Envisagez d'avoir un temps d'arrêt partiel en écriture seule, tandis que les requêtes en lecture seule sont toujours traitées.

Évaluer votre processus de déploiement et d'administration

Une fois les inventaires créés, évaluez les processus opérationnels et de déploiement de votre base de données pour déterminer comment vous devez les adapter pour faciliter votre migration. Ces processus sont fondamentaux pour la façon dont vous préparez et gérez votre environnement de production.

Réfléchissez à la façon dont vous effectuez les tâches suivantes :

  • Définir et appliquer des règles de sécurité pour vos instances: par exemple, vous devrez peut-être remplacer les groupes de sécurité Amazon. Vous pouvez utiliser les rôles Google IAM, les règles de pare-feu VPC et VPC Service Controls pour contrôler l'accès à vos instances Cloud SQL et limiter les données dans un VPC.

  • Appliquez des correctifs et configurez vos instances: vous devrez peut-être mettre à jour vos outils de déploiement existants. Par exemple, vous pouvez utiliser des paramètres de configuration personnalisés dans des groupes de paramètres ou des groupes d'options Amazon. Vos outils de provisionnement devront peut-être être adaptés pour utiliser Google Cloud Storage ou Secret Manager afin de lire ces listes de configuration personnalisées.

  • Gérer l'infrastructure de surveillance et d'alerte: les catégories de métriques pour vos instances de base de données source Amazon offrent une observabilité pendant le processus de migration. Les catégories de métriques peuvent inclure Amazon CloudWatch, Performance Insights, la surveillance améliorée et les listes de processus de l'OS.

Terminer l'évaluation

Après avoir créé les inventaires de votre environnement Amazon RDS ou Amazon Aurora, effectuez les autres étapes de la phase d'évaluation décrites sur la page Migrer vers Google Cloud: évaluer et découvrir vos charges de travail.

Planifier et établir vos fondations

Au cours de la phase de planification et de compilation, vous provisionnez et configurez l'infrastructure pour effectuer les opérations suivantes :

  • Exécuter vos charges de travail dans votre environnement Google Cloud
  • Se connecter à votre environnement source et à votre environnement Google Cloud pour effectuer la migration

La phase de planification et de compilation est composée des tâches suivantes :

  1. Créez une hiérarchie de ressources.
  2. Configurer Identity and Access Management (IAM) de Google Cloud
  3. Configurer la facturation
  4. Configurez la connectivité réseau.
  5. Renforcez votre sécurité.
  6. Configurer la journalisation, la surveillance et les alertes

Pour en savoir plus sur chacune de ces tâches, consultez la section Migrer vers Google Cloud: planifier et créer vos fondations.

Si vous prévoyez d'utiliser Database Migration Service pour la migration, consultez la section Méthodes de mise en réseau pour MySQL pour comprendre les configurations réseau disponibles pour les scénarios de migration.

Surveillance et alertes

Utilisez Cloud Monitoring de Google, qui inclut des tableaux de bord prédéfinis pour plusieurs produits Google Cloud, y compris un tableau de bord de surveillance Cloud SQL. Vous pouvez également envisager d'utiliser des solutions de surveillance tierces intégrées à Google Cloud, comme Datadog et Splunk. Pour en savoir plus, consultez la section À propos de l'observabilité des bases de données.

Migrer des instances Amazon RDS et Amazon Aurora pour MySQL vers Cloud SQL pour MySQL

Pour migrer vos instances, procédez comme suit:

  1. Choisissez la stratégie de migration: réplication continue ou maintenance planifiée.

  2. Choisissez les outils de migration en fonction de la stratégie et des exigences que vous avez choisies.

  3. Définissez le plan et le calendrier de migration pour chaque migration de base de données, y compris les tâches de préparation et d'exécution.

  4. Définissez les tâches de préparation à effectuer pour vous assurer que l'outil de migration peut fonctionner correctement.

  5. Définissez les tâches d'exécution, qui incluent les activités de travail qui implémentent la migration.

  6. Définissez des scénarios de remplacement pour chaque tâche d'exécution.

  7. Effectuez des tests et des validations, qui peuvent être effectués dans un environnement de préproduction distinct.

  8. Effectuez la migration.

  9. Effectuez le basculement en production.

  10. Nettoyez l'environnement source et configurez l'instance cible.

  11. Effectuer un réglage et une optimisation

Chaque phase est décrite dans les sections suivantes :

Choisir votre stratégie de migration

À cette étape, vous disposez de suffisamment d'informations pour évaluer et sélectionner l'une des stratégies de migration suivantes qui correspond le mieux à votre cas d'utilisation pour chaque base de données:

  • Maintenance planifiée (également appelée migration ponctuelle): cette approche est idéale si vous pouvez vous permettre un temps d'arrêt. Cette option est relativement moins coûteuse et complexe, car vos charges de travail et vos services ne nécessiteront pas beaucoup de refactorisation. Toutefois, si la migration échoue avant la fin, vous devez redémarrer le processus, ce qui prolonge le temps d'arrêt.

  • Réplication continue (également appelée migration par goutte-à-goutte): pour les bases de données critiques, cette option offre un risque de perte de données plus faible et un temps d'arrêt quasi nul. Les efforts sont divisés en plusieurs blocs. Par conséquent, en cas d'échec, le rollback et la répétition prennent moins de temps. Toutefois, la configuration est plus complexe et nécessite plus de planification et de temps. Des efforts supplémentaires sont également nécessaires pour refactoriser les applications qui se connectent à vos instances de base de données. Envisagez l'une des variantes suivantes:

    • En utilisant l'approche Y (écriture et lecture), qui est une forme de migration parallèle, en dupliquant les données dans les instances source et de destination pendant la migration.
    • En utilisant un microservice d'accès aux données, ce qui réduit les efforts de refactorisation requis par l'approche Y (écriture et lecture).

Pour en savoir plus sur les stratégies de migration de données, consultez la section Évaluer les approches de migration des données.

Le schéma suivant présente un organigramme basé sur des exemples de questions que vous pourriez vous poser pour déterminer la stratégie de migration d'une seule base de données:

Organigramme pour vous aider à choisir la stratégie de migration.

L'organigramme précédent présente les points de décision suivants:

  • Pouvez-vous vous permettre un temps d'arrêt ?

    • Si ce n'est pas le cas, adoptez la stratégie de migration de réplication continue.
    • Si oui, passez au point de décision suivant.

  • Pouvez-vous vous permettre le temps d'arrêt représenté par un intervalle de basculement lors de la migration de données ? La période de transition représente le temps nécessaire pour effectuer une sauvegarde de la base de données, la transférer vers Cloud SQL, la restaurer, puis migrer vos applications.

    • Si ce n'est pas le cas, adoptez la stratégie de migration de réplication continue.
    • Si la réponse est oui, adoptez la stratégie de migration de maintenance planifiée.

Les stratégies peuvent varier pour différentes bases de données, même lorsqu'elles se trouvent sur la même instance. Un mix de stratégies peut produire des résultats optimaux. Par exemple, migrez les bases de données de petite taille et peu utilisées à l'aide de l'approche de maintenance planifiée, mais utilisez la réplication continue pour les bases de données critiques pour lesquelles les temps d'arrêt sont coûteux.

En général, une migration est considérée comme terminée lorsque le basculement entre l'instance source initiale et l'instance cible a lieu. Toute réplication (le cas échéant) est arrêtée, et toutes les lectures et écritures sont effectuées sur l'instance cible. Le basculement lorsque les deux instances sont synchronisées n'entraîne aucune perte de données et un temps d'arrêt minimal.

Pour en savoir plus sur les stratégies et les déploiements de migration de données, consultez la section Classification des migrations de bases de données.

Les configurations de migration qui ne comportent aucun temps d'arrêt de l'application nécessitent une configuration plus complexe. Trouvez le bon équilibre entre la complexité de la configuration et les temps d'arrêt programmés pendant les heures ouvrées où le trafic est faible.

Chaque stratégie de migration comporte un compromis et un impact associé au processus de migration. Par exemple, les processus de réplication impliquent une charge supplémentaire sur vos instances sources, et vos applications peuvent être affectées par le délai avant réplication. Les applications (et les clients) peuvent être amenées à attendre pendant les temps d'arrêt de l'application, au moins aussi longtemps que le délai de réplication avant d'utiliser la nouvelle base de données. En pratique, les facteurs suivants peuvent augmenter le temps d'arrêt:

  • Les requêtes de base de données peuvent prendre quelques secondes. Au moment de la migration, les requêtes en cours peuvent être interrompues.
  • Le remplissage du cache peut prendre un certain temps si la base de données est volumineuse ou si elle dispose d'une mémoire tampon importante.
  • Les applications arrêtées dans la source et redémarrées dans Google Cloud peuvent présenter un léger temps de latence jusqu'à ce que la connexion à l'instance de base de données Google Cloud soit établie.
  • Les routes réseau vers les applications doivent être redirigées. Selon la configuration des entrées DNS, cette opération peut prendre un certain temps. Lorsque vous mettez à jour les enregistrements DNS, réduisez la valeur TTL avant la migration.

Les pratiques courantes suivantes peuvent contribuer à réduire les temps d'arrêt et l'impact:

  • Trouvez une période où les temps d'arrêt auront un impact minimal sur vos charges de travail. Par exemple, en dehors des heures d'ouverture normales, les week-ends ou pendant d'autres intervalles de maintenance planifiés.
  • Identifiez les parties de vos charges de travail qui peuvent être migrées et passer en production à différentes étapes. Vos applications peuvent comporter différents composants qui peuvent être isolés, adaptés et migrés sans impact. Par exemple, les interfaces, les modules CRM, les services backend et les plates-formes de création de rapports. Ces modules peuvent avoir leurs propres bases de données, qui peuvent être planifiées pour la migration plus tôt ou plus tard dans le processus.
  • Si vous pouvez accepter une latence sur la base de données cible, envisagez d'implémenter une migration progressive. Utilisez des transferts de données incrémentiels par lot et adaptez une partie de vos charges de travail pour qu'elles fonctionnent avec les données obsolètes de l'instance cible.
  • Envisagez de refactoriser vos applications pour réduire l'impact de la migration. Par exemple, adaptez vos applications pour qu'elles écrivent à la fois dans les bases de données source et cible, et implémentez ainsi une réplication au niveau de l'application.

Choisissez vos outils de migration.

Le facteur le plus important pour une migration réussie est de choisir le bon outil de migration. Une fois la stratégie de migration définie, examinez et choisissez l'outil de migration.

De nombreux outils sont disponibles, chacun étant optimisé pour certains cas d'utilisation de migration. Voici quelques cas d'utilisation:

  • Stratégie de migration (maintenance planifiée ou réplication continue)
  • Moteurs et versions de base de données source et cible
  • Environnements dans lesquels se trouvent les instances source et cible.
  • Taille de la base de données Plus la base de données est volumineuse, plus la migration de la sauvegarde initiale prend du temps.
  • Fréquence des modifications de la base de données.
  • Possibilité d'utiliser des services gérés pour la migration.

Pour assurer une migration et une transition fluides, vous pouvez utiliser des modèles de déploiement d'applications, une orchestration de l'infrastructure et des applications de migration personnalisées. Toutefois, des outils spécialisés appelés services de migration gérés peuvent faciliter le processus de transfert de données, d'applications ou même d'infrastructures entières d'un environnement à un autre. Ils exécutent l'extraction des données à partir des bases de données sources, les transportent de manière sécurisée vers les bases de données cibles et peuvent éventuellement les modifier pendant le transit. Grâce à ces fonctionnalités, elles encapsulent la logique complexe de la migration et offrent des fonctionnalités de surveillance de la migration.

Les services de migration gérés offrent les avantages suivants:

  • Minimiser les temps d'arrêt : les services utilisent les fonctionnalités de réplication intégrées des moteurs de base de données lorsqu'elles sont disponibles et effectuent la promotion des instances répliquées.

  • Assurer l'intégrité et la sécurité des données : les données sont transférées de manière sécurisée et fiable de la base de données source vers la base de données cible.

  • Offrir une expérience de migration cohérente: différentes techniques et tendances de migration peuvent être regroupées dans une interface cohérente et commune à l'aide d'exécutables de migration de base de données, que vous pouvez gérer et surveiller.

  • Proposez des modèles de migration résilients et éprouvés: les migrations de bases de données sont des événements peu fréquents, mais critiques. Pour éviter les erreurs de débutant et les problèmes liés aux solutions existantes, vous pouvez utiliser les outils d'experts expérimentés plutôt que de créer une solution personnalisée.

  • Optimiser les coûts: les services de migration gérés peuvent être plus rentables que le provisionnement de serveurs et de ressources supplémentaires pour des solutions de migration personnalisées.

Les sections suivantes décrivent les recommandations concernant les outils de migration, qui dépendent de la stratégie de migration choisie.

Outils pour les migrations de maintenance planifiée

Le diagramme suivant présente un organigramme avec des questions qui peuvent vous aider à choisir l'outil de migration pour une seule base de données lorsque vous utilisez une stratégie de migration de maintenance planifiée:

Organigramme pour vous aider à choisir un outil de migration de maintenance planifiée.

L'organigramme précédent présente les points de décision suivants:

  • Préférez-vous des services de migration gérés ?
    • Si la réponse est oui, nous vous recommandons d'utiliser Database Migration Service.
    • Si ce n'est pas le cas, nous vous recommandons de migrer en utilisant les sauvegardes intégrées du moteur de base de données.

L'utilisation d'un service de migration géré présente certains avantages, qui sont décrits dans la section Choisir vos outils de migration de ce document.

Les sous-sections suivantes décrivent les outils pouvant être utilisés pour les migrations ponctuelles, ainsi que leurs limites et les bonnes pratiques à suivre.

Database Migration Service pour la migration de maintenance planifiée

Database Migration Service gère à la fois la synchronisation initiale et la réplication de la capture des données modifiées (CDC, Change Data Capture) en cours, et fournit l'état de l'opération de migration.

Database Migration Service vous permet de créer des jobs de migration que vous pouvez gérer et valider. Nous vous recommandons d'utiliser Database Migration Service, car il est compatible avec les migrations vers Cloud SQL pour MySQL via des jobs de migration uniques. Pour les bases de données volumineuses, vous pouvez utiliser le parallélisme de vidage de données dans Database Migration Service.

Pour en savoir plus sur l'architecture de migration de base de données et sur Database Migration Service, consultez Migrer une base de données vers Cloud SQL pour MySQL à l'aide de Database Migration Service et Fidélité de migration pour MySQL.

Pour en savoir plus sur les limites et les conditions préalables de Database Migration Service, consultez les ressources suivantes:

Sauvegardes du moteur de base de données intégrées

Lorsque des temps d'arrêt importants sont acceptables et que vos bases de données sources sont relativement statiques, vous pouvez utiliser les fonctionnalités de vidage et de chargement (parfois appelées sauvegarde et restauration) intégrées au moteur de base de données.

La configuration et la synchronisation nécessitent un certain effort, en particulier pour un grand nombre de bases de données, mais les sauvegardes du moteur de base de données sont généralement facilement disponibles et simples à utiliser.

Les sauvegardes du moteur de base de données présentent les limites générales suivantes:

  • Les sauvegardes peuvent être sujettes à des erreurs, en particulier si elles sont effectuées manuellement.
  • Les données ne sont pas sécurisées si les sauvegardes ne sont pas gérées correctement.
  • Les sauvegardes ne disposent pas de fonctionnalités de surveillance appropriées.
  • Des efforts sont nécessaires pour assurer l'évolutivité si de nombreuses bases de données sont migrées à l'aide de cet outil.

Si vous choisissez cette approche, tenez compte des limites et des bonnes pratiques suivantes:

  • Si votre base de données est relativement petite (moins de 10 Go), nous vous recommandons d'utiliser mysqldump. Il n'existe pas de limite fixe, mais la taille de base de données idéale pour mysqldump est généralement inférieure à 10 Go.

  • Si vous importez des bases de données de plus de 10 Go, vous devrez peut-être utiliser d'autres stratégies pour minimiser le temps d'arrêt de la base de données. Voici quelques exemples de stratégies:

    • Exporter le schéma et les données en sous-sections, sans clés secondaires
    • Tirez parti des codes temporels. Si l'une de vos tables utilise des colonnes d'horodatage, vous pouvez utiliser une fonctionnalité de la commande mysqldump qui vous permet de spécifier une clause WHERE pour filtrer par colonne d'horodatage.
    • Envisagez d'autres approches, comme l'utilisation des outils mydumper et myloader.

Les vidages et sauvegardes de base de données n'incluent généralement pas les comptes utilisateur MySQL. Lorsque vous préparez la migration, examinez tous les comptes utilisateur de l'instance source. Par exemple, vous pouvez exécuter la commande SHOW GRANTS pour chaque utilisateur afin d'examiner l'ensemble actuel de droits et de déterminer si certains sont restreints dans Cloud SQL. De même, l'outil pt-show-grants de Percona peut également répertorier les autorisations.

Les restrictions sur les privilèges utilisateur dans Cloud SQL peuvent affecter les migrations lors de la migration d'objets de base de données comportant un attribut DEFINER. Par exemple, une procédure stockée peut comporter une définition de droit super permettant d'exécuter des commandes SQL, comme la modification d'une variable globale non autorisée dans Cloud SQL. Dans de tels cas, vous devrez peut-être réécrire le code de la procédure stockée ou migrer des objets hors table tels que des procédures stockées lors d'une étape de migration distincte. Pour en savoir plus, consultez les bonnes pratiques pour l'importation et l'exportation de données.

Pour en savoir plus sur les limites et les bonnes pratiques, consultez les ressources suivantes:

Autres approches de migration de maintenance planifiée

Lorsque vous utilisez une importation gérée pour configurer la réplication à partir d'une base de données MySQL externe, les données de la base de données externe sont chargées initialement dans l'instance Cloud SQL. Cette approche utilise un service qui extrait les données du serveur externe (l'instance RDS dans ce cas) et les importe directement dans l'instance Cloud SQL.

Pour les grandes bases de données (plusieurs To), il est plus rapide d'utiliser une importation personnalisée avec une charge initiale qui utilise les outils mydumper et myloader.

Vous pouvez envisager d'exporter les tables de votre base de données MySQL vers des fichiers CSV, qui peuvent ensuite être importés dans Cloud SQL pour MySQL. Pour exporter des données à partir de votre instance RDS, vous pouvez utiliser AWS Database Migration Service (AWS DMS) et un bucket S3 comme cible.

Pour en savoir plus, consultez la section Utiliser une importation gérée pour configurer la réplication à partir de bases de données externes.

Outils pour les migrations de réplication continue

Le schéma suivant présente un organigramme avec des questions qui peuvent vous aider à choisir l'outil de migration pour une seule base de données lorsque vous utilisez une stratégie de migration de réplication continue:

Organigramme pour vous aider à choisir un outil de migration de réplication continue.

L'organigramme précédent présente les points de décision suivants:

  • Préférez-vous utiliser des services de migration gérés ?

    • Si oui, pouvez-vous vous permettre quelques secondes d'indisponibilité d'écriture, en fonction du nombre de tables de votre base de données ?

      • Si la réponse est oui, utilisez Database Migration Service.
      • Si ce n'est pas le cas, explorez les autres options de migration.

    • Si ce n'est pas le cas, vous devez évaluer si la réplication intégrée du moteur de base de données est prise en charge:

      • Si tel est le cas, nous vous recommandons d'utiliser la réplication intégrée.
      • Si ce n'est pas le cas, nous vous recommandons d'explorer d'autres options de migration.

Les sections suivantes décrivent les outils pouvant être utilisés pour les migrations continues, ainsi que leurs limites et leurs bonnes pratiques.

Database Migration Service pour la migration de réplication continue

Database Migration Service prend en charge les migrations continues grâce à l'utilisation de types de jobs de migration continue. Seuls les jobs de migration continue peuvent être promus, ce qui indique que la réplication doit s'arrêter.

Si vous choisissez cet outil, tenez compte des restrictions et des bonnes pratiques suivantes:

  • Évitez les transactions de longue durée pendant la migration. Dans ce cas, nous vous recommandons de migrer à partir d'un réplica de lecture si vous ne migrez pas à partir d'AWS Aurora.
  • Pour obtenir la liste complète des limites, consultez la section Limites connues.

Réplication intégrée du moteur de base de données

La réplication intégrée du moteur de base de données est une alternative à Database Migration Service pour une migration continue.

La réplication de base de données représente le processus de copie et de distribution des données d'une base de données appelée base de données principale vers d'autres bases de données appelées instances répliquées. Ce processus vise à améliorer l'accessibilité des données, ainsi que la tolérance aux pannes et la fiabilité d'un système de base de données. Bien que la migration de bases de données ne soit pas l'objectif principal de la réplication de bases de données, elle peut être utilisée comme outil pour atteindre cet objectif. La réplication de base de données est généralement un processus en cours qui se produit en temps réel lorsque des données sont insérées, mises à jour ou supprimées dans la base de données principale. Il peut s'agir d'une opération unique ou d'une séquence d'opérations par lots.

La plupart des moteurs de base de données modernes implémentent différentes méthodes de réplication de base de données. Un type de réplication peut être obtenu en copiant et en envoyant le journal WAL (Write-Ahead Logging) ou le journal des transactions de l'instance principale à ses instances répliquées. Cette approche est appelée réplication physique ou binaire. D'autres types de réplication fonctionnent en distribuant les instructions SQL brutes qu'une base de données principale reçoit, au lieu de répliquer les modifications au niveau du système de fichiers.

Cloud SQL est compatible avec la réplication pour MySQL. Toutefois, certains prérequis et limites s'appliquent.

Prérequis :

  • Assurez-vous d'utiliser MySQL 5.5, 5.6, 5.7 ou 8.0 sur votre instance Amazon RDS ou Amazon Aurora.
  • Assurez-vous que les journaux binaires sont activés.
  • Pour accélérer la phase de vidage complète initiale, choisissez un niveau de machine suffisamment important en termes de processeur et de taille de mémoire.
  • Si vous devez accélérer la phase CDC, vous pouvez essayer de configurer la réplication parallèle et d'activer le vidage hautes performances.
  • Si l'instance dupliquée Cloud SQL est activée avec des adresses IP internes, car l'adresse IP sortante n'est pas statique, configurez le pare-feu du serveur Amazon RDS ou Amazon Aurora pour autoriser la plage d'adresses IP internes allouée à l'accès aux services privés du réseau VPC que l'instance dupliquée Cloud SQL utilise comme réseau privé. Pour en savoir plus, consultez les pages À propos de la réplication depuis un serveur externe et Configurer l'accès aux services privés.

Limites :

  • Si votre base de données contient de grandes tables uniques et de nombreux index secondaires, l'extraction complète initiale peut prendre plus de temps.
  • Si votre serveur externe contient des clauses DEFINER (vues, événements, déclencheurs ou procédures stockées), selon l'ordre d'exécution de ces instructions, la réplication peut échouer. En savoir plus sur l'utilisation de DEFINER et sur les solutions de contournement potentielles dans Cloud SQL
  • InnoDB est le seul moteur de base de données compatible avec Cloud SQL. La migration de MyISAM peut entraîner des incohérences et nécessiter une validation des données. Consultez Convertir des tables MyISAM vers InnoDB.

Autres approches de migration de réplication continue

Voici d'autres approches de migration de réplication continue:

  • Refactorisez vos applications pour effectuer des opérations Y (écriture et lecture) ou utilisez un microservice d'accès aux données.

    • La réplication continue est effectuée par vos applications.
    • L'effort de migration est axé sur le refactoring ou le développement d'outils qui se connectent à vos instances de base de données.
    • Les applications Reader sont ensuite progressivement refactorisées et déployées pour utiliser l'instance cible.

  • Répliquez les modifications de votre instance MySQL en temps quasi réel à l'aide de Datastream.

    • Datastream est un service de réplication et de capture des données modifiées (CDC) sans serveur qui peut être utilisé avec Amazon RDS ou Amazon Aurora pour répliquer et synchroniser des données.
    • Utilisez Datastream pour répliquer les modifications de votre instance MySQL dans BigQuery ou Cloud Storage, puis Dataflow ou Dataproc pour importer les données dans votre instance Cloud SQL.

Pour en savoir plus sur la réplication avec Datastream, consultez les ressources suivantes:

Outils tiers pour la migration de la réplication continue

Dans certains cas, il peut être préférable d'utiliser un seul outil tiers pour la plupart des moteurs de base de données. Par exemple, si vous préférez utiliser un service de migration géré et que vous devez vous assurer que la base de données cible est toujours synchronisée en quasi-temps réel avec la source, ou si vous avez besoin de transformations plus complexes telles que le nettoyage, la restructuration et l'adaptation des données pendant le processus de migration.

Si vous décidez d'utiliser un outil tiers, choisissez l'une des recommandations suivantes, que vous pouvez utiliser pour la plupart des moteurs de base de données.

Striim est une plate-forme en mémoire de bout en bout qui permet de collecter, filtrer, transformer, enrichir, agréger, analyser et diffuser des données en temps réel:

  • Avantages :

    • Gère de grands volumes de données et des migrations complexes.
    • Capture des données modifiées intégrée pour SQL Server
    • Modèles de connexion préconfigurés et pipelines sans code
    • Peut gérer de grandes bases de données critiques qui fonctionnent sous une charge transactionnelle importante.
    • Diffusion de type "exactement une fois".

  • Inconvénients :

Pour en savoir plus sur Striim, consultez la page Exécuter Striim dans Google Cloud.

Debezium est une plate-forme distribuée Open Source pour la capture des données modifiées. Elle peut diffuser des modifications de données aux abonnés externes:

  • Avantages :

    • Open Source.
    • Un soutien important de la communauté
    • Rentable
    • Contrôle précis des lignes, des tables ou des bases de données
    • Spécialisé pour la capture des modifications en temps réel à partir des journaux des transactions de base de données.

  • Inconvénients :

    • Nécessite une expérience spécifique avec Kafka et ZooKeeper.
    • Distribution de type "au moins une fois" des modifications de données, ce qui signifie que vous devez gérer les doublons.
    • Configuration manuelle de la surveillance à l'aide de Grafana et Prometheus
    • La réplication par lot incrémentielle n'est pas prise en charge.

Pour en savoir plus sur les migrations Debezium, consultez la section Réplication de données en temps quasi réel avec Debezium.

Fivetran est une plate-forme de transfert de données automatisée qui permet de transférer des données depuis et entre des plates-formes de données cloud.

  • Avantages :

    • Modèles de connexion préconfigurés et pipelines sans code
    • Propage toutes les modifications de schéma de votre source vers la base de données cible.
    • Distribution de type "exactement une fois" des modifications de vos données, ce qui signifie que vous n'avez pas besoin de gérer les doublons.

  • Inconvénients :

    • Non Open Source.
    • La prise en charge des transformations de données complexes est limitée.

Vous devez définir le plan de migration et le calendrier

Pour réussir la migration de la base de données et le passage en production, nous vous recommandons de préparer un plan de migration complet et bien défini. Pour réduire l'impact sur votre activité, nous vous recommandons de créer une liste de tous les éléments de travail nécessaires.

La définition du champ d'application de la migration révèle les tâches que vous devez effectuer avant, pendant et après le processus de migration de la base de données. Par exemple, si vous décidez de ne pas migrer certaines tables à partir d'une base de données, vous devrez peut-être effectuer des tâches avant ou après la migration pour implémenter ce filtrage. Vous vous assurez également que la migration de votre base de données n'affecte pas votre contrat de niveau de service (SLA) et votre plan de continuité d'activité existants.

Nous vous recommandons d'inclure les documents suivants dans votre documentation de planification de la migration:

  • Document de conception technique (CDT)
  • Matrice RACI
  • Calendrier (par exemple, un plan "T-Minus")

Les migrations de bases de données sont un processus itératif, et les premières migrations sont souvent plus lentes que les suivantes. En général, les migrations bien planifiées se déroulent sans problème, mais des problèmes imprévus peuvent toujours survenir. Nous vous recommandons de toujours disposer d'un plan de rollback. Nous vous recommandons de suivre les conseils de la section Migrer vers Google Cloud: bonnes pratiques pour valider un plan de migration.

TDD

Le TDD documente toutes les décisions techniques à prendre pour le projet. Incluez les éléments suivants dans le TDD:

  • Exigences commerciales et criticité
  • Objectif de temps de récupération (RTO) :
  • Objectif de point de reprise après sinistre (RPO) :
  • Détails de la migration de la base de données
  • Estimations de l'effort de migration
  • Recommandations de validation de la migration

Matrice RACI

Certains projets de migration nécessitent une matrice RACI, qui est un document de gestion de projet courant qui définit les personnes ou groupes responsables des tâches et des livrables du projet de migration.

Chronologie

Préparez un calendrier pour chaque base de données à migrer. Incluez toutes les tâches à accomplir, ainsi que les dates de début et de fin estimées.

Pour chaque environnement de migration, nous vous recommandons de créer un plan T-minus. Un plan "Jour J" est structuré comme un calendrier de compte à rebours et liste toutes les tâches requises pour mener à bien le projet de migration, ainsi que les groupes responsables et la durée estimée.

Le calendrier doit tenir compte non seulement de l'exécution des tâches de préparation préalable à la migration, mais aussi des tâches de validation, d'audit ou de test qui ont lieu après le transfert de données.

La durée des tâches de migration dépend généralement de la taille de la base de données, mais d'autres aspects doivent également être pris en compte, comme la complexité de la logique métier, l'utilisation de l'application et la disponibilité de l'équipe.

Voici un exemple de plan de lancement:

Date Phase Catégorie Tâches Rôle T-minus État
11/1/2023 Pré-migration Évaluation Créer un rapport d'évaluation Équipe de découverte -21 Terminée
11/7/2023 Pré-migration Préparation des cibles Concevoir l'environnement cible tel que décrit dans le document de conception Équipe de migration -14 Terminée
11/15/2023 Pré-migration Gouvernance d'entreprise Date de migration et approbation du délai avant le lancement Direction -6 Terminée
11/18/2023 Migration Configurer DMS Créer des profils de connexion Ingénieur en migration vers le cloud -3 Terminée
11/19/2023 Migration Configurer DMS Créer et démarrer des tâches de migration Ingénieur en migration vers le cloud -2 Non démarrée
11/19/2023 Migration Surveiller le DMS Surveiller les jobs DMS et les modifications LDD dans l'instance source Ingénieur en migration vers le cloud -2 Non démarrée
11/21/2023 Migration Basculement DMS Promouvoir une instance DMS répliquée Ingénieur en migration vers le cloud 0 Non démarrée
11/21/2023 Migration Validation de la migration Validation de la migration de la base de données Équipe de migration 0 Non démarrée
11/21/2023 Migration Test de l'application Exécuter des tests de fonctionnalités et de performances Équipe de migration 0 Non démarrée
11/22/2023 Migration Gouvernance d'entreprise Validation de la migration : OK ou KO Équipe de migration 1 Non démarrée
11/23/2023 Post-migration Valider la surveillance Configurer la surveillance Équipe en charge de l'infrastructure 2 Non démarrée
11/25/2023 Post-migration Sécurité Supprimer le compte utilisateur DMS Équipe de sécurité 4 Non démarrée

Plusieurs migrations de bases de données

Si vous devez migrer plusieurs bases de données, votre plan de migration doit contenir des tâches pour toutes les migrations.

Nous vous recommandons de commencer le processus par la migration d'une base de données plus petite, idéalement non critique. Cette approche peut vous aider à développer vos connaissances et votre confiance dans le processus et les outils de migration. Vous pouvez également détecter toute faille dans le processus dès les premières étapes du calendrier de migration global.

Si vous devez migrer plusieurs bases de données, les délais peuvent être chargés en parallèle. Par exemple, pour accélérer le processus de migration, vous pouvez choisir de migrer un groupe de bases de données petites, statiques ou moins critiques en même temps, comme illustré dans le diagramme suivant.

Tâches de migration de bases de données parallèles

Dans l'exemple illustré dans le diagramme, les bases de données 1 à 4 sont un groupe de petites bases de données migrées simultanément.

Définir les tâches de préparation

Les tâches de préparation sont toutes les activités que vous devez effectuer pour remplir les conditions préalables à la migration. Sans les tâches de préparation, la migration ne peut pas avoir lieu ou la base de données migrée se trouve dans un état inutilisable.

Les tâches de préparation peuvent être classées comme suit:

  • Préparation et prérequis pour les instances Amazon RDS ou Amazon Aurora
  • Préparation et conditions préalables pour la base de données source
  • Configuration de Cloud SQL
  • Configuration spécifique à la migration

Préparation et prérequis pour les instances Amazon RDS ou Amazon Aurora

Tenez compte des tâches de configuration et de prérequis courantes suivantes:

  • Selon votre chemin de migration, vous devrez peut-être autoriser les connexions à distance sur vos instances RDS. Si votre instance RDS est configurée pour être privée dans votre VPC, une connectivité RFC 1918 privée doit exister entre Amazon et Google Cloud.

  • Vous devrez peut-être configurer un nouveau groupe de sécurité pour autoriser les connexions à distance sur les ports requis.

    • Par défaut, dans AWS, l'accès réseau est désactivé pour les instances de base de données.
    • Vous pouvez spécifier des règles dans un groupe de sécurité qui autorisent l'accès à partir d'une plage d'adresses IP, d'un port ou d'un groupe de sécurité. Les mêmes règles s'appliquent à toutes les instances de base de données associées à ce groupe de sécurité.

  • Assurez-vous que vous disposez d'un espace disque suffisant pour mettre en mémoire tampon les journaux WAL pendant toute la durée de l'opération de chargement complet sur votre instance Amazon RDS.

  • Pour des résultats de migration optimaux, envisagez de migrer à partir d'un réplica de lecture, sauf si vous migrez depuis Amazon Aurora. De plus, nous vous recommandons de commencer le processus de migration pendant une période d'activité de base de données réduite.

  • MySQL limite le nom d'hôte à 60 caractères. Les noms d'hôte des bases de données Amazon RDS sont généralement plus longs que 60 caractères. Si tel est le cas pour la base de données que vous migrez, configurez une redirection DNS pour créer un enregistrement CNAME qui associe votre nom de domaine au nom de domaine de votre instance de base de données RDS.

  • Si vous utilisez la réplication intégrée, vous devez configurer votre instance Amazon RDS ou Amazon Aurora pour la réplication. La réplication intégrée ou les outils qui l'utilisent nécessitent que la journalisation binaire pour MySQL soit définie sur ROW.

  • Si vous utilisez des outils tiers, des paramètres et des configurations préalables sont généralement requis avant de pouvoir les utiliser. Consultez la documentation de l'outil tiers.

Pour en savoir plus sur la préparation des instances et les conditions préalables, consultez la section Configurer le serveur externe pour la réplication pour MySQL.

Préparation et conditions préalables pour la base de données source

  • Si vous choisissez d'utiliser Database Migration Service, vous devez configurer votre base de données source avant de vous y connecter. Examinez les tâches de migration avant de les implémenter. Pour en savoir plus, consultez la section Configurer votre source pour MySQL.
  • En fonction de votre moteur de base de données, vous devrez peut-être modifier certaines fonctionnalités. Par exemple, Cloud SQL pour MySQL n'est compatible qu'avec le moteur de base de données InnoDB. Vous devez remplacer les tables MyISAM par des tables InnoDB.
  • Certains outils de migration tiers exigent que toutes les colonnes LOB puissent avoir une valeur nulle. Toute colonne LOB qui est NOT NULL doit avoir cette contrainte supprimée lors de la migration.

  • Effectuez des mesures de référence sur votre environnement source en production. Réfléchissez aux éléments suivants :

    • Mesurez la taille de vos données, ainsi que les performances de votre charge de travail. Combien de temps durent les requêtes ou transactions importantes, en moyenne ? Combien de temps pendant les heures de pointe ?
    • Documentez les mesures de référence pour les comparer ultérieurement, afin de déterminer si la fidélité de votre migration de base de données est satisfaisante. Déterminez si vous pouvez basculer vos charges de travail de production et mettre hors service votre environnement source, ou si vous en avez encore besoin à des fins de remplacement.

Configuration de Cloud SQL

Choisissez soigneusement la taille et les spécifications de votre instance de base de données Cloud SQL pour MySQL cible afin qu'elle corresponde à la source pour des besoins de performances similaires. Accordez une attention particulière à la taille et au débit du disque, aux IOPS et au nombre de processeurs virtuels. Une taille incorrecte peut entraîner de longs délais de migration, des problèmes de performances de la base de données, des erreurs de base de données et des problèmes de performances de l'application.

Vous devez confirmer les propriétés et les exigences suivantes avant de créer vos instances Cloud SQL, car elles ne pourront pas être modifiées ultérieurement sans les recréer.

  • Choisissez avec soin le projet et la région de vos instances Cloud SQL cibles. Vous ne pouvez pas migrer des instances Cloud SQL entre des projets et des régions Google Cloud sans transfert de données.
  • Migrez vers une version majeure correspondante sur Cloud SQL. Par exemple, si votre source utilise MySQL 8.0.34 sur Amazon RDS ou Amazon Aurora, vous devez migrer vers Cloud SQL pour MySQL version 8.0.34.
  • Répliquez les informations utilisateur séparément si vous utilisez des sauvegardes du moteur de base de données intégré ou Database Migration Service. Cloud SQL gère les utilisateurs à l'aide de Google IAM. Pour en savoir plus, consultez les limites de la section Sauvegardes du moteur de base de données intégré.
  • Examinez les indicateurs de configuration du moteur de base de données et comparez leurs valeurs d'instance source et cible. Assurez-vous de comprendre leur impact et de savoir s'ils doivent être identiques ou non. Par exemple, nous vous recommandons d'exécuter la commande SHOW VARIABLES sur votre base de données source avant la migration, puis de l'exécuter à nouveau sur la base de données Cloud SQL. Mettez à jour les paramètres d'indicateur si nécessaire dans la base de données Cloud SQL pour répliquer les paramètres source. Notez que toutes les options MySQL ne sont pas autorisées sur une instance Cloud SQL.

Pour en savoir plus sur la configuration de Cloud SQL, consultez les ressources suivantes:

Configuration spécifique à la migration

Si vous importez des fichiers de vidage SQL dans Cloud SQL, vous devrez peut-être créer un bucket Cloud Storage. Le bucket stocke le dump de la base de données.

Si vous utilisez la réplication, vous devez vous assurer que l'instance dupliquée Cloud SQL a accès à votre base de données principale. Cet accès peut être obtenu via les options de connectivité documentées.

Selon votre scénario et la criticité, vous devrez peut-être implémenter un scénario de remplacement, qui implique généralement d'inverser la direction de la réplication. Dans ce cas, vous devrez peut-être utiliser un mécanisme de réplication supplémentaire de Cloud SQL vers votre instance Amazon source.

Pour la plupart des outils tiers, vous devez provisionner des ressources spécifiques à la migration. Par exemple, pour Striim, vous devez utiliser Google Cloud Marketplace pour commencer. Pour configurer votre environnement de migration dans Striim, vous pouvez utiliser Flow Designer pour créer et modifier des applications, ou sélectionner un modèle préexistant. Les applications peuvent également être codées à l'aide du langage de programmation Tungsten Query Language (TQL). Un tableau de bord de validation des données vous permet d'obtenir une représentation visuelle des données gérées par votre application Striim.

Vous pouvez mettre hors service les ressources qui connectent votre environnement Amazon et Google Cloud une fois la migration terminée et validée.

Pour en savoir plus, consultez les ressources suivantes :

Définir les tâches d'exécution

Les tâches d'exécution implémentent le travail de migration lui-même. Les tâches dépendent de l'outil de migration que vous avez choisi, comme décrit dans les sous-sections suivantes.

Sauvegardes du moteur de base de données intégrées

Pour effectuer une migration ponctuelle, utilisez l'utilitaire mysqldump pour créer une sauvegarde, qui copie les données d'Amazon RDS sur votre ordinateur client local. Pour obtenir des instructions, consultez la section Importer un fichier de dump SQL dans Cloud SQL pour MySQL.

Vous pouvez vérifier l'état des opérations d'importation et d'exportation pour votre instance Cloud SQL.

Tâches de migration de Database Migration Service

Définissez et configurez des jobs de migration dans Database Migration Service pour migrer des données d'une instance source vers la base de données de destination. Les tâches de migration se connectent à l'instance de base de données source via des profils de connexion définis par l'utilisateur.

Testez toutes les conditions préalables pour vous assurer que la tâche peut s'exécuter correctement. Choisissez un moment où vos charges de travail peuvent supporter un temps d'arrêt limité pour la migration et le passage en production.

Dans Database Migration Service, la migration commence par la sauvegarde et le chargement complets initiaux, suivis d'un flux continu de modifications de la source vers l'instance de base de données de destination.

Database Migration Service nécessite quelques secondes pour obtenir le verrouillage en lecture de toutes les tables de votre instance Amazon RDS ou Amazon Aurora source dont il a besoin pour effectuer le vidage complet initial de manière cohérente. Pour obtenir le verrouillage en lecture, un temps d'arrêt d'écriture compris entre 1 et 49 secondes peut être nécessaire. Les temps d'arrêt dépendent du nombre de tables de votre base de données, 1 seconde correspondant à 100 tables et 9 secondes à 10 000 tables.

Le processus de migration avec Database Migration Service se termine par l'opération de promotion. La promotion d'une instance de base de données interrompt la connexion de la base de données de destination au flux de modifications provenant de la base de données source. L'instance de destination, désormais autonome, est ensuite promue en instance principale. Cette approche est parfois appelée "switch de production".

Pour en savoir plus sur les tâches de migration dans Database Migration Service, consultez les ressources suivantes:

Pour découvrir le processus de configuration de la migration, consultez la page Migrer une base de données vers Cloud SQL pour MySQL à l'aide de Database Migration Service. Dans Database Migration Service, la migration est effectuée en démarrant et en exécutant une tâche de migration.

Réplication intégrée du moteur de base de données

Vous pouvez utiliser la réplication intégrée d'Amazon RDS vers une instance Cloud SQL pour MySQL externe.

Pour MySQL, vous devez d'abord commencer par un vidage initial pouvant être stocké dans un bucket Cloud Storage, puis importer les données dans Cloud SQL pour MySQL. Vous pouvez ensuite démarrer le processus de réplication.

Surveillez la réplication et arrêtez les écritures sur votre instance source au moment opportun. Vérifiez à nouveau l'état de la réplication pour vous assurer que toutes les modifications ont été répliquées, puis promouvez le réplicat Cloud SQL pour MySQL en instance autonome pour terminer la migration.

Pour obtenir des instructions détaillées sur la configuration de la réplication intégrée à partir d'un serveur externe tel qu'Amazon RDS ou Amazon Aurora pour MySQL, consultez les pages À propos de la réplication à partir d'un serveur externe et Configurer Cloud SQL et le serveur externe pour la réplication.

Pour en savoir plus et obtenir des conseils, consultez les ressources suivantes:

Outils tiers

Définissez les tâches d'exécution pour l'outil tiers que vous avez choisi.

Cette section se concentre sur Striim. Striim utilise des applications qui acquièrent des données à partir de diverses sources, les traitent, puis les transmettent à d'autres applications ou cibles.

Les applications peuvent être créées graphiquement à l'aide du client Web. Elles contiennent des sources, des cibles et d'autres composants logiques organisés en un ou plusieurs flux.

Pour configurer votre environnement de migration dans Striim, vous pouvez utiliser la fonctionnalité Flow Designer pour créer et modifier des applications, ou choisir parmi un certain nombre de modèles préexistants. Les applications peuvent également être codées à l'aide du langage de programmation TQL.

Vous pouvez obtenir une représentation visuelle des données gérées par votre application Striim à l'aide d'un tableau de bord de validation des données.

Pour commencer à utiliser Striim dans Google Cloud rapidement, consultez la page Exécuter Striim dans Google Cloud. Pour en savoir plus sur les concepts de base de Striim, consultez la section Concepts de Striim. Veillez également à lire le guide des bonnes pratiques pour passer d'un chargement initial à une réplication continue.

Tenez compte des bonnes pratiques suivantes pour votre migration de données:

  • Informez les équipes impliquées chaque fois que l'une des étapes du plan commence et se termine.
  • Si l'une des étapes prend plus de temps que prévu, comparez le temps écoulé au temps maximal alloué à chaque étape. Dans ce cas, transmettez régulièrement des informations intermédiaires aux équipes concernées.
  • Si la période est supérieure à la durée maximale réservée à chaque étape du plan, envisagez de revenir en arrière.
  • Prenez des décisions "go or no-go" pour chaque étape du plan de migration et de basculement.
  • Envisagez des actions de rollback ou des scénarios alternatifs pour chacune des étapes.

Définir des scénarios de remplacement

Définissez des actions de remplacement pour chaque tâche d'exécution de la migration afin de vous protéger contre les problèmes imprévus pouvant survenir au cours du processus de migration. Les tâches de remplacement dépendent généralement de la stratégie de migration et des outils utilisés.

Le remplacement peut nécessiter un effort considérable. Nous vous recommandons de ne pas passer en production tant que les résultats de vos tests ne sont pas satisfaisants. La migration de la base de données et le scénario de remplacement doivent être correctement testés pour éviter une panne grave.

Définissez des critères de réussite et définissez des délais pour toutes vos tâches d'exécution de la migration. Effectuer un essai de migration permet de recueillir des informations sur les délais attendus pour chaque tâche. Par exemple, pour une migration de maintenance planifiée, vous pouvez vous permettre le temps d'arrêt représenté par l'intervalle de basculement. Toutefois, il est important de planifier votre prochaine action au cas où la tâche de migration ponctuelle ou la restauration de la sauvegarde échouerait à mi-chemin. Selon le temps écoulé depuis le début de l'arrêt planifié, vous devrez peut-être reporter la migration si la tâche de migration ne se termine pas dans le délai prévu.

Un plan de secours fait généralement référence à la réinitialisation de la migration après le passage en production, si des problèmes surviennent sur l'instance cible. Si vous implémentez un plan de remplacement, n'oubliez pas qu'il doit être traité comme une migration complète de la base de données, y compris la planification et les tests.

Si vous choisissez de ne pas avoir de plan de secours, assurez-vous de bien comprendre les conséquences possibles. L'absence de plan de remplacement peut entraîner des efforts imprévus et des perturbations évitables dans votre processus de migration.

Bien qu'un remplacement soit une opération à effectuer en dernier recours et que la plupart des migrations de bases de données ne l'utilisent pas, nous vous recommandons de toujours avoir une stratégie de remplacement.

Solution de remplacement simple

Dans cette stratégie de remplacement, vous rebasculez vos applications vers l'instance de base de données source d'origine. Adoptez cette stratégie si vous pouvez vous permettre des temps d'arrêt en cas de bascule ou si vous n'avez pas besoin que les transactions soient validées sur le nouveau système cible.

Si vous avez besoin de toutes les données écrites dans votre base de données cible et que vous pouvez vous permettre un temps d'arrêt, vous pouvez envisager d'arrêter les écritures dans votre instance de base de données cible, de créer des sauvegardes intégrées et de les restaurer sur votre instance source, puis de reconnecter vos applications à l'instance de base de données source initiale. En fonction de la nature de votre charge de travail et de la quantité de données écrites sur l'instance de base de données cible, vous pouvez l'importer dans votre système de base de données source initial ultérieurement, en particulier si vos charges de travail ne dépendent pas d'une heure de création d'enregistrement spécifique ni de contraintes d'ordonnancement temporel.

Réplication inverse

Dans cette stratégie, vous répliquez les écritures qui se produisent sur votre nouvelle base de données cible après le passage en production vers votre base de données source initiale. De cette façon, vous synchronisez la source d'origine avec la nouvelle base de données cible et les écritures sont effectuées sur la nouvelle instance de base de données cible. Son principal inconvénient est que vous ne pouvez pas tester le flux de réplication avant d'avoir effectué la transition vers l'instance de base de données cible. Il n'est donc pas possible de procéder à des tests de bout en bout, et il existe une courte période sans reprise.

Choisissez cette approche lorsque vous pouvez conserver votre instance source pendant un certain temps et que vous effectuez la migration à l'aide de la migration de réplication continue.

Transfert de la réplication

Cette stratégie est une variante de la réplication inverse. Vous répliquez les écritures sur votre nouvelle base de données cible dans une troisième instance de base de données de votre choix. Vous pouvez diriger vos applications vers cette troisième base de données, qui se connecte au serveur et exécute des requêtes en lecture seule lorsque le serveur est indisponible. Vous pouvez utiliser n'importe quel mécanisme de réplication, en fonction de vos besoins. L'avantage de cette approche est qu'elle peut être entièrement testée de bout en bout.

Adoptez cette approche lorsque vous souhaitez être couvert par un plan de secours en permanence ou lorsque vous devez supprimer votre base de données source initiale peu de temps après le passage en production.

Dupliquer les écritures

Si vous choisissez une stratégie de migration de microservice d'accès aux données ou Y (écriture et lecture), ce plan de remplacement est déjà défini. Cette stratégie est plus complexe, car vous devez refactoriser des applications ou développer des outils qui se connectent à vos instances de base de données.

Vos applications écrivent à la fois dans les instances de base de données source et cible initiales, ce qui vous permet d'effectuer une transition progressive vers la production jusqu'à ce que vous n'utilisiez plus que vos instances de base de données cible. En cas de problème, vous reconnectez vos applications à la source initiale sans temps d'arrêt. Vous pouvez supprimer la source initiale et le mécanisme d'écriture en double lorsque vous considérez que la migration a été effectuée sans problème.

Nous vous recommandons cette approche lorsque vous devez absolument éviter tout temps d'arrêt lié à la migration, que vous disposez d'un plan de secours fiable et que vous avez le temps et les ressources nécessaires pour effectuer le refactoring de l'application.

Effectuer des tests et des validations

Les objectifs de cette étape sont de tester et de valider les éléments suivants:

  • Migration réussie des données dans la base de données.
  • Intégration aux applications existantes après leur passage à la nouvelle instance cible.

Définissez les principaux facteurs de réussite, qui sont propres à votre migration. Voici des exemples de facteurs subjectifs:

  • Les données à migrer. Pour certaines charges de travail, il n'est pas nécessaire de migrer toutes les données. Vous ne souhaitez peut-être pas migrer les données déjà agrégées, redondantes, archivées ou obsolètes. Vous pouvez archiver ces données dans un bucket Cloud Storage, à titre de sauvegarde.
  • Un pourcentage acceptable de perte de données. Cela s'applique particulièrement aux données utilisées pour les charges de travail d'analyse, où la perte d'une partie des données n'affecte pas les tendances générales ni les performances de vos charges de travail.
  • Critères de qualité et de quantité des données, que vous pouvez appliquer à votre environnement source et comparer à l'environnement cible après la migration.
  • Critères de performances Certaines transactions commerciales peuvent être plus lentes dans l'environnement cible, mais le temps de traitement reste dans les attentes définies.

Les configurations de stockage de votre environnement source ne correspondent peut-être pas directement aux cibles d'environnement Google Cloud. Par exemple, les configurations des volumes SSD à usage général (gp2 et gp3) avec des performances d'IOPS en utilisation intensive ou les SSD IOPS provisionnés. Pour comparer et dimensionner correctement les instances cibles, effectuez des benchmarks sur vos instances sources, à la fois lors des phases d'évaluation et de validation.

Dans le processus de benchmarking, vous appliquez des séquences d'opérations semblables à celles de la production aux instances de base de données. Pendant cette période, vous capturez et traitez des métriques pour mesurer et comparer les performances relatives des systèmes source et cible.

Pour les configurations classiques basées sur des serveurs, utilisez les mesures pertinentes observées lors des pics de charge. Pour les modèles de capacité de ressources flexibles tels qu'Aurora Serverless, envisagez d'examiner les données historiques des métriques pour observer vos besoins d'ajustement.

Les outils suivants peuvent être utilisés pour les tests, la validation et le benchmark des bases de données:

  • HammerDB : outil Open Source de benchmarking et de test de charge de base de données. Il prend en charge des charges de travail transactionnelles et analytiques complexes, basées sur les normes du secteur, sur plusieurs moteurs de base de données (TPROC-C et TPROC-H). HammerDB dispose d'une documentation détaillée et d'une large communauté d'utilisateurs. Vous pouvez partager et comparer les résultats entre plusieurs moteurs de base de données et configurations de stockage. Pour en savoir plus, consultez les pages Tests de charge SQL Server avec HammerDB et Benchmark des performances Amazon RDS SQL Server avec HammerDB.
  • Outil de benchmark DBT2 : outil de benchmark spécialisé pour MySQL. Un ensemble de kits de charge de travail de base de données imite une application pour une entreprise qui possède des entrepôts et implique un mélange de transactions de lecture et d'écriture. Utilisez cet outil si vous souhaitez utiliser un test de charge de traitement transactionnel en ligne (OLTP) prêt à l'emploi.
  • DbUnit : outil de test unitaire Open Source utilisé pour tester les interactions de base de données relationnelle en Java. La configuration et l'utilisation sont simples, et il est compatible avec plusieurs moteurs de base de données (MySQL, PostgreSQL, SQL Server, etc.). Toutefois, l'exécution des tests peut parfois être lente, en fonction de la taille et de la complexité de la base de données. Nous vous recommandons cet outil lorsque la simplicité est importante.
  • DbFit : framework de test de base de données Open Source compatible avec le développement de code basé sur les tests et les tests automatisés. Il utilise une syntaxe de base pour créer des cas de test et propose des tests basés sur les données, un contrôle des versions et des rapports sur les résultats des tests. Cependant, la prise en charge des requêtes et des transactions complexes est limitée, et il n'est pas soutenu par une grande communauté ni ne dispose d'une documentation complète, par rapport aux autres outils. Nous vous recommandons cet outil si vos requêtes ne sont pas complexes et que vous souhaitez effectuer des tests automatisés et les intégrer à votre processus d'intégration et de livraison continue.

Pour exécuter un test de bout en bout, y compris le test du plan de migration, effectuez toujours un exercice de simulation de migration. Une simulation effectue la migration de la base de données dans son intégralité sans changer de charges de travail de production. Elle offre les avantages suivants:

  • Vous permet de vous assurer que tous les objets et configurations sont correctement migrés.
  • Vous aide à définir et à exécuter vos scénarios de test de migration.
  • Fournit des informations sur le temps nécessaire pour la migration réelle afin que vous puissiez calibrer votre calendrier.
  • Représente une occasion de tester, valider et adapter le plan de migration. Parfois, vous ne pouvez pas tout planifier à l'avance. Cela vous aide donc à repérer les lacunes.

Les tests de données peuvent être effectués sur un petit ensemble de bases de données à migrer ou sur l'ensemble complet. En fonction du nombre total de bases de données et des outils utilisés pour implémenter leur migration, vous pouvez décider d'adopter une approche basée sur les risques. Avec cette approche, vous effectuez une validation des données sur un sous-ensemble de bases de données migrées via le même outil, en particulier s'il s'agit d'un service de migration géré.

Pour les tests, vous devez avoir accès aux bases de données source et cible, et effectuer les tâches suivantes:

  • Comparez les schémas source et cible. Vérifiez si toutes les tables et les exécutables existent. Vérifiez le nombre de lignes et comparez les données au niveau de la base de données.
  • Exécutez des scripts de validation de données personnalisés
  • Vérifiez que les données migrées sont également visibles dans les applications qui sont passées à la base de données cible (les données migrées sont lues via l'application).
  • Effectuez des tests d'intégration entre les applications commutées et la base de données cible en testant différents cas d'utilisation. Ces tests incluent la lecture et l'écriture de données dans les bases de données cibles via les applications afin que les charges de travail soient entièrement compatibles avec les données migrées et les données nouvellement créées.
  • Testez les performances des requêtes de base de données les plus utilisées pour voir s'il y a une dégradation en raison de mauvaises configurations ou d'une mauvaise dimensionnement.

Idéalement, tous ces scénarios de test de migration sont automatisés et reproductibles sur n'importe quel système source. La suite de scénarios de test automatisés est adaptée pour être exécutée sur les applications commutées.

Si vous utilisez Database Migration Service comme outil de migration, consultez la section Valider une migration.

Outil de validation des données

Pour effectuer la validation des données, nous vous recommandons d'utiliser l'outil de validation des données (DVT, Data Validation Tool). La DVT est un outil de CLI Python Open Source, soutenu par Google, qui fournit une solution automatisée et reproductible pour la validation dans différents environnements.

L'outil de validation des données peut vous aider à simplifier le processus de validation des données en proposant des fonctions de validation personnalisées à plusieurs niveaux pour comparer les tables source et cible au niveau des tables, des colonnes et des lignes. Vous pouvez également ajouter des règles de validation.

DVT couvre de nombreuses sources de données Google Cloud, y compris AlloyDB pour PostgreSQL, BigQuery, Cloud SQL, Spanner, JSON et les fichiers CSV sur Cloud Storage. Il peut également être intégré à Cloud Run Functions et à Cloud Run pour le déclenchement et l'orchestration basés sur des événements.

DVT accepte les types de validation suivants :

  • Comparaisons au niveau du schéma
  • Colonne (y compris "MOYENNE", "NB.", "SOMME", "MIN", "MAX", "GROUP BY" et "STRING_AGG")
  • Ligne (y compris le hachage et la correspondance exacte dans les comparaisons de champs)
  • Comparaison des résultats de requêtes personnalisées

Pour en savoir plus sur la validation des données, consultez le dépôt Git et La validation des données simplifiée avec l'outil de validation des données de Google Cloud.

Effectuer la migration

Les tâches de migration incluent les activités permettant le transfert d'un système à un autre.

Tenez compte des bonnes pratiques suivantes pour votre migration de données:

  • Informez les équipes concernées chaque fois qu'une étape du plan commence et se termine.
  • Si l'une des étapes prend plus de temps que prévu, comparez le temps écoulé au temps maximal alloué à cette étape. Dans ce cas, transmettez régulièrement des informations intermédiaires aux équipes concernées.
  • Si la période est supérieure à la durée maximale réservée à chaque étape du plan, envisagez de revenir en arrière.
  • Prenez des décisions "go or no-go" pour chaque étape du plan de migration et de basculement.
  • Envisagez des actions de rollback ou des scénarios alternatifs pour chacune des étapes.

Effectuez la migration en suivant les tâches d'exécution définies, puis consultez la documentation de l'outil de migration que vous avez sélectionné.

Effectuer le basculement en production

La procédure de passage à la production à un niveau élevé peut varier en fonction de la stratégie de migration choisie. Si vous pouvez accepter un temps d'arrêt sur vos charges de travail, la transition de la migration commence par arrêter les écritures dans votre base de données source.

Pour les migrations de réplication continue, vous procédez généralement comme suit dans le processus de basculement:

  • Arrêtez toute écriture de données dans la base de données source.
  • Videz la source.
  • Arrêtez le processus de réplication.
  • Déployez les applications qui pointent vers la nouvelle base de données cible.

Une fois les données migrées à l'aide de l'outil de migration choisi, vous les validez dans la base de données cible. Vous confirmez que la base de données source et les bases de données cibles sont synchronisées et que les données de l'instance cible respectent les critères de réussite de la migration que vous avez choisis.

Une fois la validation des données conforme à vos critères, vous pouvez effectuer le basculement au niveau de l'application. Déployez les charges de travail qui ont été refactorisées pour utiliser la nouvelle instance cible. Vous déployez les versions de vos applications qui pointent vers la nouvelle instance de base de données cible. Les déploiements peuvent être effectués par le biais de mises à jour progressives, de versions par étapes ou à l'aide d'un modèle de déploiement bleu-vert. Un temps d'arrêt de l'application peut être nécessaire.

Suivez les bonnes pratiques pour votre passage en production:

  • Surveillez vos applications qui fonctionnent avec la base de données cible après le passage.
  • Définissez une période de surveillance pour déterminer si vous devez implémenter votre plan de remplacement ou non.
  • Notez que votre instance Cloud SQL ou AlloyDB pour PostgreSQL peut nécessiter un redémarrage si vous modifiez certains indicateurs de base de données.
  • Sachez que l'effort d'inversion de la migration peut être plus important que la résolution des problèmes qui apparaissent dans l'environnement cible.

Nettoyer l'environnement source et configurer l'instance Cloud SQL ou AlloyDB pour PostgreSQL

Une fois la transition terminée, vous pouvez supprimer les bases de données sources. Nous vous recommandons d'effectuer les actions importantes suivantes avant le nettoyage de votre instance source:

  • Créez une sauvegarde finale de chaque base de données source. Ces sauvegardes vous fournissent l'état final des bases de données sources. Dans certains cas, les sauvegardes peuvent également être requises pour respecter certaines réglementations sur les données.

  • Collectez les paramètres de paramètre de base de données de votre instance source. Vérifiez également qu'ils correspondent à ceux que vous avez recueillis lors de la phase de création de l'inventaire. Ajustez les paramètres de l'instance cible pour qu'ils correspondent à ceux de l'instance source.

  • Collectez les statistiques de la base de données de l'instance source et comparez-les à celles de l'instance cible. Si les statistiques sont disparates, il est difficile de comparer les performances de l'instance source et de l'instance cible.

Dans un scénario de remplacement, vous pouvez implémenter la réplication de vos écritures sur l'instance Cloud SQL vers votre base de données source d'origine. La configuration ressemble au processus de migration, mais s'exécute à l'inverse: la base de données source initiale devient la nouvelle cible.

Il est recommandé de répliquer les écritures effectuées sur les instances Cloud SQL cibles vers la base de données source pour maintenir les instances sources à jour après la transition. Si vous devez effectuer un rollback, vous pouvez revenir à vos anciennes instances sources avec une perte de données minimale.

En plus du nettoyage de l'environnement source, vous devez effectuer les configurations critiques suivantes pour vos instances Cloud SQL:

  • Configurez un intervalle de maintenance permettant à votre instance principale de contrôler à quel moment des mises à jour perturbatrices peuvent se produire.
  • Configurez l'espace de stockage sur l'instance afin de disposer d'au moins 20 % d'espace disponible pour prendre en charge toutes les opérations de maintenance de base de données critiques que Cloud SQL peut effectuer. Pour recevoir une alerte si l'espace disque disponible est inférieur à 20%, créez une règle d'alerte basée sur les métriques pour la métrique d'utilisation du disque.

Ne démarrez pas une opération administrative avant la fin de l'opération précédente.

Pour en savoir plus sur la maintenance et les bonnes pratiques, consultez la page À propos de la maintenance des instances Cloud SQL.

Optimiser votre environnement après la migration

L'optimisation est la dernière phase de votre migration. Au cours de cette phase, vous effectuez des itérations sur les tâches d'optimisation jusqu'à ce que votre environnement réponde à vos exigences d'optimisation. Les étapes de chaque itération sont les suivantes :

  1. Évaluer votre environnement actuel, vos équipes et votre boucle d'optimisation
  2. Définir vos exigences et vos objectifs d'optimisation
  3. Optimiser votre environnement et vos équipes
  4. Ajuster la boucle d'optimisation

Vous devez répéter cette séquence jusqu'à ce que vous ayez atteint vos objectifs d'optimisation.

Pour en savoir plus sur l'optimisation de votre environnement Google Cloud, consultez les pages Migrer vers Google Cloud : optimiser votre environnement et Processus d'optimisation des performances.

Définir vos exigences d'optimisation

Examinez les exigences d'optimisation suivantes pour votre environnement Google Cloud et choisissez celles qui correspondent le mieux à vos charges de travail:

Améliorer la fiabilité et la disponibilité de votre base de données

Avec Cloud SQL, vous pouvez mettre en œuvre une stratégie de reprise après sinistre à haute disponibilité et conforme à vos objectifs en termes de temps de récupération (RTO) et de point de récupération (RPO). Pour améliorer la fiabilité et la disponibilité, tenez compte des points suivants:

  • Pour les charges de travail lourdes en lecture, ajoutez des instances répliquées avec accès en lecture pour décharger le trafic de l'instance principale.
  • Pour les charges de travail critiques, utilisez la configuration à haute disponibilité, les instances dupliquées pour le basculement régional et une configuration de reprise après sinistre robuste.
  • Pour les charges de travail moins critiques, des sauvegardes automatiques et à la demande peuvent suffire.
  • Pour éviter la suppression accidentelle d'instances, utilisez la protection contre la suppression d'instances.
  • Envisagez d'utiliser l'édition Cloud SQL Enterprise Plus pour bénéficier d'une disponibilité, d'une conservation des journaux et d'une maintenance planifiée avec un temps d'arrêt quasi nul accrus. Pour en savoir plus sur Cloud SQL Enterprise Plus, consultez les pages Présentation des éditions Cloud SQL et Maintenance planifiée avec un temps d'arrêt quasi nul.

Pour en savoir plus sur l'amélioration de la fiabilité et de la disponibilité de votre base de données, consultez les ressources suivantes:

Améliorer l'efficacité de votre infrastructure de base de données

Pour avoir un impact économique positif, vos charges de travail doivent utiliser efficacement les ressources et les services disponibles. Vous avez le choix entre les options suivantes :

  • Fournissez à la base de données la capacité de stockage minimale requise en procédant comme suit:

    • Pour faire évoluer automatiquement la capacité de stockage à mesure que la quantité de données augmente, activez l'augmentation automatique de l'espace de stockage. Toutefois, assurez-vous de configurer vos instances pour qu'elles disposent d'une certaine mémoire tampon en cas de pics de charge de travail. N'oubliez pas que les charges de travail de base de données ont tendance à augmenter avec le temps.

  • Identifiez les ressources surestimées possibles:

    • Adapter la taille de vos instances Cloud SQL peut réduire les coûts d'infrastructure sans ajouter de risques supplémentaires à la stratégie de gestion de la capacité.
    • Cloud Monitoring fournit des tableaux de bord prédéfinis qui permettent d'identifier l'état et l'utilisation de la capacité de nombreux composants Google Cloud, y compris Cloud SQL. Pour en savoir plus, consultez la section Créer et gérer des tableaux de bord personnalisés.

  • Identifiez les instances qui ne nécessitent pas de configuration de haute disponibilité ni de reprise après sinistre, puis supprimez-les de votre infrastructure.

  • Supprimez les tables et les objets dont vous n'avez plus besoin. Vous pouvez les stocker dans une sauvegarde complète ou dans un bucket Cloud Storage d'archivage.

  • Évaluez le type de stockage le plus économique (SSD ou HDD) pour votre cas d'utilisation.

    • Dans la plupart des cas, le SSD est le choix le plus efficace et le plus rentable.
    • Si vos ensembles de données sont volumineux (10 To ou plus), non sensibles à la latence ou rarement utilisés, un disque dur peut être plus approprié.
    • Pour en savoir plus, consultez la section Choisir entre le stockage SSD et HDD.

  • Souscrivez des remises sur engagement d'utilisation pour les charges de travail ayant des besoins en ressources prévisibles.

  • Utilisez Active Assist pour obtenir des insights et des recommandations sur les coûts.

    Pour en savoir plus et découvrir d'autres options, consultez la page Réduisez vos coûts tout en faisant plus : découvrez les recommandations d'optimisation des coûts Cloud SQL avec Active Assist.

Améliorer les performances de votre infrastructure de base de données

Les problèmes de performances mineurs liés à la base de données peuvent souvent avoir un impact sur l'ensemble de l'opération. Pour maintenir et améliorer les performances de votre instance Cloud SQL, suivez les consignes suivantes:

  • Si vous avez un grand nombre de tables de base de données, cela peut affecter les performances et la disponibilité de l'instance, et entraîner la perte de sa couverture par le contrat de niveau de service.

  • Assurez-vous que l'instance n'est pas limitée en termes de mémoire ou de processeur.

    • Pour les charges de travail exigeantes en performances, assurez-vous que votre instance dispose d'au moins 60 Go de mémoire.
    • Si vous rencontrez une latence pendant l'insertion, la mise à jour ou la suppression de bases de données, vérifiez les emplacements du rédacteur et de la base de données. L'envoi de données sur une longue distance entraîne généralement une latence.

  • Améliorez les performances des requêtes à l'aide du tableau de bord "Insights sur les requêtes" prédéfini dans Cloud Monitoring (ou des fonctionnalités intégrées similaires du moteur de base de données). Identifiez les commandes les plus coûteuses et essayez de les optimiser.

  • Empêchez les fichiers de base de données d'être excessivement volumineux. Définissez autogrow en Mo plutôt que sous forme de pourcentage, en utilisant des incréments adaptés à l'exigence.

  • Vérifiez l'emplacement du lecteur et celui de la base de données. La latence affecte davantage les performances de lecture que les performances d'écriture.

  • Envisagez d'utiliser l'édition Cloud SQL Enterprise Plus pour profiter d'un cache de données et de limites de configuration de machine plus élevés. Pour en savoir plus, consultez la page Présentation des éditions Cloud SQL.

Pour en savoir plus sur l'amélioration des performances, consultez la section Performances dans "Diagnostiquer les problèmes".

Améliorer les fonctionnalités d'observabilité des bases de données

Le diagnostic et le dépannage des problèmes dans les applications qui se connectent à des instances de base de données peuvent s'avérer difficiles et chronophages. C'est pourquoi il est essentiel de disposer d'un espace centralisé où tous les membres de l'équipe peuvent voir ce qui se passe au niveau de la base de données et des instances. Vous pouvez surveiller les instances Cloud SQL de différentes manières:

  • Cloud SQL utilise des agents personnalisés à mémoire intégrée pour collecter la télémétrie des requêtes.

    • Utilisez Cloud Monitoring pour collecter des mesures de votre service et des ressources Google Cloud que vous utilisez. Cloud Monitoring inclut des tableaux de bord prédéfinis pour plusieurs produits Google Cloud, y compris un tableau de bord de surveillance Cloud SQL.
    • Vous pouvez créer des tableaux de bord personnalisés qui vous aident à surveiller les métriques et à configurer des règles d'alerte afin de recevoir des notifications en temps opportun.
    • Vous pouvez également envisager d'utiliser des solutions de surveillance tierces intégrées à Google Cloud, telles que Datadog et Splunk.

  • Cloud Logging collecte les données de journalisation à partir des composants d'application courants.

  • Cloud Trace collecte les données de latence et les plans de requête exécutés à partir d'applications pour vous aider à suivre la propagation des requêtes dans votre application.

  • Database Center fournit une vue d'ensemble centralisée et assistée par IA de votre parc de bases de données. Vous pouvez surveiller l'état de vos bases de données, la configuration de la disponibilité, la protection des données, la sécurité et la conformité aux normes du secteur.

Bonnes pratiques générales et consignes opérationnelles concernant Cloud SQL

Appliquez les bonnes pratiques pour Cloud SQL afin de configurer et d'optimiser la base de données.

Voici quelques recommandations générales importantes concernant Cloud SQL:

  • Si vous avez des instances volumineuses, nous vous recommandons de les scinder en instances plus petites, dans la mesure du possible.
  • Configurez l'espace de stockage pour tenir compte de la maintenance critique des bases de données. Assurez-vous de disposer d'au moins 20% d'espace disponible pour prendre en charge toutes les opérations de maintenance de base de données critiques que Cloud SQL peut effectuer.
  • Un trop grand nombre de tables de base de données peut avoir un impact sur le délai de mise à niveau de la base de données. Dans l'idéal, visez moins de 10 000 tables par instance.
  • Choisissez la taille appropriée pour vos instances afin de prendre en compte la conservation des journaux de transactions (binaires), en particulier pour les instances à forte activité d'écriture.

Pour pouvoir gérer efficacement les problèmes de performances de la base de données que vous pourriez rencontrer, suivez les instructions suivantes jusqu'à ce que le problème soit résolu:

Évoluer l'infrastructure: augmenter les ressources (telles que le débit disque, les vCPU et la RAM). En fonction de l'urgence, de la disponibilité et de l'expérience de votre équipe, la mise à l'échelle verticale de votre instance peut résoudre la plupart des problèmes de performances. Vous pourrez ensuite examiner plus en détail l'origine du problème dans un environnement de test et envisager des solutions pour l'éliminer.

Effectuer et planifier des opérations de maintenance de la base de données: défragmentation des index, mises à jour des statistiques, analyse de l'espace vide et réindexation des tables fréquemment mises à jour. Vérifiez si et quand ces opérations de maintenance ont été effectuées pour la dernière fois, en particulier sur les objets concernés (tables, index). Déterminez si les activités de base de données ont changé. Par exemple, si vous avez récemment ajouté une colonne ou si vous avez effectué de nombreuses mises à jour dans un tableau.

Effectuez l'ajustement et l'optimisation de la base de données: les tables de votre base de données sont-elles correctement structurées ? Les colonnes présentent-elles les types de données appropriés ? Votre modèle de données est-il adapté au type de charge de travail ? Examinez vos requêtes lentes et leurs plans d'exécution. Utilisent-elles les index disponibles ? Recherchez les analyses d'index, les verrous et les temps d'attente sur d'autres ressources. Envisagez d'ajouter des index pour prendre en charge vos requêtes critiques. Supprimez les index et les clés étrangères non critiques. Envisagez de réécrire les requêtes et les jointures complexes. Le temps nécessaire pour résoudre votre problème dépend de l'expérience et de la disponibilité de votre équipe, et peut aller de quelques heures à plusieurs jours.

Évoluez vos lectures: envisagez d'utiliser des instances dupliquées avec accès en lecture. Lorsque le scaling vertical ne répond pas à vos besoins et que les mesures de réglage et d'optimisation de la base de données ne sont pas efficaces, envisagez d'utiliser le scaling horizontal. Le routage des requêtes de lecture de vos applications vers une instance répliquée de lecture améliore les performances globales de votre charge de travail de base de données. Toutefois, il peut être nécessaire de modifier vos applications pour qu'elles se connectent à l'instance répliquée de lecture.

Réarchitecture de la base de données: envisagez de partitionner et d'indexer la base de données. Cette opération nécessite beaucoup plus d'efforts que le réglage et l'optimisation de la base de données, et peut impliquer une migration de données, mais elle peut constituer une solution à long terme. Parfois, une conception médiocre du modèle de données peut entraîner des problèmes de performances, qui peuvent être partiellement compensés par un scaling vertical. Toutefois, un modèle de données approprié est une solution à long terme. Envisagez de partitionner vos tables. Archivez les données dont vous n'avez plus besoin, si possible. Normalisez la structure de votre base de données, mais n'oubliez pas que la dénormalisation peut également améliorer les performances.

Segmentation de la base de données : vous pouvez effectuer un scaling horizontal de vos écritures en segmentant votre base de données. Le sharding est une opération complexe qui implique de repenser votre base de données et vos applications de manière spécifique, et d'effectuer une migration de données. Vous divisez votre instance de base de données en plusieurs instances plus petites à l'aide de critères de partitionnement spécifiques. Les critères peuvent être basés sur le client ou le sujet. Cette option vous permet de mettre à l'échelle horizontalement vos écritures et vos lectures. Toutefois, cela augmente la complexité de vos charges de travail de base de données et d'application. Cela peut également entraîner des fragments déséquilibrés appelés "hotspots", qui l'emporteraient sur les avantages du sharding. - Plus précisément, pour Cloud SQL pour MySQL, assurez-vous que vos tables disposent d'une clé primaire ou unique. Cloud SQL utilise une réplication basée sur les lignes, qui fonctionne mieux sur les tables avec des clés primaires ou uniques.

Pour en savoir plus, consultez les bonnes pratiques générales et les consignes opérationnelles pour Cloud SQL pour MySQL.

Étape suivante

Contributeurs

Auteurs :

Autres contributeurs :