Migrer d'AWS vers Google Cloud: migrer d'Amazon RDS pour SQL Server vers Cloud SQL pour SQL Server

Last reviewed 2024-06-28 UTC

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

Ce document est destiné aux administrateurs cloud et de bases de données qui souhaitent planifier, mettre en œuvre et valider un projet de migration de bases de données. Il s'adresse également aux décisionnaires 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 où les bases de données source et de destination utilisent la même technologie de base de données. La source est Amazon RDS pour SQL Server, et la destination est Cloud SQL pour SQL Server.

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

• Commencer
• Migrer depuis Amazon EC2 vers Compute Engine
• Migrer depuis Amazon S3 vers Cloud Storage
• Migrer d'Amazon EKS vers GKE
• Migrer depuis Amazon RDS et Amazon Aurora pour MySQL vers Cloud SQL pour MySQL
• Migrer depuis Amazon RDS et Amazon Aurora pour PostgreSQL vers Cloud SQL pour PostgreSQL et AlloyDB pour PostgreSQL
• Migrer depuis Amazon RDS pour SQL Server vers Cloud SQL pour SQL Server (ce document)
• Migrer d'AWS Lambda vers Cloud Run

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

Le diagramme suivant illustre le parcours de votre migration.

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. Optimisez votre environnement Google Cloud .

Pour en savoir plus sur les phases de ce framework, consultez 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 que vous disposez d'une stratégie de rollback. Pour vous aider à valider votre plan de migration, consultez 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 la migration de votre environnement source vers Google Cloud.

Elle 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. Formez vos équipes à Google Cloud.
4. Créer des tests et des démonstrations de faisabilité sur Google Cloud
5. Calculez 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. Vous devez définir le plan de migration et le calendrier.
9. Validez votre plan de migration.

Pour en savoir plus sur la phase d'évaluation et ces tâches, consultez Migrer vers Google Cloud : évaluer et découvrir vos charges de travail. Les sections suivantes sont basées sur les informations de ce document.

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 correspond à 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 vCPU. Les migrations peuvent rencontrer des difficultés ou échouer en raison d'un dimensionnement incorrect de l'instance de base de données cible. Un dimensionnement incorrect peut entraîner des temps de migration longs, des problèmes de performances de la base de données, des erreurs de base de données et des problèmes de performances des applications. Lorsque vous choisissez l'instance Cloud SQL, n'oubliez pas que les performances du disque dépendent de sa taille et du 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

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. Idéalement, le processus doit être automatisé, car les approches manuelles sont sujettes aux erreurs et peuvent conduire à des hypothèses incorrectes.

Amazon RDS et Cloud SQL peuvent ne pas avoir les mêmes fonctionnalités, spécifications d'instance ou opérations. Certaines fonctionnalités peuvent être implémentées différemment ou ne pas être disponibles. Les 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 extensions de fonctionnalités spécifiques du moteur de base de données. Selon le type de moteur de base de données, la taille de l'instance et l'architecture, les valeurs par défaut des paramètres de base de données peuvent également varier.

L'analyse comparative peut vous aider à mieux comprendre les charges de travail à migrer et à définir l'architecture appropriée de l'environnement cible de la migration. Il est important de collecter des informations sur les performances pour estimer les besoins en performances de l'environnement cible Google Cloud . Les concepts et les 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 pour les examens

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 paysage d'applications et de bases de données, y compris l'adéquation technique d'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 un échec de la migration, et peut indiquer des solutions de contournement. migVisor peut également recommander une solution Google Cloud cible, y compris le dimensionnement et l'architecture initiaux.

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 détaillant les économies réalisées 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 d'interruption 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, processeurs et taille de la mémoire), ainsi que des détails sur la topologie de la base de données, les règles de sauvegarde, les paramètres et les personnalisations spéciales utilisées.

Si vous préférez utiliser des outils Open Source, vous pouvez utiliser des scripts de collecteur de données avec (ou à la place) des 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 la 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, et indique 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. Vous pouvez désormais 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 ? Sont-ils supérieurs à 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 pour les bases de données de destination ?
• Dans quelle mesure les bases de données source et de destination sont-elles compatibles ?
• Les données doivent-elles résider 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 besoin d'être migrées ?

Pour définir le champ d'application de la migration, déterminez les données à conserver et celles à migrer. La migration de toutes vos bases de données peut prendre beaucoup de temps et d'efforts. Certaines données peuvent rester dans les sauvegardes de votre base de données source. Par exemple, les anciennes tables de journalisation ou les données d'archive 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 références de migration de données qui vous aident à comparer et à évaluer vos résultats et vos 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 vous aident à prendre des décisions. Il est important de prendre des mesures sur l'environnement source pour vous aider à évaluer la réussite de la migration de vos données. Ces mesures incluent les éléments suivants :

• 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 des temps d'arrêt sur l'entreprise ? Existe-t-il des périodes de faible activité de la base de données, pendant lesquelles moins d'utilisateurs sont affectés par les temps d'arrêt ? Si oui, quelle est la durée de ces périodes et quand se produisent-elles ? Envisagez de n'avoir qu'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

Après avoir créé les inventaires, évaluez les processus opérationnels et de déploiement de votre base de données pour déterminer comment les adapter afin de faciliter votre migration. Ces processus sont essentiels pour préparer et gérer 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 au sein d'un VPC. Si vous prévoyez d'utiliser l'authentification Windows avec Cloud SQL pour SQL Server, vous devez déployer Microsoft AD géré et vous connecter à votre infrastructure Active Directory existante.
• Appliquez des correctifs et configurez vos instances : vos outils de déploiement existants devront peut-être être mis à jour. Par exemple, vous utilisez peut-être des paramètres de configuration personnalisés dans des groupes de paramètres Amazon 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 sources Amazon assurent l'observabilité pendant le processus de migration. Les catégories de métriques peuvent inclure Amazon CloudWatch, Performance Insights, Enhanced Monitoring et les listes de processus de l'OS.

