Migrer d'AWS vers Google Cloud: migrer depuis Amazon RDS et Amazon Aurora pour PostgreSQL vers Cloud SQL et AlloyDB pour PostgreSQL

Last reviewed 2024-09-12 UTC

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

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

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

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

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.

Chemin de migration en quatre phases.

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

  1. Évaluer et découvrir vos charges de travail et vos données
  2. Planifier et établir les 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 d'avoir 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.

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

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

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

La phase d'évaluation de la base de données vous aide à choisir la taille et les spécifications de votre instance de base de données Cloud SQL cible qui correspondent à la source pour des besoins de performances similaires. Portez une attention particulière à la taille et au débit du disque, aux IOPS et au nombre de processeurs virtuels. Les migrations peuvent rencontrer des difficultés ou échouer en raison d'un dimensionnement incorrect de l'instance de base de données cible. Un dimensionnement incorrect peut entraîner de longs délais de migration, des problèmes de performances de la base de données, des erreurs de base de données et des problèmes de performances de l'application. Lorsque vous choisissez l'instance Cloud SQL, gardez à l'esprit 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 ou Amazon Aurora

Pour définir le champ d'application de votre migration, vous devez créer un inventaire et collecter des informations sur vos instances Amazon RDS et Amazon Aurora. Dans l'idéal, il s'agit d'un processus automatisé, car les approches manuelles sont sujettes aux erreurs et peuvent conduire à des hypothèses incorrectes.

Il est possible qu'Amazon RDS ou Amazon Aurora et Cloud SQL pour PostgreSQL ou AlloyDB pour PostgreSQL ne disposent pas de fonctionnalités, de spécifications d'instance ou d'opérations similaires. Certaines fonctionnalités peuvent être implémentées différemment ou être indisponibles. Les différences peuvent concerner 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, les intégrations de fonctionnalités spécifiques au moteur de base de données et les extensions. En fonction du type de moteur de base de données, de la taille et de l'architecture de l'instance, 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 outils de benchmarking sont détaillés dans la section 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 évaluations

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).

Migration Center vous permet d'évaluer complètement votre paysage d'applications et de bases de données, y compris l'adéquation technique pour une migration de base de données vers Google Cloud. Vous recevez des recommandations sur la taille et la 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 qui peuvent entraîner un échec de la migration, et peut suggérer 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 de fonctionnement.
  • Plan de migration par phases pour déplacer les bases de données et les applications associées avec un minimum de perturbations 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 informations sur la topologie de la base de données, les règles de sauvegarde, les paramètres et les personnalisations spéciales en cours d'utilisation.

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

Nous vous recommandons l'outil Open Source DMA, qui a été 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 la 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

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

  • Vos bases de données ont-elles une taille supérieure à 5 To ?
  • Votre base de données contient-elle des tables volumineuses ? Sont-elles supérieures à 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 du tout 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. Il est possible que certaines données restent dans les sauvegardes de votre base de données source. Par exemple, les anciennes tables de journaux ou les données d'archivage peuvent ne pas être nécessaires. Vous pouvez également décider de déplacer les données après le processus de migration, en fonction de votre stratégie et de vos outils.

Établissez des bases de référence pour la migration de données qui vous aideront à comparer et à évaluer vos résultats et vos impacts. Ces références 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 dans l'environnement source pour vous aider à évaluer la réussite de la migration de vos données. Ces mesures incluent les suivantes :

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

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

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

Une fois les inventaires créés, évaluez les processus opérationnels et de déploiement de votre base de données pour déterminer comment 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éfinissez et appliquez 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 pour PostgreSQL et limiter les données dans un VPC.

  • Corrigez et configurez vos instances. Il est possible que vous deviez mettre à jour vos outils de déploiement existants. Par exemple, vous pouvez utiliser des paramètres de configuration personnalisés dans des groupes de paramètres ou des groupes d'options Amazon. Il est possible que vous deviez adapter vos outils de provisionnement pour qu'ils utilisent Cloud Storage ou Secret Manager afin de lire ces listes de configuration personnalisées.

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

Terminer l'évaluation

Après avoir créé les inventaires de votre environnement Amazon RDS ou Amazon Aurora, effectuez les autres étapes de la phase d'évaluation décrites dans 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 établir vos fondations.

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

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

Migrer des instances Amazon RDS et Amazon Aurora pour PostgreSQL vers Cloud SQL pour PostgreSQL et AlloyDB pour PostgreSQL

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 sélectionnées.

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

  4. Définissez les tâches préparatoires à effectuer pour que l'outil de migration puisse fonctionner correctement.

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

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

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

  8. Effectuez la migration.

  9. Effectuez le basculement en production.

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

  11. Effectuez des ajustements et des optimisations.

Chaque phase est décrite dans les sections suivantes :