Terminer l'évaluation

Après avoir créé les inventaires de votre environnement Amazon RDS, 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. Configurez 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 Migrer vers Google Cloud : planifier et créer vos fondations.

Surveillance et alertes

Utilisez Google Cloud Monitoring, 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, telles que Datadog et Splunk. Pour en savoir plus, consultez À propos de l'observabilité des bases de données.

Migrer des instances Amazon RDS pour SQL Server vers Cloud SQL pour SQL Server

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 définies.

3. Définissez le plan de migration et le calendrier de 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 que l'outil de migration fonctionne correctement.

5. Définissez les tâches d'exécution, qui incluent les activités de travail qui mettent en œuvre 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 réalisés dans un environnement de préproduction distinct.

8. Effectuez la migration.

9. Effectuez la transition vers la production.

10. Nettoyer l'environnement source et configurer l'instance cible.

11. Effectuer des réglages et des optimisations.

Chaque phase est décrite dans les sections suivantes :

Choisir la stratégie de migration

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

• Maintenance planifiée (également appelée migration ponctuelle ou migration big bang) : cette approche est idéale si vous pouvez vous permettre un temps d'arrêt. Cette option est relativement moins coûteuse et moins 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 en ligne ou migration progressive) : 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 répartis en plusieurs parties. Ainsi, 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. Un effort supplémentaire est également nécessaire pour refactoriser les applications qui se connectent à vos instances de base de données. Essayez l'une des variantes suivantes :

  • Utiliser 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.
  • Utiliser un microservice d'accès aux données, ce qui réduit l'effort 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 lorsque vous décidez de la stratégie de migration d'une seule base de données :

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 par 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 basculement représente le temps nécessaire pour sauvegarder la base de données, la transférer vers Cloud SQL, la restaurer, puis basculer vos applications.

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

Les stratégies peuvent varier d'une base de données à l'autre, même lorsqu'elles se trouvent sur la même instance. Une combinaison 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 règle générale, 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 permet d'éviter toute perte de données et de minimiser les temps d'arrêt.

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

Réduire les temps d'arrêt et les impacts liés à la migration

Les configurations de migration qui n'entraînent 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 planifiés pendant les heures d'ouverture à faible trafic.

Chaque stratégie de migration implique un compromis et un certain impact sur le 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 un délai avant réplication. Les applications (et les clients) peuvent devoir attendre pendant le temps d'arrêt de l'application, au moins aussi longtemps que dure 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 :

• L'exécution des requêtes de base de données peut prendre quelques secondes. Au moment de la migration, les requêtes en cours peuvent être annulées.
• 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 Cloudpeuvent présenter un léger décalage jusqu'à ce que la connexion à l'instance de base de données Google Cloudsoit établie.
• Les routes réseau vers les applications doivent être redirigées. Selon la configuration des entrées DNS, cela peut prendre un certain temps. Lorsque vous mettez à jour des enregistrements DNS, réduisez la valeur TTL avant la migration.

Les pratiques courantes suivantes peuvent vous aider à minimiser les temps d'arrêt et l'impact :

• Trouvez une période pendant laquelle 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 faire l'objet d'une migration et d'un basculement 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 de backend et les plates-formes de création de rapports. Ces modules peuvent avoir leurs propres bases de données, dont la migration peut être planifiée plus tôt ou plus tard dans le processus.
• Si vous pouvez vous permettre une certaine latence sur la base de données cible, envisagez de mettre en œuvre 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 sur l'instance cible.
• Envisagez de refactoriser vos applications pour minimiser l'impact de la migration. Par exemple, adaptez vos applications pour qu'elles écrivent à la fois dans les bases de données sources et cibles, 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 le choix du bon outil de migration. Une fois la stratégie de migration décidée, examinez et choisissez l'outil de migration.

Il existe de nombreux outils, 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 de base de données source et cible, et versions des moteurs.
• 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.
• Disponibilité des services gérés pour la migration.

Pour garantir une migration et un basculement fluides, vous pouvez utiliser des modèles de déploiement d'applications, l'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 déplacement de données, d'applications ou même d'infrastructures entières d'un environnement à un autre. Ils exécutent l'extraction de données à partir des bases de données sources, transportent les données de manière sécurisée vers les bases de données cibles et peuvent éventuellement modifier les données pendant le transit. Grâce à ces fonctionnalités, ils 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.

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

• Proposer 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ées

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.

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

Lorsqu'un temps d'arrêt important est acceptable et que vos bases de données sources sont relativement statiques, vous pouvez utiliser les fonctionnalités de sauvegarde et de restauration intégrées du 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. Cette approche convient à toutes les tailles de base de données et est généralement plus efficace que d'autres outils pour les instances volumineuses.

Les sauvegardes de moteurs 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.

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

• Pour les sauvegardes de bases de données de plus de 5 To, utilisez une sauvegarde agrégée par bandes (une sauvegarde de plusieurs fichiers).
• Lorsque vous utilisez une sauvegarde agrégée par bandes, vous ne pouvez pas sauvegarder ni restaurer plus de 10 fichiers de sauvegarde en même temps.
• Vous devez effectuer la sauvegarde dans un bucket Amazon S3 situé dans la même région Amazon que votre instance de base de données source.
• Les sauvegardes n'incluent pas les connexions, les autorisations et les rôles de serveur SQL Server, car ils sont situés au niveau de l'instance. Pour transférer ce type de données de l'instance source vers l'instance cible, utilisez des scripts PowerShell ou des outils tels que DBAtools.

Pour en savoir plus sur les limites et les bonnes pratiques, consultez Bonnes pratiques pour importer et exporter des données avec Cloud SQL pour SQL Server et Problèmes connus liés à Cloud SQL pour SQL Server.

Autres approches pour les migrations de maintenance planifiée

L'utilisation d'autres approches peut offrir plus de contrôle et de flexibilité dans votre processus de migration de maintenance planifiée.

Par exemple, en utilisant des fichiers plats pour exporter et importer vos données (ou en utilisant des scripts personnalisés), vous pouvez effectuer les opérations suivantes :

• Effectuez des transformations, des vérifications ou d'autres opérations sur vos données pendant la migration. Par exemple, des validations, une agrégation, ou une normalisation et une dénormalisation de vos données sources.
• Choisissez les structures que vous souhaitez migrer et celles que vous souhaitez laisser de côté. Vous pouvez décider d'extraire uniquement un sous-ensemble de vos tables dans des fichiers plats pour l'importation.
• Choisissez de filtrer les données en fonction du domaine, de la source, de l'âge ou d'autres critères personnalisés. Par exemple, vous pouvez exclure les données qui atteignent un seuil d'âge et les stocker dans des fichiers ou dans la sauvegarde finale de votre base de données source, avant la migration.
• Refactorisez vos structures de base de données et synchronisez le temps d'arrêt encouru avec le temps d'arrêt de la migration.
• Regroupez plusieurs instances ou bases de données dans une seule instance ou base de données pour réduire les coûts opérationnels et résoudre vos problèmes d'évolutivité. Par exemple, vous pouvez passer d'une approche basée sur une instance, une base de données ou un schéma par client à une structure de base de données unique optimisée pour l'architecture mutualisée.

Voici d'autres approches :