Choisir votre stratégie de migration

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

  • Maintenance planifiée (également appelée migration ponctuelle 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 complexe, car vos charges de travail et vos services ne nécessiteront pas beaucoup de refactoring. 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 stratégiques, cette option offre un risque de perte de données plus faible et un temps d'arrêt quasi nul. Les efforts sont divisés en plusieurs blocs. Ainsi, en cas d'échec, la restauration et la répétition prennent moins de temps. Toutefois, la configuration est plus complexe et nécessite plus de planification et de temps. Des efforts supplémentaires sont également nécessaires pour refactoriser les applications qui se connectent à vos instances de base de données. Envisagez l'une des variantes suivantes :

    • Utilisez l'approche Y (écriture et lecture), qui est une forme de migration parallèle, pour dupliquer 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 les efforts de refactorisation requis par l'approche Y (écriture et lecture).

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

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

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

L'organigramme précédent montre 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 fenêtre de transition 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 la réponse est oui, adoptez la stratégie de migration avec maintenance planifiée.

Les stratégies peuvent varier pour différentes bases de données, même si 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 la méthode de maintenance planifiée, mais utilisez la réplication continue pour les bases de données critiques pour lesquelles les temps d'arrêt sont coûteux.

En général, une migration est considérée comme terminée lorsque le basculement entre l'instance source initiale et l'instance cible a lieu. Toute réplication (si elle est utilisée) est arrêtée, et toutes les lectures et écritures sont effectuées sur l'instance cible. Si vous basculez lorsque les deux instances sont synchronisées, vous ne perdrez aucune donnée et le temps d'arrêt sera minimal.

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.

Les configurations de migration qui ne provoquent 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 creuses.

Chaque stratégie de migration présente des compromis et des impacts associés au processus de migration. Par exemple, les processus de réplication impliquent une charge supplémentaire sur vos instances sources, et vos applications peuvent être affectées par le délai de réplication. Les applications (et les clients) devront peut-être attendre pendant l'indisponibilité de l'application, au moins aussi longtemps que le décalage de réplication, avant d'utiliser la nouvelle base de données. En pratique, les facteurs suivants peuvent augmenter les 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 abandonnées.
  • Le cache peut prendre un certain temps à se remplir 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. En fonction de la configuration des entrées DNS, cela peut prendre un certain temps. Lorsque vous mettez à jour les enregistrements DNS, réduisez la valeur TTL avant la migration.

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

  • Identifiez une période pendant laquelle les temps d'arrêt auraient un impact minimal sur vos charges de travail. Par exemple, en dehors des heures d'ouverture normales, les week-ends ou pendant d'autres intervalles de maintenance planifiés.
  • Identifiez les parties de vos charges de travail qui peuvent être migrées et basculées en production à différentes étapes. Vos applications peuvent comporter différents composants qui peuvent être isolés, adaptés et migrés sans impact. Par exemple, les interfaces, les modules CRM, les services backend et les plates-formes de création de rapports. Ces modules peuvent avoir leurs propres bases de données, 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 d'implémenter une migration progressive. Utilisez des transferts de données incrémentaux par lot et adaptez une partie de vos charges de travail pour qu'elles fonctionnent avec les données obsolètes de l'instance cible.
  • Envisagez de refactoriser vos applications pour minimiser l'impact de la migration. Par exemple, adaptez vos applications pour qu'elles écrivent dans les bases de données source et cible, et implémentez ainsi une réplication au niveau de l'application.

Choisissez vos outils de migration.

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

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

  • Stratégie de migration (maintenance planifiée ou réplication continue).
  • Moteurs et versions des moteurs de base de données source et cible.
  • Environnements dans lesquels se trouvent les instances sources et cibles.
  • 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 apportées à la base de données.
  • Disponibilité des services gérés pour la migration.

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

  • Offrez une expérience de migration cohérente : vous pouvez consolider différentes techniques et différents modèles de migration 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.

  • Proposez des modèles de migration résilients et éprouvés : les migrations de bases de données sont des événements peu fréquents, mais essentiels. Pour éviter les erreurs de débutant et les problèmes liés aux solutions existantes, vous pouvez utiliser des outils proposés par des experts expérimentés au lieu 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 les solutions de migration personnalisées.

Les sections suivantes décrivent les recommandations concernant l'outil 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 les limites et les bonnes pratiques de chaque outil.

Pour les migrations ponctuelles vers Cloud SQL pour PostgreSQL ou AlloyDB pour PostgreSQL, nous vous recommandons d'utiliser les sauvegardes du moteur de base de données pour exporter les données de votre instance source et les importer dans votre instance cible. Les tâches de migration ponctuelles ne sont pas compatibles avec Database Migration Service.

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

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

La configuration et la synchronisation nécessitent un certain effort, en particulier pour un grand nombre de bases de données. Toutefois, 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 les autres outils pour les grandes instances.

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

  • Les sauvegardes peuvent être sujettes à des erreurs, en particulier si elles sont effectuées manuellement.
  • Les données peuvent être non sécurisées si les instantanés ne sont pas gérés correctement.
  • Les sauvegardes ne disposent pas de capacités de surveillance appropriées.
  • La mise à l'échelle des sauvegardes est difficile lorsque vous migrez de nombreuses bases de données.

Vous pouvez utiliser les utilitaires de sauvegarde intégrés à PostgreSQL, pg_dump et pg_dumpall, pour migrer Cloud SQL pour PostgreSQL et AlloyDB pour PostgreSQL. Toutefois, les utilitaires pg_dump et pg_dumapall présentent les limites générales suivantes :

  • Les utilitaires de sauvegarde intégrés doivent être utilisés pour migrer les bases de données de 500 Go ou moins. L'exportation et la restauration de bases de données volumineuses peuvent prendre beaucoup de temps et nécessiter un espace disque et une mémoire importants.
  • L'utilitaire pg_dump n'inclut pas les utilisateurs ni les rôles. Pour migrer ces comptes et rôles utilisateur, vous pouvez utiliser l'utilitaire pg_dumpall.
  • Cloud Storage accepte une taille d'objet unique maximale de 5 téraoctets (To). Si vous disposez de bases de données dont la taille est supérieure à 5 To, l'opération d'exportation vers Cloud Storage échoue. Dans ce cas, vous devez diviser vos fichiers d'exportation en segments plus petits.

Si vous choisissez d'utiliser ces utilitaires, tenez compte des restrictions et des bonnes pratiques suivantes :

  • Compressez les données pour réduire les coûts et la durée du transfert. Utilisez l'option --jobs avec la commande pg_dump pour exécuter un nombre donné de tâches de vidage simultanément.
  • Utilisez l'option -z avec la commande pg_dump pour spécifier le niveau de compression à utiliser. Les valeurs acceptables pour cette option sont comprises entre 0 et 9. La valeur par défaut est de compresser au niveau 6. Des valeurs plus élevées réduisent la taille du fichier de dump, mais peuvent entraîner une consommation élevée des ressources sur l'hôte client. Si l'hôte client dispose de suffisamment de ressources, des niveaux de compression plus élevés peuvent réduire encore la taille du fichier de dump.
  • Utiliser les indicateurs appropriés lors de la création d'un fichier de dump SQL
  • Vérifiez la base de données importée Surveillez la sortie de l'utilitaire pg_restore pour détecter les éventuels messages d'erreur lors du processus de restauration. Consultez les journaux PostgreSQL pour détecter les éventuels avertissements ou erreurs survenus lors du processus de restauration. Exécutez des requêtes de base et des décomptes de tables pour vérifier l'intégrité de votre base de données.

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

Autres approches pour la migration de la maintenance planifiée

L'utilisation d'autres approches que les utilitaires de sauvegarde intégrés peut vous offrir plus de contrôle et de flexibilité lors de la migration de votre maintenance planifiée. Ces autres types d'approches vous permettent d'effectuer des transformations, des vérifications ou d'autres opérations sur vos données lors de la migration. Vous pouvez regrouper plusieurs instances ou bases de données dans une seule instance ou base de données. La consolidation des instances peut vous aider à réduire les coûts opérationnels et à résoudre vos problèmes d'évolutivité.

Une alternative aux utilitaires de sauvegarde consiste à utiliser des fichiers plats pour exporter et importer vos données. Pour en savoir plus sur l'importation de fichiers à plat, consultez Exporter et importer à l'aide de fichiers CSV pour Cloud SQL pour PostgreSQL.

Une autre solution consiste à utiliser une importation gérée pour configurer la réplication à partir d'une base de données PostgreSQL externe. Lorsque vous utilisez une importation gérée, un chargement initial des données est effectué depuis la base de données externe vers l'instance Cloud SQL pour PostgreSQL. Ce chargement initial utilise un service qui extrait les données du serveur externe (l'instance RDS ou Aurora) et les importe directement dans l'instance Cloud SQL pour PostgreSQL. Pour en savoir plus, consultez la section Utiliser une importation gérée pour configurer la réplication à partir de bases de données externes.

Une autre façon d'effectuer une migration unique de vos données consiste à exporter les tables de votre base de données PostgreSQL source vers des fichiers CSV ou SQL. Vous pouvez ensuite importer le fichier CSV ou SQL dans Cloud SQL pour PostgreSQL ou AlloyDB pour PostgreSQL. Pour exporter la date de votre instance source, vous pouvez utiliser l'extension aws_s3 pour PostgreSQL. Vous pouvez également utiliser Amazon Database Migration Service et un bucket S3 comme cible. Pour en savoir plus sur cette approche, consultez les ressources suivantes :

Vous pouvez également importer manuellement des données dans une instance AlloyDB pour PostgreSQL. Les formats acceptés sont les suivants :

  • CSV : avec ce format de fichier, chaque fichier contient le contenu d'un tableau de la base de données. Vous pouvez charger les données dans le fichier CSV à l'aide du programme en ligne de commande psql. Pour en savoir plus, consultez la section sur la création d'un fichier CSV.
  • DMP : ce format de fichier contient l'archive d'une base de données PostgreSQL entière. Vous importez les données de ce fichier à l'aide de l'utilitaire pg_restore. Pour en savoir plus, consultez la section Importer un fichier DMP.
  • SQL : ce format de fichier contient la reconstruction textuelle d'une base de données PostgreSQL. Les données de ce fichier sont traitées à l'aide de la ligne de commande psql. Pour en savoir plus, consultez la section Importer un fichier SQL.

Outils pour les migrations de réplication continue

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

Organigramme vous aidant à choisir un outil pour les migrations de 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, pouvez-vous vous permettre quelques secondes d'indisponibilité en écriture pendant l'étape de réplication ?

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

    • Si la réponse est non, vous devez évaluer si la réplication intégrée du moteur de base de données est compatible :

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

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

Database Migration Service pour la migration par réplication continue

Database Migration Service propose un type de job spécifique pour les migrations continues. Ces jobs de migration continue permettent d'effectuer des migrations haute fidélité vers Cloud SQL pour PostgreSQL et AlloyDB pour PostgreSQL.

Lorsque vous utilisez Database Migration Service pour migrer vers Cloud SQL pour PostgreSQL ou AlloyDB pour PostgreSQL, des conditions préalables et des limites sont associées à chaque instance cible :

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

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

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

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

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

Voici les limites et les conditions préalables pour Cloud SQL pour PostgreSQL :

  • Les versions Amazon suivantes sont acceptées :

    • Amazon RDS 9.6.10 et versions ultérieures, 10.5 et versions ultérieures, 11.1 et versions ultérieures, 12, 13, 14
    • Amazon Aurora 10.11 et versions ultérieures, 11.6 et versions ultérieures, 12.4 et versions ultérieures, et 13.3 et versions ultérieures

  • Le pare-feu du serveur externe doit être configuré pour autoriser la plage d'adresses IP internes allouée à l'accès aux services privés du réseau VPC. La base de données répliquée Cloud SQL pour PostgreSQL utilise le réseau VPC comme réseau privé.

  • Le pare-feu de la base de données source doit être configuré pour autoriser l'intégralité de la plage d'adresses IP internes allouée à la connexion de service privée du réseau VPC. L'instance de destination Cloud SQL pour PostgreSQL utilise ce réseau VPC dans le champ privateNetwork de son paramètre IpConfiguration.

  • Lorsque vous installez l'extension pglogical sur une instance Cloud SQL pour PostgreSQL, assurez-vous d'avoir défini l'indicateur enable_pglogical sur on (par exemple, cloudsql.enable_pglogical=on).

  • Assurez-vous que le paramètre shared_preload_libraries inclut l'extension pglogical sur votre instance source (par exemple, shared_preload_libraries=pg_stat_statements,pglogical). Définissez le paramètre rds.logical_replication sur 1. Ce paramètre active les journaux WAL au niveau logique.

    Ces modifications nécessitent un redémarrage de l'instance principale.

Pour en savoir plus sur l'utilisation de Cloud SQL pour PostgreSQL pour la réplication, consultez la checklist du serveur externe dans la section sur la réplication pour PostgreSQL, ainsi que la page Configurer la réplication logique et le décodage pour PostgreSQL de la documentation officielle de Cloud SQL.

AlloyDB pour PostgreSQL est compatible avec la réplication via l'extension pglogical. Pour activer l'extension pglogical pour la réplication, vous pouvez utiliser la commande CREATE EXTENSION. Avant d'utiliser cette commande, vous devez d'abord définir les indicateurs de base de données alloydb.enable_pglogical et alloydb.logical_decoding sur on dans l'instance AlloyDB pour PostgreSQL où vous souhaitez utiliser l'extension. L'activation de ces options nécessite le redémarrage de l'instance.

Autres approches pour la migration de la réplication continue

Vous pouvez utiliser Datastream pour répliquer les modifications apportées à votre instance PostgreSQL source en temps quasi réel. Datastream utilise la capture des données modifiées (CDC) et la réplication pour répliquer et synchroniser les données. Vous pouvez ensuite utiliser Datastream pour la réplication continue depuis Amazon RDS et Amazon Aurora. Vous utilisez Datastream pour répliquer les modifications de votre instance PostgreSQL vers BigQuery ou Cloud Storage. Ces données répliquées peuvent ensuite être importées dans votre instance Cloud SQL pour PostgreSQL et AlloyDB pour PostgreSQL avec Dataflow à l'aide d'un modèle flexible Dataflow ou avec Dataproc.

Pour en savoir plus sur l'utilisation de Datastream et Dataflow, consultez les ressources suivantes :

Outils tiers pour la migration de la réplication continue

Dans certains cas, il peut être préférable d'utiliser un seul outil tiers pour la plupart des moteurs de base de données. 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 comme 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 de bout en bout en mémoire qui permet de collecter, filtrer, transformer, enrichir, agréger, analyser et distribuer des données en temps réel :

  • Avantages :

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

  • Inconvénients :

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

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

  • Avantages :

    • Open Source.
    • Un soutien solide de la communauté.
    • 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 la 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 incrémentielle par lot n'est pas acceptée.

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

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

  • Avantages :

    • Modèles de connexion préconfigurés et pipelines sans code.
    • Propager les modifications de schéma de votre 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 :

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

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

Pour réussir la migration de la base de données et le 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 avant ou après la migration pour implémenter ce filtrage. Vous vous assurez également que la migration de votre base de données n'affecte pas votre contrat de niveau de service (SLA) existant ni votre plan de continuité des activités.

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

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

La migration de bases de données est un processus itératif. 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 avoir un plan de restauration. Suivez les bonnes pratiques décrites dans Migrer vers Google Cloud : bonnes pratiques pour valider un plan de migration.

TDD

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

  • Exigences et caractère critique pour l'entreprise
  • Objectif de temps de récupération (RTO) :
  • Objectif de point de reprise après sinistre (RPO) :
  • Détails de la migration de bases de données
  • Estimations de l'effort de migration
  • Recommandations de validation de la migration

Matrice RACI

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

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

La chronologie 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 de données.

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

Voici un exemple de forfait T-Minus :

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 tel qu'il est 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 T-Minus 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 Bascule DMS Promouvoir une instance DMS répliquée Ingénieur en migration vers le cloud 0 Non démarrée
11/21/2023 Migration Validation de la migration Validation de la migration de la base de données Équipe de migration 0 Non démarrée
11/21/2023 Migration Test de l'application Exécuter des tests de 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 un compte utilisateur DMS Équipe de sécurité 4 Non démarrée

Migrations de bases de données multiples

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

Nous vous recommandons de commencer le processus en migrant une base de données plus petite, idéalement non critique. Cette approche peut vous aider à développer vos connaissances et votre confiance dans le processus et les outils de migration. Vous pouvez également détecter 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 un groupe de bases de données petites, statiques ou moins critiques en même temps, comme illustré dans le schéma suivant.

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

Dans l'exemple illustré dans le diagramme, les bases de données 1 à 4 constituent un groupe de petites bases de données 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. Sans les tâches de préparation, la migration ne peut pas avoir lieu ou la base de données migrée est inutilisable.

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

  • Préparations et prérequis pour une instance Amazon RDS ou Amazon Aurora
  • Préparation de la base de données source et conditions préalables
  • Configurer une instance Cloud SQL pour PostgreSQL et AlloyDB pour PostgreSQL
  • Configuration spécifique à la migration

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

Voici quelques tâches de configuration et prérequis courants :

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

  • Vous devrez peut-être configurer un groupe de sécurité pour autoriser les connexions à distance sur les ports requis et appliquer le groupe de sécurité à votre instance Amazon RDS ou Amazon Aurora :

    • Par défaut, dans AWS, l'accès au 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é.

  • Si vous migrez depuis Amazon RDS, assurez-vous d'avoir suffisamment d'espace disque libre pour mettre en mémoire tampon les journaux write-ahead pendant toute la durée de l'opération de chargement complet sur votre instance Amazon RDS.

  • 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 de lecture.

  • Si vous utilisez la réplication intégrée, vous devez configurer votre instance Amazon RDS ou Amazon Aurora pour la réplication pour PostgreSQL. La réplication intégrée ou les outils qui l'utilisent nécessitent une réplication logique pour PostgreSQL.

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

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

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

  • Si vous choisissez d'utiliser Database Migration Service, configurez votre base de données source avant de vous y connecter. Pour en savoir plus, consultez les pages Configurer votre source pour PostgreSQL et Configurer votre source pour PostgreSQL vers AlloyDB pour PostgreSQL.

  • Pour les tables qui ne possèdent pas de clés primaires, une fois que Database Migration Service a migré la sauvegarde initiale, seules les instructions INSERT sont migrées vers la base de données cible pendant la phase CDC. Les instructions DELETE et UPDATE ne sont pas migrées pour ces tables.

  • Notez que les grands objets ne peuvent pas être répliqués par Database Migration Service, car la fonctionnalité de décodage logique de PostgreSQL n'est pas compatible avec le décodage des modifications apportées aux grands objets.

  • Si vous choisissez d'utiliser la réplication intégrée, sachez que la réplication logique présente certaines limites concernant les commandes, les séquences et les objets volumineux du langage de définition de données (LDD). Des clés primaires doivent exister ou être ajoutées aux tables pour lesquelles la CDC doit être activée et qui font l'objet de nombreuses mises à jour.

  • Certains outils de migration tiers exigent que toutes les colonnes d'objets volumineux puissent avoir une valeur nulle. Toutes les colonnes d'objets volumineux qui sont NOT NULL doivent voir cette contrainte supprimée lors de la migration.

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

    • Mesurez la taille de vos données et les performances de votre charge de travail. Combien de temps prennent en moyenne les requêtes ou transactions importantes ? Combien de temps aux heures de pointe ?
    • Documentez les mesures de référence pour les comparer ultérieurement. Cela vous aidera à 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.

Configurer une instance Cloud SQL pour PostgreSQL et AlloyDB pour PostgreSQL

Pour que votre instance cible atteigne des niveaux de performances similaires à ceux de votre instance source, choisissez la taille et les spécifications de votre instance de base de données PostgreSQL cible pour qu'elles correspondent à celles de l'instance source. Portez une attention particulière à la taille et au débit du disque, opérations d'entrée/de sortie par seconde (IOPS) et au nombre de processeurs virtuels (vCPU). Un dimensionnement incorrect peut entraîner de longs délais de migration, des problèmes de performances de la base de données, des erreurs de base de données et des problèmes de performances de l'application. Lorsque vous choisissez l'instance Cloud SQL pour PostgreSQL ou AlloyDB pour PostgreSQL, gardez à l'esprit que les performances du disque sont basées sur la taille du disque et le nombre de processeurs virtuels.

Vous devez confirmer les propriétés et les exigences suivantes avant de créer vos instances Cloud SQL pour PostgreSQL et AlloyDB pour PostgreSQL. Si vous souhaitez modifier ces propriétés et exigences ultérieurement, vous devrez recréer les instances.

  • Choisissez avec soin le projet et la région de vos instances cibles Cloud SQL pour PostgreSQL et AlloyDB pour PostgreSQL. Les instances 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 pour PostgreSQL et AlloyDB pour PostgreSQL. Par exemple, si vous utilisez PostgreSQL 14.x sur Amazon RDS ou Amazon Aurora, vous devez migrer vers Cloud SQL ou AlloyDB pour PostgreSQL, pour la version 14.x de PostgreSQL.

  • 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 dans la section Sauvegardes spécifiques au moteur de base de données.

  • Examinez les indicateurs de configuration spécifiques au moteur de base de données et comparez les valeurs de l'instance source et de l'instance cible. Assurez-vous de comprendre leur impact et de savoir s'ils doivent être identiques ou non. Par exemple, lorsque vous travaillez avec PostgreSQL, nous vous recommandons de comparer les valeurs du tableau pg_settings de votre base de données source à celles de l'instance Cloud SQL et AlloyDB pour PostgreSQL. Mettez à jour les paramètres des indicateurs si nécessaire sur l'instance de base de données cible pour répliquer les paramètres sources.

  • En fonction de la nature de votre charge de travail, vous devrez peut-être activer des extensions spécifiques pour prendre en charge votre base de données. Si votre charge de travail nécessite ces extensions, consultez les extensions PostgreSQL compatibles et découvrez comment les activer dans Cloud SQL et AlloyDB pour PostgreSQL.

Pour en savoir plus sur la configuration de Cloud SQL pour PostgreSQL, consultez Options de configuration des instances, Options spécifiques au moteur de base de données et Extensions compatibles.

Pour en savoir plus sur la configuration d'AlloyDB pour PostgreSQL, consultez les pages Options de base de données compatibles et Extensions compatibles.

Configuration spécifique à la migration

Si vous pouvez vous permettre des temps d'arrêt, vous pouvez importer des fichiers de dump SQL dans Cloud SQL et AlloyDB pour PostgreSQL. Dans ce cas, vous devrez peut-être créer un bucket Cloud Storage pour stocker le dump de la base de données.

Si vous utilisez la réplication, vous devez vous assurer que l'instance répliquée Cloud SQL et AlloyDB pour PostgreSQL a accès à votre base de données principale (source). Vous pouvez y accéder à l'aide des options de connectivité documentées.

Selon votre cas d'utilisation et son caractère critique, vous devrez peut-être implémenter un scénario de secours, 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 votre cible Cloud SQL et AlloyDB pour PostgreSQL vers votre instance Amazon source.

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

Si vous migrez vers AlloyDB pour PostgreSQL, envisagez d'utiliser une instance Cloud SQL pour PostgreSQL comme destination potentielle pour vos scénarios de remplacement. Utilisez l'extension pglogical pour configurer la réplication logique sur cette instance Cloud SQL.

Pour en savoir plus, consultez les ressources suivantes :

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

Les tâches d'exécution implémentent la migration elle-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

Utilisez l'utilitaire pg_dump pour créer une sauvegarde. Pour en savoir plus sur l'utilisation de cet utilitaire pour importer et exporter des données, consultez les ressources suivantes :

Tâches de migration de Database Migration Service

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

Testez toutes les conditions préalables pour vous assurer que le job peut s'exécuter correctement. Choisissez un moment où vos charges de travail peuvent tolérer une courte interruption pour la migration et le basculement en production.

Dans Database Migration Service, la migration commence par le vidage et la restauration du schéma initial sans index ni contraintes, suivis de l'opération de copie des données. Une fois la copie des données terminée, les index et les contraintes sont restaurés. Enfin, la réplication continue des modifications de l'instance de base de données source vers l'instance de base de données de destination est lancée.

Database Migration Service utilise l'extension pglogical pour la réplication de votre base de données source vers l'instance de base de données cible. Au début de la migration, cette extension configure la réplication en exigeant des verrous exclusifs à court terme sur toutes les tables de votre instance Amazon RDS ou Amazon Aurora source. C'est pourquoi nous vous recommandons de lancer la migration lorsque la base de données est la moins occupée et d'éviter les instructions sur la source pendant la phase de dump et de réplication, car les instructions LDD ne sont pas répliquées. Si vous devez effectuer des opérations LDD, utilisez les fonctions "pglogical" pour exécuter des instructions LDD sur votre instance source ou exécutez manuellement les mêmes instructions LDD sur l'instance cible de la migration, mais uniquement une fois l'étape de dump initial terminée.

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

Pour obtenir des instructions détaillées sur la configuration de la migration, consultez les guides de démarrage rapide pour PostgreSQL et PostgreSQL vers AlloyDB pour PostgreSQL.

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

Cloud SQL est compatible avec deux types de réplication logique : la réplication logique intégrée de PostgreSQL et la réplication logique via l'extension pglogical. Pour AlloyDB pour PostgreSQL, nous vous recommandons d'utiliser l'extension pglogical pour la réplication. Chaque type de réplication logique possède ses propres caractéristiques et limites.

La réplication logique intégrée présente les caractéristiques et les limites suivantes :

  • Elle est disponible dans PostgreSQL 10 et versions ultérieures.
  • Toutes les modifications et les colonnes sont répliquées. Les publications sont définies au niveau de la table.
  • Les données ne sont répliquées que des tables de base vers les tables de base.
  • Il n'effectue pas de réplication de séquence.
  • Il s'agit du type de réplication recommandé lorsqu'il existe de nombreuses tables sans clé primaire. Configurer la réplication logique PostgreSQL intégrée Pour les tables sans clé primaire, appliquez le formulaire REPLICA IDENTITY FULL afin que la réplication intégrée utilise l'intégralité de la ligne comme identifiant unique au lieu d'une clé primaire.

La réplication logique pglogical présente les caractéristiques et limites suivantes :

  • Elle est disponible dans toutes les versions de PostgreSQL et offre une compatibilité entre les versions.
  • Le filtrage des lignes est disponible au niveau de la source.
  • Il ne réplique pas les tables UNLOGGED et TEMPORARY.
  • Une clé primaire ou unique est requise dans les tables pour enregistrer les modifications apportées à UPDATE et DELETE.
  • La réplication de séquence est disponible.
  • La réplication différée est possible.
  • Elle permet de détecter les conflits et de les résoudre de manière configurable en cas de présence de plusieurs éditeurs ou de conflits entre les données répliquées et les modifications locales.

Pour savoir comment configurer la réplication logique PostgreSQL intégrée à partir d'un serveur externe tel qu'Amazon RDS ou Amazon Aurora pour PostgreSQL, consultez les ressources suivantes :

Outils tiers

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

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

Vous utilisez un ou plusieurs flux pour organiser ces processus de migration dans vos applications personnalisées. Pour coder vos applications personnalisées, vous pouvez utiliser un outil de programmation graphique ou le langage de programmation TQL (Tungsten Query Language).

Pour en savoir plus sur l'utilisation de Striim, consultez les ressources suivantes :

Si vous décidez d'utiliser Striim pour migrer vos données, consultez les guides suivants sur l'utilisation de Striim pour migrer des données vers Google Cloud :

Définir des scénarios de remplacement

Définissez des actions de secours pour chaque tâche d'exécution de la migration, afin de vous prémunir contre les problèmes imprévus qui pourraient survenir pendant le processus de migration. Les tâches de secours dépendent généralement de la stratégie de migration et des outils utilisés.

La solution de repli peut nécessiter un effort considérable. Nous vous recommandons de ne pas effectuer de transition vers la 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 secours doivent être correctement testés pour éviter une panne grave.

Définissez des critères de réussite et limitez dans le temps toutes vos tâches d'exécution de la migration. Effectuer un test de migration vous aide à recueillir des informations sur les délais 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 l'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 échoueraient en cours de route. Selon le temps d'arrêt planifié qui s'est écoulé, vous devrez peut-être reporter la migration si la tâche de migration ne se termine pas dans le délai prévu.

Un plan de secours consiste généralement à annuler 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 complète des bases de données, y compris la planification et les tests.

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

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

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 retour à l'état précédent 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 dans 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 dans 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 à votre système de base de données source initial ultérieurement, en particulier si vos charges de travail ne dépendent pas d'une heure de création d'enregistrement spécifique ni de contraintes d'ordre chronologique.

Réplication inverse

Avec cette stratégie, vous répliquez les écritures qui se produisent dans votre nouvelle base de données cible après le transfert de production vers votre base de données source initiale. De cette façon, vous maintenez la synchronisation de la source d'origine avec la nouvelle base de données cible et les écritures ont lieu 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 tant que vous n'avez pas basculé vers l'instance de base de données cible. Par conséquent, il ne permet pas d'effectuer des tests de bout en bout et il présente une courte période sans possibilité de retour en arrière.

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

Transfert de la réplication

Cette stratégie est une variante de la réplication inversée. Vous répliquez les écritures sur votre nouvelle base de données cible vers une instance de base de données tierce de votre choix. Vous pouvez rediriger 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 un fallback à 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 secours 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 dans les instances de base de données source et cible initiales, ce qui vous permet d'effectuer une transition progressive vers la production jusqu'à ce que vous n'utilisiez plus que vos instances de base de données cible. En cas de problème, vous 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 estimez que la migration a été effectuée sans problème.

Nous recommandons cette approche lorsqu'il est essentiel de ne pas avoir de temps d'arrêt de la migration, de disposer d'un fallback fiable et lorsque vous avez le temps et les ressources nécessaires pour effectuer le refactoring de l'application.

Effectuer des tests et des validations

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

  • Migration réussie des données de la base de données.
  • Intégration aux applications existantes une fois qu'elles sont passées à l'utilisation de la nouvelle instance cible.

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

  • Les 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 les données déjà agrégées, redondantes, archivées ou anciennes. Vous pouvez archiver ces données dans un bucket Cloud Storage, en guise de sauvegarde.
  • 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 des attentes définies.

Il est possible que les configurations de stockage de votre environnement source ne correspondent pas directement aux cibles d'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, évaluez vos instances sources lors des phases d'évaluation et de validation.

Lors du processus de benchmarking, vous appliquez des séquences d'opérations semblables à celles de production aux instances de base de données. Pendant cette période, 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 de consulter les données 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 de benchmarking 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 large communauté d'utilisateurs. Vous pouvez partager et comparer les résultats de plusieurs moteurs de base de données et configurations de stockage. Pour en savoir plus, consultez les pages Tests de charge SQL Server avec HammerDB et Benchmark des performances Amazon RDS SQL Server avec HammerDB.
  • Outil de benchmark DBT2 : outil de benchmarking spécialisé pour MySQL. Un ensemble de kits de charge de travail de base de données imite une application pour une entreprise qui possède des entrepôts et implique un mélange de transactions de lecture et d'écriture. Utilisez cet outil si vous souhaitez utiliser un test de charge de traitement 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 et autres). Toutefois, l'exécution des tests peut parfois être lente, en fonction de la taille et de la complexité de la base de données. Nous vous recommandons cet outil si la simplicité est importante.
  • DbFit : framework de test de base de données Open Source qui prend en charge le développement de code axé sur les tests et les tests automatisés. Il utilise une syntaxe de base pour créer des cas de test et propose des tests axés sur les données, le contrôle des versions et le reporting des résultats des tests. Toutefois, la compatibilité avec les requêtes et les transactions complexes est limitée. De plus, contrairement à d'autres outils, il ne bénéficie pas d'une grande communauté ni d'une documentation complète. 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 déploiement continus.

Pour exécuter un test de bout en bout, y compris un test du plan de migration, effectuez toujours une simulation de migration. Une simulation exécute la migration de base de données à grande échelle sans basculer les charges de travail de production. Elle offre les avantages suivants :

  • Vous permet de vous assurer que tous les objets et configurations sont correctement migrés.
  • Vous aide à définir et à exécuter vos scénarios de test de migration.
  • Fournit des informations sur le temps nécessaire à la migration proprement dite, ce qui vous permet de calibrer votre calendrier.
  • Il s'agit d'une occasion de tester, valider et adapter le plan de migration. Parfois, vous ne pouvez pas tout planifier à l'avance. Cette étape vous aide donc à identifier les éventuelles lacunes.

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

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

  • Comparez les schémas source et cible. Vérifiez si toutes les tables et 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 sont passées à la base de données cible (les données migrées sont lues via l'application).
  • Effectuez des tests d'intégration entre les applications migré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 celles nouvellement créées.
  • Testez les performances des requêtes de base de données les plus utilisées pour voir si elles se sont dégradées en raison de configurations incorrectes ou d'un dimensionnement inapproprié.

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

Si vous utilisez Database Migration Service comme outil de migration, consultez la version PostgreSQL ou PostgreSQL vers AlloyDB pour PostgreSQL de la section "Valider une migration".

Outil de validation des données

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

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

DVT couvre de nombreuses Google Cloud sources de données, 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 personnalisée des résultats de requête

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

Effectuer la migration

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

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

  • Informez les équipes concernées chaque fois qu'une étape du plan commence et se termine.
  • Si l'une des étapes prend plus de temps que prévu, comparez le temps écoulé avec la durée maximale allouée à cette étape. Dans ce cas, informez régulièrement les é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 "go ou no-go" pour chaque étape du plan de migration et de transition.
  • Envisagez des actions de rétablissement ou des scénarios alternatifs pour chacune des étapes.

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

Effectuer le basculement en production

Le processus de transition vers la production de haut niveau peut varier en fonction de la stratégie de migration choisie. Si vous pouvez tolérer un temps d'arrêt de vos charges de travail, le transfert 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 générales suivantes dans le processus de basculement :

  • Arrêtez toute écriture de données dans 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 devez les valider 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 la validation des données conforme à vos critères, vous pouvez effectuer le basculement au niveau de l'application. Déployez les charges de travail qui ont été refactorisées pour utiliser la nouvelle instance cible. Vous déployez les versions de vos applications qui pointent vers la nouvelle instance de base de données cible. Les déploiements peuvent être effectués par le biais de mises à jour progressives, de déploiements par étapes ou à l'aide d'un modèle de déploiement bleu-vert. Il est possible que l'application soit indisponible pendant un certain temps.

Suivez les bonnes pratiques pour votre transition vers la 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 secours.
  • 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.
  • Gardez à l'esprit que l'effort nécessaire pour annuler la migration peut être supérieur à celui requis pour résoudre les problèmes qui apparaissent dans l'environnement cible.

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

Une fois la bascule terminée, 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 respecter 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'ils correspondent à ceux que vous avez collectés 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 secours, vous pouvez implémenter la réplication de vos écritures sur l'instance Cloud SQL vers votre base de données source d'origine. La configuration ressemble au processus de migration, mais s'exécute à l'inverse : la base de données source initiale deviendrait la nouvelle cible.

Pour que les instances sources restent à jour après le basculement, il est recommandé de répliquer les écritures effectuées sur les instances Cloud SQL cibles dans la base de données source. Si vous devez effectuer un rollback, vous pouvez revenir à vos anciennes instances sources avec une perte de données minimale.

Vous pouvez également utiliser une autre instance et y répliquer vos modifications. Par exemple, lorsque AlloyDB pour PostgreSQL est une destination de migration, envisagez de configurer la réplication vers une instance Cloud SQL pour PostgreSQL pour les scénarios de secours.

En plus du nettoyage de l'environnement source, les configurations critiques suivantes pour vos instances Cloud SQL pour PostgreSQL doivent être effectuées :

  • 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 de l'instance de sorte à disposer d'au moins 20 % d'espace disponible pour prendre en charge toutes les opérations de maintenance de base de données critiques que Cloud SQL peut effectuer. Pour recevoir une alerte si l'espace disque disponible est inférieur à 20 %, créez une règle d'alerte basée sur les métriques pour la métrique d'utilisation du disque.

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

Pour en savoir plus sur la maintenance et les bonnes pratiques concernant les instances Cloud SQL pour PostgreSQL et AlloyDB pour PostgreSQL, consultez les ressources suivantes :

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

Optimiser votre environnement après la migration

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

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

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

Pour en savoir plus sur l'optimisation de votre environnement Google Cloud , consultez Migrer vers Google Cloud : optimiser votre environnement et FrameworkGoogle Cloud Well-Architected : 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éliorer la fiabilité et la disponibilité de votre base de données

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

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 services disponibles. Vous avez le choix entre les options suivantes :

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

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

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

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

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

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

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

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

Lorsque vous migrez depuis Amazon RDS et Aurora pour PostgreSQL vers Cloud SQL pour PostgreSQL, tenez compte des consignes suivantes :

  • Utilisez la mise en cache pour améliorer les performances de lecture. Inspectez les différentes statistiques de la vue pg_stat_database. Par exemple, le ratio blks_hit / (blks_hit + blks_read) doit être supérieur à 99 %. Si ce ratio n'est pas supérieur à 99 %, envisagez d'augmenter la taille de la mémoire RAM de votre instance. Pour en savoir plus, consultez la page Outil de collecte de statistiques PostgreSQL.
  • Récupérez de l'espace et évitez les mauvaises performances d'index. En fonction de la fréquence à laquelle vos données changent, définissez une programmation pour exécuter la commande VACUUM sur votre instance Cloud SQL pour PostgreSQL.
  • Utilisez l'édition Cloud SQL Enterprise Plus pour augmenter les limites de configuration des machines et le cache de données. Pour en savoir plus sur Cloud SQL Enterprise Plus, consultez la page Présentation des éditions Cloud SQL.
  • Passez à AlloyDB pour PostgreSQL. Si vous changez de base de données, vous pouvez bénéficier d'une compatibilité totale avec PostgreSQL, d'un meilleur traitement transactionnel et de charges de travail d'analyse transactionnelle rapides sur votre base de données de traitement. Vous recevez également une recommandation pour de nouveaux index grâce à la fonctionnalité de conseiller d'index.

Pour en savoir plus sur l'amélioration des performances de votre infrastructure de base de données Cloud SQL pour PostgreSQL, consultez la documentation sur l'amélioration des performances de Cloud SQL pour PostgreSQL.

Lorsque vous migrez depuis Amazon RDS et Aurora pour PostgreSQL vers AlloyDB pour PostgreSQL, tenez compte des consignes suivantes pour améliorer les performances de votre instance de base de données AlloyDB pour PostgreSQL :

Augmenter les capacités d'observabilité des bases de données

Diagnostiquer et résoudre les problèmes dans les applications qui se connectent à des instances de base de données peut être difficile et chronophage. 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 sur votre service et les 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.

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

Pour en savoir plus sur l'amélioration de l'observabilité de votre infrastructure de base de données, consultez les sections suivantes de la documentation :

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

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

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

  • Si vous avez des instances volumineuses, nous vous recommandons de les diviser 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 tenir compte de 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 consignes ci-dessous jusqu'à ce que votre problème soit résolu :

Augmenter la capacité de l'infrastructure : augmentez les ressources (comme le débit du disque, les vCPU et la RAM). En fonction de l'urgence, de la disponibilité et de l'expérience de votre équipe, le scaling vertical de votre instance peut résoudre la plupart des problèmes de performances. Vous pourrez ensuite examiner plus en détail la cause première du problème dans un environnement de test et envisager des options pour l'éliminer.

Effectuez et planifiez des opérations de maintenance de la base de données : défragmentation de l'index, mise à jour des statistiques, analyse du vide et réindexation des tables fréquemment mises à jour. Vérifiez si et quand ces opérations de maintenance ont été effectuées pour la dernière fois, en particulier sur les objets concernés (tables, index). Déterminez si une modification a été apportée aux activités normales de la base de données. Par exemple, si vous avez récemment ajouté une colonne ou apporté de nombreuses modifications à une table.

Ajustez et optimisez votre 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 ? Vérifiez les analyses d'index, les verrous et les attentes sur les 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. Il peut varier de quelques heures à quelques 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.

Reconcevez l'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 être 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é constitue 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éarchitecturer votre base de données et vos applications d'une manière spécifique, et d'effectuer la migration des données. Vous divisez votre instance de base de données en plusieurs instances plus petites à l'aide de critères de partitionnement spécifiques. Les critères peuvent être basés sur le client ou le sujet. Cette option vous permet de faire évoluer horizontalement vos opérations d'écriture et de lecture. Toutefois, cela augmente la complexité de vos charges de travail de base de données et d'application. Cela peut également entraîner des partitions déséquilibrées appelées points chauds, ce qui annulerait l'avantage du partitionnement.

Pour Cloud SQL pour PostgreSQL et AlloyDB pour PostgreSQL, tenez compte des bonnes pratiques suivantes :

  • Pour décharger le trafic de l'instance principale, ajoutez des instances répliquées avec accès en lecture. Vous pouvez également utiliser un équilibreur de charge tel que HAProxy pour gérer le trafic vers les instances répliquées. Toutefois, évitez d'avoir trop d'instances répliquées, car cela entrave l'opération VACUUM. Pour en savoir plus sur l'utilisation de HAProxy, consultez le site Web officiel HAProxy.
  • Optimisez l'opération VACUUM en augmentant la mémoire système et le paramètre maintenance_work_mem. L'augmentation de la mémoire système signifie que davantage de tuples peuvent être regroupés dans chaque itération.
  • Les index plus volumineux peuvent prendre beaucoup de temps à analyser. Par conséquent, définissez le paramètre INDEX_CLEANUP sur OFF pour procéder rapidement au nettoyage et figer les données de la table.
  • Lorsque vous utilisez AlloyDB pour PostgreSQL, utilisez le tableau de bord et les journaux d'audit des insights système d'AlloyDB pour PostgreSQL. Le tableau de bord des insights système d'AlloyDB pour PostgreSQL affiche les métriques des ressources que vous utilisez et vous permet de les surveiller. Pour en savoir plus, consultez les consignes de la section Surveiller les instances dans la documentation AlloyDB pour PostgreSQL.

Pour en savoir plus, consultez les ressources suivantes :

Étapes suivantes

Contributeurs

Auteurs :

Autre contributeur : Somdyuti Paul | Spécialiste de la gestion des données