• Utiliser des fichiers CSV ou JSON : avec cette approche, vous extrayez les données de la base de données dans les fichiers, puis vous importez les fichiers dans vos instances cibles.

  • Bien que généralement plus lente, cette méthode vous permet de migrer un sous-ensemble de tables (ou de données d'une table donnée).
  • Les formats CSV et JSON sont compris par de nombreux outils.
  • Si vous automatisez le processus, vous pouvez passer à une migration par réplication continue par lot.

• Utilisez l'assistant d'importation et d'exportation SQL Server de Microsoft : cet outil utilise SQL Server Integration Services (SSIS) et vous permet d'importer des données à partir de différentes sources, telles que d'autres moteurs de base de données ou des fichiers plats.

• Utilisez l'assistant de génération et de publication de scripts SQL Server et l'utilitaire bcp : cet outil fait partie de Microsoft SQL Server Management Studio.

  • Cette approche vous permet de créer des scripts pour l'ensemble de votre schéma de base de données ou seulement pour certaines parties.
  • L'utilitaire bcp vous permet de créer un script pour les données et de les exporter dans des fichiers.

• Utilisez la réplication d'instantanés si votre source utilise Amazon RDS Standard :

  • Avec cette approche, vous restaurez la sauvegarde SQL Server de l'instance RDS sur une autre instance autonome de SQL Server sur Compute Engine. Ensuite, utilisez la réplication d'instantanés pour migrer vers Cloud SQL pour SQL Server.
  • La génération d'instantanés conserve les verrous sur les tables sources, ce qui peut avoir un impact sur vos charges de travail.
  • La réplication d'instantanés peut entraîner des charges supplémentaires sur votre serveur Amazon RDS.
  • Toutefois, vous pouvez choisir les objets à migrer ou à répliquer, ce qui vous offre une certaine flexibilité.
  • Pour en savoir plus, consultez Migrer des données de SQL Server 2017 vers Cloud SQL pour SQL Server à l'aide de la réplication des instantanés.

Outils pour les migrations avec 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 par réplication continue :

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

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

  • Si oui, passez à la décision suivante. Si vous pouvez vous permettre un temps d'arrêt minimal et que vous n'avez pas besoin de transformer les données ni de les synchroniser en temps réel, nous vous recommandons d'utiliser Database Migration Service. Sinon, explorez les options tierces.
  • Si ce n'est pas le cas, passez à la décision suivante. Si la réplication intégrée du moteur de base de données est compatible, nous vous recommandons de l'utiliser. Si ce n'est pas le cas, nous vous recommandons d'explorer d'autres options de migration.

• Pouvez-vous vous permettre un temps d'arrêt minimal et migrer sans transformation de données ni synchronisation en temps réel ?

  • Si la réponse est oui, nous vous recommandons d'utiliser Database Migration Service.
  • Si ce n'est pas le cas, explorez les options tierces.

• La réplication intégrée spécifique au moteur de base de données est-elle compatible ?

  • Si oui, 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 par réplication continue, ainsi que leurs limites et les bonnes pratiques associées.

Database Migration Service pour la migration avec réplication continue

Database Migration Service est compatible avec les migrations homogènes vers Cloud SQL pour SQL Server, lorsque la source est Amazon RDS.

Database Migration Service est un outil économique et simple d'utilisation. Nous vous recommandons d'utiliser Database Migration Service dans les cas suivants :

• Vous pouvez vous permettre un temps d'arrêt minimal.
• Vous n'avez pas besoin d'une synchronisation en temps réel.
• Vous n'avez pas besoin d'effectuer de transformations de données pendant la migration.

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

• Le temps d'arrêt dépend de la fréquence de vos sauvegardes de journaux de transactions.
• Les sauvegardes n'incluent pas les connexions, les autorisations ni les rôles de serveur SQL Server, car ils se trouvent au niveau de l'instance. Écrivez-les à partir de l'instance source, puis transférez-les vers l'instance cible à l'aide de scripts PowerShell ou d'outils tels que DBAtools.

Pour obtenir la liste complète des limites, consultez Limites connues.

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

Cloud SQL est compatible avec la réplication pour SQL Server. Toutefois, Amazon RDS pour SQL Server Standard ne peut être qu'un abonné. La réplication intégrée depuis Amazon RDS Standard n'est pas disponible. Seul Amazon RDS Custom pour SQL Server peut être configuré en tant que serveur de publication intégré.

Pour obtenir la liste des fonctionnalités compatibles et non compatibles sur Amazon RDS, consultez Amazon RDS pour Microsoft SQL Server.

Autres approches pour la migration par réplication continue

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

• Refactorisez vos applications pour effectuer une écriture et une lecture en Y 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 la refactorisation ou le développement d'outils qui se connectent à vos instances de base de données.
  • Les applications de lecture sont ensuite progressivement refactorisées et déployées pour utiliser l'instance cible.

• Implémentez des fonctions qui interrogent régulièrement les données de votre instance source, filtrent uniquement les nouvelles données et écrivent les données dans des fichiers CSV, JSON ou Parquet.

  • Ces fichiers sont stockés dans un bucket Google Cloud Storage.
  • Les fichiers peuvent être écrits immédiatement dans votre instance de base de données cible à l'aide de Cloud Run Functions.
  • Les fonctionnalités de capture des données modifiées (CDC) peuvent vous aider à réaliser une migration par réplication en temps quasi réel.
  • Vous pouvez diffuser la CDC dans un lac de données Amazon S3 au format Parquet à l'aide d'AWS Database Migration Service (AWS DMS).
  • Vous pouvez utiliser une implémentation personnalisée pour lire les fichiers et écrire leur contenu dans Cloud SQL.

Outils tiers pour les migrations par réplication continue

Dans certains cas, il peut être préférable d'utiliser un outil tiers pour la plupart des moteurs de base de données. Cela peut être le cas 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 temps quasi 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 permettant 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 de données modifiées intégrée pour SQL Server.
  • Modèles de connexion préconfigurés et pipelines sans code.
  • Capable de gérer des bases de données volumineuses et stratégiques qui fonctionnent sous une charge transactionnelle importante.
  • Diffusion de type "exactement une fois".

• Inconvénients :

  • Pas Open Source.
  • Peut devenir coûteux, en particulier pour les migrations de longue durée.
  • Certaines limites de propagation des opérations de langage de définition de données (LDD) Pour en savoir plus, consultez la section Opérations LDD compatibles et Notes et limites de l'évolution du schéma.

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 CDC, qui peut diffuser les modifications de données vers des abonnés externes :

• Avantages :

  • Open Source.
  • Assistance de la communauté solide.
  • Rentable
  • Contrôle précis des lignes, des tables ou des bases de données
  • Spécialisé dans la capture des modifications en temps réel à partir des journaux de 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é qui permet de déplacer des données depuis et vers des plates-formes de données cloud.

• Avantages :

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

• Inconvénients :

  • Il n'est pas Open Source.
  • La prise en charge de la transformation 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 basculement 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 d'une base de données, vous devrez peut-être effectuer des tâches de prémigration ou de postmigration pour mettre en œuvre 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) existant ni votre plan de continuité d'activité.

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

• Document de conception technique (TDD)
• Matrice RACI
• Chronologie (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 page Migrer vers Google Cloud : bonnes pratiques pour valider un plan de migration.

TDD

Le document de conception technique (TDD) documente toutes les décisions techniques à prendre pour le projet. Incluez les éléments suivants dans le document de conception technique :

• Exigences métier 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 base de données
• Estimations de l'effort de migration
• Recommandations pour la validation de la migration

Matrice RACI

Certains projets de migration nécessitent une matrice RACI, un document de gestion de projet courant qui définit les personnes ou les 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 à effectuer, ainsi que les dates de début définies et les dates de fin estimées.

Pour chaque environnement de migration, nous vous recommandons de créer un plan T-minus. Un plan T-minus est structuré comme un calendrier de compte à rebours et répertorie 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 avant la migration, mais aussi des tâches de validation, d'audit ou de test qui ont lieu après le transfert des 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, tels que la complexité de la logique métier, l'utilisation de l'application et la disponibilité de l'équipe.

Un plan T-Minus peut se présenter comme suit :

Date	Phase	Catégorie	Tâches	Rôle	T-minus	État
11/1/2023	Pré-migration	Évaluation	Créer un rapport d'évaluation	Équipe Discovery	-21	Terminée
11/7/2023	Pré-migration	Préparation de la cible	Concevoir l'environnement cible comme décrit dans le document de conception	Équipe de migration	-14	Terminée
11/15/2023	Pré-migration	Gouvernance de l'entreprise	Date de migration et approbation J-X	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 jobs de migration	Ingénieur en migration vers le cloud	-2	Non démarrée
11/19/2023	Migration	Surveiller 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	Basculer DMS	Promouvoir une instance répliquée DMS	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 bases de données	Équipe de migration	0	Non démarrée
11/21/2023	Migration	Test d'application	Exécuter des tests de capacités et de performances	Équipe de migration	0	Non démarrée
11/22/2023	Migration	Gouvernance de l'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

Migrations de plusieurs 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 par migrer une base de données plus petite, idéalement non critique. Cette approche peut vous aider à acquérir des connaissances et à vous familiariser avec le processus et les outils de migration. Vous pouvez également détecter les failles du 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 simultanément un groupe de bases de données de petite taille, statiques ou moins critiques, comme illustré dans le schéma suivant.

Dans l'exemple illustré dans le schéma, les bases de données 1 à 4 constituent un groupe de petites bases de données qui sont migrées en même temps.

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. Si vous n'effectuez pas les tâches de préparation, la migration ne pourra pas avoir lieu ou la base de données migrée risque d'être inutilisable.

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

• Préparations et conditions préalables pour l'instance Amazon RDS
• Préparation de la base de données source et conditions préalables
• Configuration de Cloud SQL
• Configuration spécifique à la migration

Préparation et conditions préalables pour l'instance Amazon RDS

Voici quelques tâches de configuration et conditions préalables courantes :

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

• Pour la réplication en cours (modifications en streaming via CDC), vous devez utiliser une instance RDS complète et non une instance répliquée avec CDC activé. Pour en savoir plus, consultez Utiliser la capture de données modifiées avec SQL Server.

• Si vous utilisez des outils tiers, vous devez généralement les configurer avant de les utiliser. Consultez la documentation de l'outil tiers.

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

• Assurez-vous que la base de données source dispose d'un espace de stockage tampon et d'une mémoire disponibles pendant les opérations de migration. Par exemple, si vous utilisez des fichiers de sauvegarde du journal des transactions, surveillez l'utilisation de l'espace de stockage et assurez-vous de disposer d'un espace de stockage tampon supplémentaire.
• Documentez les paramètres de votre base de données et appliquez-les à votre instance cible avant d'effectuer les tests et la validation de la migration.

• Effectuez des mesures de référence sur votre environnement source en production. Tenez compte des points suivants :

  • Mesurez la taille de vos données, ainsi que les performances de votre charge de travail. Combien de temps prennent les requêtes ou transactions importantes, en moyenne ? Combien de temps pendant les heures pleines ?
  • Documentez les mesures de référence pour les comparer ultérieurement, afin de vous aider à déterminer si la fidélité de la migration de votre 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 cible pour qu'elle corresponde à 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 vCPU. Un dimensionnement incorrect peut entraîner des temps de migration longs, des problèmes de performances de la base de données, des erreurs de base de données et des problèmes de performances des applications.

Assurez-vous que la destination est adaptée. Il est important de noter que les options de configuration d'Amazon RDS peuvent différer de celles de Cloud SQL. Si Cloud SQL ne répond pas à vos exigences, envisagez d'autres options, y compris des bases de données sur Compute Engine.

Vous devez confirmer les propriétés et 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. Les instances Cloud SQL ne peuvent pas être migrées 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 SQL Server 15.0, migrez vers Cloud SQL pour SQL Server 15.0. Si les versions sont différentes, le paramètre de niveau de compatibilité doit être le même pour garantir les mêmes fonctionnalités du moteur.

• Répliquez les informations utilisateur séparément si vous utilisez des sauvegardes de moteur de base de données intégrées ou Database Migration Service. Pour en savoir plus, consultez les limites de la section Sauvegardes spécifiques au moteur de base de données.

• Examinez les options de configuration spécifiques au moteur de base de données et comparez les valeurs de leurs instances source et cible. Assurez-vous de comprendre leur impact et de savoir s'ils doivent être identiques ou non. Par exemple, nous vous recommandons de comparer les valeurs de la vue sys.configurations de votre base de données source avec celles de l'instance Cloud SQL. Notez que les options ne doivent pas toutes être identiques et que toutes les modifications d'options ne sont pas autorisées sur une instance Cloud SQL.

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

• Bonnes pratiques générales pour SQL Server
• Options de configuration d'instance pour SQL Server
• Options spécifiques au moteur de base de données pour SQL Server

Configuration spécifique à la migration

Si vous utilisez l'exportation et l'importation de fichiers pour migrer, ou si vous utilisez l'outil de migration Database Migration Service, vous devez créer un bucket Cloud Storage. Le bucket stocke les fichiers de sauvegarde de la base de données et du journal des transactions. Pour en savoir plus sur l'utilisation de Database Migration Service, consultez Stocker des fichiers de sauvegarde dans un bucket Cloud Storage.

Si vous utilisez la réplication, vous devez vous assurer que l'instance répliquée Cloud SQL a accès à votre base de données principale. Pour ce faire, vous pouvez utiliser les options de connectivité documentées.

Selon votre scénario et sa criticité, vous devrez peut-être mettre en œuvre un scénario de remplacement, qui inclut généralement l'inversion du sens de la réplication. Dans ce cas, vous aurez peut-être besoin d'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 commencer par utiliser Google Cloud Marketplace. Ensuite, 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). À l'aide d'un tableau de bord de validation des données, vous pouvez obtenir une représentation visuelle des données gérées par votre application Striim.

Vous pouvez mettre hors service les ressources qui connectent vos environnements Amazon etGoogle Cloud une fois la migration terminée et validée.

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 intégrées du moteur de base de données

Pour en savoir plus et obtenir des instructions sur les sauvegardes spécifiques à une base de données, consultez Importer des données à partir d'un fichier BAK vers Cloud SQL pour SQL Server et Exporter des données depuis RDS pour SQL Server. Pour en savoir plus sur l'automatisation des importations de fichiers journaux de transactions, consultez Planifier l'importation des fichiers journaux de transactions pour Amazon RDS.

Jobs 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 jobs 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 le job peut s'exécuter correctement. Choisissez un moment où vos charges de travail peuvent se permettre un court temps d'arrêt pour la migration et le basculement en production.

Le processus de migration implique généralement les tâches suivantes :

• Exportez une sauvegarde complète de la base de données source, puis importez-la dans un bucket Cloud Storage.
• Sauvegardez les fichiers journaux des transactions, puis importez-les dans le même bucket Cloud Storage. Pour en savoir plus sur l'automatisation de ce processus, consultez Planifier l'importation des fichiers journaux de transactions pour Amazon RDS.
• Dans Database Migration Service, vous surveillez le traitement des sauvegardes du journal des transactions.
• Arrêtez toute écriture de données sur la base de données source.
• Attendez que la source et la cible soient synchronisées, c'est-à-dire que la sauvegarde finale du journal des transactions soit traitée.
• Arrêtez la réplication en cours et promouvez le job de migration.En promouvant un job de migration, l'instance Cloud SQL de destination est déconnectée de l'instance de base de données source, puis promue en tant qu'instance principale.
• Déployez les applications qui pointent vers la nouvelle base de données cible.

Pour en savoir plus sur le processus de configuration de la migration, consultez Migrer vos bases de données SQL Server vers Cloud SQL pour SQL Server.

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

Si vous utilisez Amazon RDS Standard, vous devrez peut-être d'abord migrer vers la version Amazon RDS Custom, puis répliquer vers Cloud SQL.

Cloud SQL est compatible avec la réplication pour SQL Server. Pour en savoir plus sur la réplication à partir d'un serveur externe, consultez Migrer des données de SQL Server 2017 vers Cloud SQL pour SQL Server à l'aide de la réplication des instantanés.

Outils tiers

Définissez les tâches d'exécution de l'outil tiers que vous avez choisi. Par exemple, si vous décidez d'utiliser Striim, vous devez créer des applications dans votre espace de noms et configurer le lecteur CDC pour qu'il se connecte à l'instance Amazon. Pour en savoir plus, consultez la section Configuration de SQL Server dans la documentation Striim.

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 pendant le 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 important. Nous vous recommandons de ne pas effectuer de basculement 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 des délais pour toutes vos tâches d'exécution de la migration. Effectuer un dry run de migration permet de collecter des informations sur les temps prévus 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 un intervalle de basculement. Toutefois, il est important de planifier votre prochaine action au cas où le job de migration ponctuel ou la restauration de la sauvegarde échouerait à mi-parcours. Selon le temps écoulé de votre temps d'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 remplacement fait généralement référence au rollback de la migration après le basculement en production, si des problèmes apparaissent sur l'instance cible. Si vous mettez en œuvre un plan de remplacement, n'oubliez pas qu'il doit être traité comme une migration de base de données complète, y compris la planification et les tests.

Si vous choisissez de ne pas avoir de plan de secours, assurez-vous d'en 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 un dernier recours et que la plupart des migrations de bases de données ne l'utilisent pas, nous vous recommandons de toujours disposer d'une stratégie de remplacement.

Création 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 un temps d'arrêt lors du basculement ou si vous n'avez pas besoin des transactions validées sur le nouveau système cible.

Si vous avez besoin de toutes les données écrites sur votre base de données cible et que vous pouvez vous permettre un certain temps d'arrêt, vous pouvez envisager d'arrêter les écritures sur votre instance de base de données cible, d'effectuer 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'intégrer ultérieurement à votre système de base de données source initial, en particulier si vos charges de travail ne dépendent pas d'une heure de création d'enregistrement spécifique ou de contraintes d'ordre 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 basculement de 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 basculé vers l'instance de base de données cible. Par conséquent, elle ne permet pas de tests de bout en bout et présente une courte période sans solution de remplacement.

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 par réplication continue.

Transfert de la réplication

Cette stratégie est une variante de la réplication inverse. Vous répliquez les écritures de votre nouvelle base de données cible sur une troisième instance de base de données de votre choix. Vous pouvez faire pointer 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 n'est pas disponible. 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 une solution de remplacement à tout moment ou lorsque vous devez supprimer votre base de données source initiale peu de temps après le basculement en production.

Dupliquer les écritures

Si vous choisissez une stratégie de migration Y (écriture et lecture) ou de microservice d'accès aux données, ce plan de remplacement est déjà défini. Cette stratégie est plus complexe, car vous devez refactoriser les 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 un basculement progressif en production jusqu'à ce que vous n'utilisiez que vos instances de base de données cibles. En cas de problème, vous pouvez reconnecter 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 lorsqu'il est essentiel de ne pas avoir de temps d'arrêt lors de la migration, de disposer d'un remplacement fiable et lorsque vous disposez du temps et des ressources nécessaires pour refactoriser 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 de la base de données.
• Intégration aux applications existantes après leur basculement vers la nouvelle instance cible.

Définissez les facteurs clés de réussite, qui sont subjectifs à votre migration. Voici quelques exemples de facteurs subjectifs :

• Quelles données migrer ? Pour certaines charges de travail, il n'est peut-être pas nécessaire de migrer toutes les données. Vous ne souhaiterez peut-être pas migrer des données déjà agrégées, redondantes, archivées ou anciennes. Vous pouvez archiver ces données dans un bucket Cloud Storage, en tant que 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 limites définies.

Les configurations de stockage de votre environnement source peuvent ne pas correspondre directement aux cibles de l'environnementGoogle 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 une analyse comparative de vos instances sources, à la fois lors des phases d'évaluation et de validation.

Dans le processus d'analyse comparative, vous appliquez des séquences d'opérations de type production aux instances de base de données. Pendant ce temps, vous capturez et traitez les métriques pour mesurer et comparer les performances relatives des systèmes source et cible.

Pour les configurations conventionnelles basées sur un serveur, 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 de métriques historiques pour observer vos besoins de scaling.

Les outils suivants peuvent être utilisés pour les tests, la validation et l'analyse comparative des bases de données :

• HammerDB : outil Open Source d'analyse comparative et de test de charge de base de données. Il est compatible avec les 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 vaste communauté d'utilisateurs. Vous pouvez partager et comparer les résultats sur 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 d'analyse comparative DBT2 : analyse comparative spécialisée 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 une combinaison de transactions de lecture et d'écriture. Utilisez cet outil si vous souhaitez utiliser un test de charge de traitement des transactions en ligne (OLTP) prêt à l'emploi.
• DbUnit : outil de test unitaire Open Source utilisé pour tester les interactions avec les bases de données relationnelles 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 du test peut parfois être lente, en fonction de la taille et de la complexité de la base de données. Nous 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 des tests et les tests automatisés. Il utilise une syntaxe de base pour créer des scénarios 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 compatibilité avec les requêtes et les transactions complexes est limitée, et il ne bénéficie pas d'une assistance de la communauté importante ni d'une documentation complète, contrairement à d'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 continues.

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. Un dry run effectue la migration complète de la base de données sans changer de charge de travail de production. Il 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 insights sur le temps nécessaire à la migration réelle, ce qui vous permet d'ajuster votre calendrier.
• Il s'agit d'une occasion de tester, de valider et d'adapter le plan de migration. Il est parfois impossible de 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 mettre en œuvre leur migration, vous pouvez décider d'adopter une approche basée sur les risques. Avec cette approche, vous effectuez la validation des données sur un sous-ensemble de bases de données migrées à l'aide du 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 que toutes les tables et tous 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 ont basculé vers 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 basculé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 observer s'il existe une dégradation due à des erreurs de configuration ou à un dimensionnement incorrect.

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 s'exécuter sur les applications basculées.

Si vous utilisez Database Migration Service comme outil de migration, consultez Vérifier 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). 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.

Le DVT 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 "AVG", "COUNT", "SUM", "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 l'outil de validation des données, consultez le dépôt Git et l'article 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 de transférer des données d'un système à un autre.

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

• Informer 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é avec le temps maximal alloué à cette étape. Dans ce cas, envoyez régulièrement des informations intermédiaires aux équipes concernées.
• Si la durée est supérieure à la durée maximale réservée à chaque étape du plan, envisagez d'effectuer un rollback.
• Prenez des décisions de type "go/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 et reportez-vous à la documentation de l'outil de migration que vous avez sélectionné.

Effectuer le basculement en production

Le processus de basculement de production de haut niveau peut varier en fonction de la stratégie de migration que vous avez choisie. Si vos charges de travail peuvent être interrompues, le basculement de la migration commence par l'arrêt des écritures dans votre base de données source.

Pour les migrations de réplication continue, vous effectuez généralement les étapes de haut niveau suivantes dans le processus de basculement :

• Arrêtez toute écriture de données sur la base de données source.
• Drainez 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 normes de réussite de la migration que vous avez choisies.

Une fois que la validation des données répond à 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. Une interruption de l'application peut se produire.

Suivez les bonnes pratiques pour votre basculement en production :

• Surveillez vos applications qui fonctionnent avec la base de données cible après le basculement.
• Définissez une période de surveillance pour déterminer si vous devez ou non mettre en œuvre votre plan de remplacement.
• 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 de rollback de la migration peut être supérieur à la résolution des problèmes qui apparaissent dans l'environnement cible.

Nettoyer l'environnement source et configurer l'instance Cloud SQL

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

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

• Collectez les paramètres de base de données de votre instance source. Vous pouvez également vérifier qu'elles correspondent à celles que vous avez collectées 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 à partir 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 en sens 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 afin de maintenir les instances sources à jour après le basculement. Si vous devez effectuer un rollback, vous pouvez revenir à vos anciennes instances sources avec une perte de données minimale.

Outre le nettoyage de l'environnement source, les configurations critiques suivantes doivent être effectuées 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 de sorte que vous disposiez 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, consultez les ressources suivantes :

• À propos de la maintenance des instances Cloud SQL
• Paramètres spécifiques au moteur SQL Server

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 Migrer vers Google Cloud : optimiser votre environnement et Well-Architected FrameworkGoogle Cloud  : optimisation des performances.

Définir vos exigences d'optimisation

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

Améliorez 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 répliquées pour le basculement régional et une configuration de reprise après sinistre robuste.
• Pour les charges de travail moins critiques, les sauvegardes automatiques et à la demande peuvent suffire.
• Pour éviter la suppression accidentelle d'instances, utilisez la protection contre la suppression d'instances.
• Activez la récupération à un moment précis (PITR) pour votre instance Cloud SQL pour SQL Server.
• Automatisez les sauvegardes de bases de données SQL à l'aide de plans de maintenance.

Améliorer la rentabilité 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, veillez à configurer vos instances de manière à disposer d'une marge de sécurité pour les charges de travail de pointe. N'oubliez pas que les charges de travail des bases de données ont tendance à augmenter au fil du temps.

• Identifiez les ressources potentiellement surestimées :

  • Le redimensionnement de vos instances Cloud SQL peut réduire le coût de l'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 Créer et gérer des tableaux de bord personnalisés.

• Identifiez les instances qui ne nécessitent pas de configurations de haute disponibilité ou 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 un bucket Cloud Storage de sauvegarde complète ou d'archivage.

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

  • Dans la plupart des cas, le stockage SSD constitue 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, le stockage HDD 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.

Pour réduire les coûts de licence, en particulier pour Cloud SQL pour SQL Server, tenez compte des points suivants :

• Migrez vers SQL Server Standard Edition si les SLA répondent à vos exigences.
• Désactivez le multithreading simultané (SMT) et ajoutez 25 % de cœurs supplémentaires. Les cœurs supplémentaires peuvent compenser l'impact sur les performances de la désactivation du SMT. Cette stratégie peut vous aider à réduire les coûts de licence, mais elle peut avoir un impact sur les performances de votre instance. Nous vous recommandons d'effectuer un test de charge sur votre instance pour vous assurer que vos SLA ne sont pas affectés.
• Envisagez une migration hétérogène de Cloud SQL pour SQL Server vers Cloud SQL pour PostgreSQL ou AlloyDB pour PostgreSQL, en fonction de votre charge de travail.

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

Les problèmes de performances mineurs liés aux bases de données peuvent souvent avoir un impact sur l'ensemble des opérations. Pour maintenir et améliorer les performances de votre instance Cloud SQL, tenez compte des consignes suivantes :

• Si vous avez un grand nombre de tables de base de données, elles peuvent 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 votre 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 prédéfini "Insights sur les requêtes" dans Cloud Monitoring (ou de fonctionnalités intégrées au moteur de base de données similaires). 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.

• Empêchez la fragmentation des données et des index. Définissez une planification pour recréer vos index dans SQL Server, en fonction de la fréquence de modification de vos données.

• Modifiez les paramètres spécifiques au moteur SQL Server afin qu'ils fonctionnent de manière optimale pour Cloud SQL.

• Pour en savoir plus sur la maintenance des index et des statistiques, consultez SQL Server Maintenance Solution.

• Mettez régulièrement à jour les statistiques sur Cloud SQL pour SQL Server.

• Envisagez d'effectuer des opérations ETL sur une instance répliquée avec accès en lecture, car elles peuvent affecter le cache de votre instance.

Pour en savoir plus sur l'amélioration des performances, consultez Performances dans "Diagnostiquer les problèmes" et Cloud SQL : analyse des performances et réglage des requêtes SQL Server.

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 emplacement centralisé où tous les membres de l'équipe peuvent voir ce qui se passe au niveau de la base de données et de l'instance. 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 Cloudque 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 l'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é sectorielle.

• Affichez et interrogez les journaux de votre instance Cloud SQL.

• Observez l'état de vos bases de données pour améliorer les performances de votre environnement et résoudre les éventuels problèmes.

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

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

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

• Si vous disposez d'instances volumineuses, nous vous recommandons de les scinder en instances plus petites, si 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 influer sur le temps de mise à niveau de la base de données. Dans l'idéal, essayez de ne pas dépasser 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 base de données que vous pourriez rencontrer, suivez les instructions ci-dessous jusqu'à ce que votre problème soit résolu :

Faire évoluer l'infrastructure : augmentez les ressources (telles que le débit du disque, les vCPU et la RAM). Selon l'urgence, la disponibilité et l'expérience de votre équipe, le scaling vertical de votre instance peut résoudre la plupart des problèmes de performances. Plus tard, vous pourrez approfondir la recherche de la cause principale du problème dans un environnement de test et envisager des options pour l'éliminer.

Effectuer et planifier des opérations de maintenance de base de données : défragmentation d'index, mises à jour des statistiques, analyse de nettoyage et réindexation des tables fortement 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 s'il y a eu un changement par rapport aux activités normales de la base de données. Par exemple, l'ajout récent d'une colonne ou de nombreuses mises à jour sur une table.

Régler et optimiser la base de données : les tables de votre base de données sont-elles correctement structurées ? Les colonnes ont-elles les bons types de données ? 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 attentes sur d'autres ressources. Envisagez d'ajouter des index pour prendre en charge vos requêtes critiques. Éliminez 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.

Effectuez un scaling horizontal de vos lectures : envisagez d'utiliser des instances répliqué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. Si possible, archivez les données dont vous n'avez plus besoin. 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 partitionnement est une opération complexe qui implique de réorganiser votre base de données et vos applications d'une 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 d'un critère de partitionnement spécifique. Les critères peuvent être basés sur le client ou le sujet. Cette option vous permet d'effectuer un scaling horizontal de vos écritures et de 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 segments déséquilibrés appelés "points d'accès", qui l'emporteraient sur les avantages du segment.

Pour Cloud SQL pour SQL Server, tenez compte des bonnes pratiques suivantes :

• Pour mettre à jour les paramètres SQL Server afin d'optimiser les performances avec Cloud SQL, consultez Paramètres SQL Server.
• Déterminez la capacité du sous-système des opérations d'E/S avant de déployer SQL Server.

• Si vous disposez d'instances volumineuses, scindez-les en instances plus petites, dans la mesure du possible :

  • Une taille de disque de 4 To ou plus offre un débit et un nombre d'IOPS plus élevés.
  • Plus le nombre de processeurs virtuels est élevé, plus le nombre d'IOPS et le débit sont élevés. Lorsque vous utilisez un nombre de processeurs virtuels plus élevé, surveillez les temps d'attente de la base de données pour le parallélisme, qui peuvent également augmenter.

• Désactivez le SMT si les performances sont réduites dans certaines situations. Par exemple, si une application exécute des threads qui deviennent un goulot d'étranglement et que l'architecture du processeur ne gère pas cela efficacement.

• Définissez une planification pour réorganiser ou recréer vos index, en fonction de la fréquence de modification de vos données.

• Définissez un facteur de remplissage approprié pour réduire la fragmentation. Surveillez SQL Server pour détecter les index manquants susceptibles d'améliorer les performances.

• 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. Gérez également la croissance de la base de données de manière proactive avant que le seuil de autogrow ne soit atteint.

• Pour faire évoluer automatiquement la capacité de stockage, activez l'augmentation automatique de l'espace de stockage. Cloud SQL peut ajouter de l'espace de stockage si celui de la base de données et de l'instance est insuffisant.

• Assurez-vous de comprendre les exigences locales, l'ordre de tri, ainsi que la sensibilité à la casse et aux accents des données sur lesquelles vous travaillez. Lorsque vous sélectionnez un classement pour votre serveur, base de données, colonne ou expression, vous attribuez certaines caractéristiques à vos données.

• Les jointures de hachage récursives ou les interruptions de hachage entraînent une baisse des performances sur un serveur. Si vous rencontrez de nombreux événements de type "hash warning" dans une trace, mettez à jour les statistiques des colonnes en cours de jointure. Pour en savoir plus, consultez Classe d'événement Hash Warning.

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

Étapes suivantes

• Découvrez d'autres parcours de migration d'AWS vers Google Cloud .
• Découvrez comment comparer les services AWS et Azure à Google Cloud.
• Découvrez où obtenir de l'aide pour vos migrations.
• Suivez la formation Google Skills sur la migration vers Google Cloud.
• Pour découvrir d'autres architectures de référence, schémas et bonnes pratiques, consultez le Centre d'architecture cloud.

Contributeurs

Auteurs :

• Alex Cârciu | Architecte de solutions
• Marco Ferrari | Architecte de solutions cloud

Autres contributeurs :

• Derek Downey | Ingénieur relations avec les développeurs
• Paweł Krentowski | Rédacteur technique
• Matthew Smith | Ingénieur cloud stratégique
• Somdyuti Paul | Spécialiste de la gestion des données
• Zach Seils | Spécialiste en gestion des réseaux