Ce document décrit comment configurer et exécuter une migration de bases de données, et comment corriger les échecs. Il s'agit de la seconde partie d'une série comprenant deux volets. La partie 1 présente les concepts, les principes et la terminologie de la migration de bases de données avec un temps d'arrêt quasiment nul pour les architectes cloud qui doivent migrer des bases de données vers Google Cloud depuis des environnements sur site ou d'autres environnements cloud.
Configuration de la migration de bases de données
Cette section décrit les différentes phases d'une migration de bases de données. Commencez par configurer la migration. Ensuite, une fois la procédure de migration et de basculement des clients vers les bases de données cibles terminée, vous pouvez soit supprimer les bases de données sources, soit mettre en œuvre un plan de remplacement. Cela peut s'avérer nécessaire si vous rencontrez des problèmes de migration après le basculement. Un remplacement permet d'assurer la continuité de l'activité.
Lors de la migration, vous devez accorder une attention particulière aux modifications qui pourraient survenir dans le schéma ou les données. Pour plus d'informations sur l'impact de ces modifications, consultez la section Modifications dynamiques pendant la migration plus loin dans ce document.
Spécification du schéma cible
Pour chaque système de base de données cible, vous devez définir et créer son schéma. En cas de migrations de bases de données homogènes, vous pouvez créer cette spécification plus rapidement en exportant le schéma de la base de données source dans la base de données cible, ce qui crée le schéma de la base de données cible.
La manière dont vous nommez votre schéma est importante. Une option consiste à choisir un nom de schéma cible correspondant au nom du schéma source. Cependant, même si elle simplifie le basculement des clients, cette approche peut induire en erreur les utilisateurs si les outils se connectent simultanément aux schémas de bases de données sources et cibles, par exemple pour comparer des données. Si vous générez des noms de schémas abstraits à l'aide d'un fichier de configuration, attribuer aux schémas de base de données cibles des noms différents de la source permet de les différencier plus facilement.
En cas de migrations de bases de données hétérogènes, vous devez créer chaque schéma de base de données cible. Ce processus d'ingénierie peut nécessiter plusieurs itérations. Pour pouvoir mettre en œuvre la migration, vous devrez peut-être modifier les schémas afin de les adapter à votre processus de migration et aux éventuelles modifications de données.
Comme vous allez probablement créer des bases de données cibles plusieurs fois lors du test et de l'exécution de votre migration, le processus de création du schéma doit être reproductible (idéalement via des scripts d'installation). Vous pouvez utiliser un système de gestion de code pour contrôler la version des scripts, assurer la cohérence et accéder à l'historique des modifications des scripts.
Sémantique de migration et d'exécution des requêtes
À terme, vous devez basculer l'accès des clients des systèmes de base de données sources vers les systèmes de base de données cibles. Dans les intégrations de bases de données homogènes, les requêtes peuvent demeurer inchangées si les schémas ne sont pas modifiés. Bien que les clients doivent être testés sur les systèmes de base de données cibles, ils ne doivent pas être modifiés en raison de requêtes.
Pour les migrations de bases de données hétérogènes en général, vous devez modifier les requêtes, car les schémas diffèrent entre les bases de données source et cible. Cette différence peut être due à une non-concordance du type de données entre les bases de données source et cible. En outre, les fonctionnalités du langage de requête disponibles dans les systèmes de base de données sources peuvent ne pas être toutes disponibles dans les systèmes de base de données cibles, ou inversement. Dans des cas extrêmes, vous devrez peut-être convertir une requête d'un système de base de données source en plusieurs requêtes sur le système cible. Dans le scénario inverse, où davantage de fonctionnalités de langage de requête sont disponibles dans la base de données cible que dans la source, vous devrez peut-être combiner plusieurs requêtes de la base de données source en une seule requête sur la base de données cible correspondante.
La sémantique des requêtes peut également différer. Par exemple, certains systèmes de base de données matérialisent une mise à jour dans une transaction immédiatement dans cette transaction. Ainsi, lorsque le même élément de données est lu, la valeur mise à jour est récupérée. D'autres systèmes ne matérialisent pas immédiatement une mise à jour et attendent le commit de la transaction. Si la logique du système de base de données source repose sur la matérialisation de l'écriture, la même logique sur la base de données cible peut provoquer des erreurs de données, voire des échecs.
Si vous devez migrer des requêtes, vous devez tester toutes les fonctionnalités pour vous assurer que le comportement des clients est le même avant et après la migration. Vous pouvez également effectuer des tests au niveau des données, mais ces tests ne remplacent pas ceux effectués au niveau du client. Les clients exécutent des requêtes du point de vue de la logique métier et ne peuvent être testés qu'au niveau de celle-ci.
Processus de migration
Pour les migrations de bases de données hétérogènes, les processus de migration spécifient la manière dont les données extraites des systèmes de base de données sources sont modifiées et insérées dans les bases de données cibles. Les modifications de données, telles que celles décrites dans la section Modifications des données de ce document, sont définies et exécutées tandis que les éléments de données sont extraits des bases de données sources et transférés vers les bases de données cibles.
Avec les migrations de bases de données homogènes, lorsque les schémas des bases de données sources et cibles sont équivalents, la modification des données n'est pas nécessaire. Les données sont insérées dans les bases de données cibles telles qu'elles ont été extraites des bases de données sources.
En fonction de votre système de migration de bases de données, plusieurs configurations peuvent être requises. Par exemple, vous devez indiquer si les données modifiées et transférées doivent être stockées de manière temporaire dans le système de migration de bases de données. Le stockage des données peut ralentir le processus de migration global, mais accélérer considérablement la récupération en cas d'échec. Vous devrez peut-être spécifier le type de validation. Par exemple, certains systèmes de migration de bases de données interrogent les systèmes sources et cibles pour établir l'équivalence de l'ensemble de données migré jusqu'au moment de la requête. La gestion des erreurs nécessite que vous spécifiiez un comportement de récupération après échec. Encore une fois, cette exigence dépend du système de migration de bases de données utilisé.
Il va sans dire que vous devez tester votre migration de données de manière approfondie et répétée. Dans l'idéal, votre migration est testée pour s'assurer que chaque élément de données connu est migré, qu'aucune erreur de modification des données ne se produit, que les performances et le débit sont suffisants, et que le délai de migration peut être atteint.
Processus de remplacement
Lors d'une migration de bases de données, les bases de données sources demeurent opérationnelles (sauf si la migration implique un temps d'arrêt planifié). Si la migration de bases de données échoue à un moment, vous pouvez (dans le pire des scénarios) l'annuler et rétablir l'état initial de la base de données cible. Une fois les échecs résolus, vous pouvez redémarrer la migration de bases de données. Ces échecs et leur résolution n'affectent pas les systèmes de base de données sources opérationnels.
Si des échecs surviennent après la migration de bases de données et le basculement des clients vers les bases de données cibles, le processus d'échec et de résolution peut avoir un impact sur ces clients et les empêcher de fonctionner correctement. Dans le meilleur des cas, l'échec est résolu rapidement et le temps d'arrêt des clients est court. Dans le pire des cas, l'échec n'est pas résolu, ou la résolution prend beaucoup de temps et vous devez rebasculer les clients vers les bases de données sources.
Pour rebasculer les clients vers les bases de données sources, vous devez migrer toutes les modifications de données effectuées sur les bases de données cibles vers les bases de données sources. Vous pouvez configurer et exécuter ce processus en tant que migration de bases de données complète et distincte. Toutefois, étant donné que les clients ne sont pas opérationnels sur les bases de données cibles à ce stade, des temps d'arrêt importants seront engendrés.
Pour éviter les temps d'arrêt des clients dans ce scénario, vous devez démarrer vos processus de migration immédiatement après la migration de bases de données d'origine. Chaque modification appliquée aux systèmes de base de données cibles est immédiatement appliquée aux systèmes de base de données sources. Cette approche garantit que les systèmes de base de données cibles et sources sont synchronisés en permanence.
La préparation d'un remplacement des bases de données cibles par les bases de données sources nécessite un effort considérable. Il est essentiel que vous décidiez si vous devez mettre en œuvre et tester des processus de remplacement, ou que vous soyez conscient des conséquences si vous ne le faites pas, à savoir des temps d'arrêt importants.
Exécution d'une migration de bases de données
L'exécution d'une migration de bases de données implique cinq phases distinctes, décrites dans cette section. Une sixième phase consiste à effectuer un remplacement, mais elle est considérée comme une exception à l'exécution normale d'une migration de bases de données.
Le processus décrit dans cette section est une migration de bases de données hétérogène avec un temps d'arrêt quasiment nul. Si vous êtes en mesure de supporter des temps d'arrêt importants, vous pouvez combiner les trois premières phases (chargement initial, migration continue et drainage) en une seule phase en adoptant une approche de sauvegarde et de restauration ou d'exportation et d'importation.
Une migration de bases de données homogène constitue un cas particulier. Avec ce type de migration, vous pouvez utiliser la fonctionnalité de réplication du système de gestion de bases de données (pour les systèmes compatibles) qui migre les données alors que les systèmes de base de données sources demeurent opérationnels.
Les phases exposées ici décrivent une approche que vous devrez peut-être modifier en fonction des exigences de votre processus de migration de bases de données.
Phase 1 : chargement initial
Le point de départ consiste à migrer toutes les données spécifiées pour la migration depuis toutes les bases de données sources. Au début de la migration des données, les bases de données sources ont un état spécifique, qui change pendant la migration.
Si vous démarrez une migration tandis que des modifications se produisent simultanément, nous vous conseillons de noter l'heure du système de base de données juste avant l'extraction du premier élément de données. Vous pouvez ainsi extraire toutes les modifications de bases de données à partir du journal de transactions à compter de cet horodatage. En outre, le chargement initial doit lire un état de base de données cohérent pour toutes les données. Vous devrez peut-être verrouiller la base de données pendant un court moment afin d'empêcher la lecture d'un ensemble de données incohérent.
Cette phase comprend les étapes suivantes :
- Enregistrement de l'heure du système de base de données juste avant le début de la migration de bases de données.
- Exécution d'un processus de migration avec chargement initial qui interroge l'ensemble de données (complet ou partiel) à partir des bases de données sources à migrer, puis migration de l'ensemble de données. Dans un modèle de base de données relationnelle, les processus de migration avec chargement initial exécutent des requêtes telles que
SELECT *, ou des requêtes avec sélection, avec projection, ou les deux. Le processus de migration effectue la modification des données comme indiqué.
Pendant l'exécution des processus de migration avec chargement initial, les clients apportent généralement des modifications aux bases de données sources. Étant donné que vous enregistrez l'heure du système de base de données au démarrage, vous pourrez extraire ces modifications du journal de transactions ultérieurement.
Le résultat de la phase de chargement initial est la migration complète de l'ensemble de données initial depuis les systèmes de base de données sources vers les systèmes de base de données cibles. Cependant, les bases de données sources et cibles ne sont pas encore synchronisées, car les clients ont probablement modifié les bases de données sources lors de la migration. La phase 2 implique la capture et la migration de ces modifications.
Phase 2 : migration continue
La migration continue a deux objectifs. Tout d'abord, elle lit les modifications apportées aux bases de données sources après le démarrage du chargement initial. Ensuite, elle capture ces modifications et les transfère vers les bases de données cibles.
Cette phase comprend les étapes suivantes :
- Démarrage des processus de migration continue à partir de l'heure du système de base de données enregistrée lors de la phase 1. La migration lit le journal de transactions à partir de cet horodatage et applique chaque modification au système de base de données cible.
- Exécution de toute modification de données. Le processus de migration effectue cette étape selon vos spécifications.
Les modifications consignées après l'heure du système de base de données sont parfois transférées lors du chargement initial. Par conséquent, il est possible que ces modifications puissent être appliquées une seconde fois pendant la migration continue. Vous devez définir vos processus de migration pour vous assurer que les modifications ne sont pas appliquées deux fois, par exemple à l'aide d'identifiants. Supposons qu'un élément de données modifié soit transféré lors du chargement initial et que l'insertion soit consignée dans le journal de transactions. En appliquant un identifiant à l'élément de données, le système de migration peut déterminer à partir du journal de transactions qu'une autre insertion n'est pas nécessaire, car l'élément de données existe déjà.
Le résultat de la phase de migration continue est la synchronisation complète ou quasi complète des bases de données cibles avec les bases de données sources. Lorsqu'une modification d'un système de base de données source n'est pas migrée, vous disposez d'une base de données presque synchronisée.
Selon la configuration de votre système de migration de bases de données, les écarts peuvent être minimes ou importants. Par exemple, pour augmenter l'efficacité, les modifications ne doivent pas toutes être migrées immédiatement. Sinon, vous pouvez créer une charge importante sur la source en cas de pic des modifications apportées à celle-ci. En général, les modifications sont collectées et migrées par lot sous forme d'opérations groupées. Avec des lots plus petits, les écarts entre la source et la cible sont moins importants, mais votre source peut être soumise à une charge plus élevée si des modifications sont fréquemment effectuées.
Si la taille des lots est configurée de manière dynamique, il est préférable de synchroniser les lots plus volumineux au début de la phase de migration continue, puis de synchroniser des lots d'une taille progressivement réduite lorsque le rapprochement des bases de données est presque atteint. Cette méthode rend le processus de rapprochement plus efficace et réduit ultérieurement l'écart entre les bases de données sources et cibles.
Phase 3 : drainage
Pour préparer le basculement des clients des bases de données sources vers les bases de données cibles, vous devez vous assurer que les bases de données sources et cibles sont entièrement synchronisées. Le drainage est le processus de migration des modifications restantes des bases de données sources vers les bases de données cibles.
Cette phase comprend les étapes suivantes :
- Suspension des systèmes de base de données sources. Cela signifie qu'aucune modification des données ne peut être apportée dans la base de données source et que le journal de transactions ne reçoit pas d'autres entrées de modification.
- Attente de la migration de toutes les modifications vers les bases de données cibles. Ce processus correspond au drainage réel des modifications.
- Une fois le drainage terminé, sauvegarde des bases de données cibles afin d'avoir un point de départ défini pour les futures sauvegardes incrémentielles.
Le résultat de la phase de drainage est la synchronisation des systèmes de base de données sources et cibles, et l'absence de modification des données.
Pour garantir que le drainage est terminé, un élément de données de "dernière insertion" peut être écrit dans une base de données source. Lorsque cet élément de données apparaît dans la base de données cible correspondante, cela signifie que la phase de drainage est terminée.
Phase 4 : basculement
Une fois la phase de drainage terminée, vous pouvez basculer les clients des bases de données sources vers les bases de données cibles. Nous vous recommandons de respecter les bonnes pratiques suivantes :
- Avant d'activer l'accès à la base de données de production, testez les fonctionnalités de base afin de vous assurer que les clients sont opérationnels et fonctionnent comme prévu. Le nombre de scénarios de test détermine le temps d'arrêt réel de votre base de données de production.
- Sauvegardez les bases de données cibles avant d'activer l'accès des clients. Cette bonne pratique garantit que l'état initial des bases de données cibles peut être récupéré.
À la fin du basculement, les clients sont entièrement opérationnels et commencent à accéder aux bases de données de production (appelées bases de données cibles jusqu'à présent dans ce document).
Phase 5 : suppression des bases de données sources
Une fois le basculement vers les bases de données de production terminé, vous pouvez supprimer les bases de données sources. Il est recommandé d'effectuer une sauvegarde finale de chaque base de données source afin que vous disposiez d'un état terminal défini qui soit accessible. La réglementation concernant les données peut également exiger des sauvegardes finales pour des raisons de conformité.
Phase 6 : remplacement
La mise en œuvre d'un remplacement, en particulier pour les clients de base de données essentiels, peut constituer une bonne protection contre les problèmes liés à votre migration. Un remplacement est comme une migration, mais en sens inverse. Autrement dit, dans le cadre d'un remplacement, vous configurez une migration des bases de données cibles vers les bases de données sources. Avec les migrations de bases de données hétérogènes, la création de remplacement est plus complexe. C'est pourquoi nous vous recommandons d'effectuer la commutation qu'après avoir testé minutieusement que votre processus de migration de base de données, ainsi que vos applications connectées à la base de données cible, respectent vos contrats de niveau de service.
Après avoir drainé les bases de données sources et sauvegardé toutes les bases de données, vous pouvez activer les processus de migration qui identifient les modifications survenues dans les bases de données cibles et les migrent vers les bases de données sources avant le basculement.
La création de ces processus de migration garantit que les bases de données sources sont synchronisées et que l'état des données est mis à jour une fois que les clients ont modifié les bases de données cibles. Un remplacement peut être nécessaire quelques jours ou semaines après le basculement. Par exemple, les clients peuvent accéder aux fonctionnalités pour la première fois et être bloqués en raison de fonctionnalités défaillantes qui ne peuvent pas être corrigées rapidement. Dans ce cas, les clients peuvent revenir à l'accès aux bases de données sources. Avant cela, toutes les modifications apportées aux bases de données cibles doivent être drainées dans les bases de données sources.
Avec cette approche, certains cas de figure nécessitent une attention particulière :
- Vous devez concevoir les schémas cibles afin qu'une migration inverse (des bases de données cibles vers les bases de données sources) soit possible. Par exemple, si votre processus de migration initial (de la source vers la cible) comporte des jointures ou des agrégations, une migration inverse est complexe, voire impossible. Dans ce cas, les données individuelles doivent également être disponibles dans les bases de données cibles.
- Un problème peut survenir lorsque les bases de données sources comportent des journaux de transactions, mais que les bases de données cibles ne fournissent pas ce type de fonctionnalité non fonctionnelle. Dans ce cas, une migration inverse (de la cible vers la source) doit s'appuyer sur des requêtes différentielles. Cette configuration doit être conçue et préparée dans les schémas de bases de données cibles.
- Les clients qui utilisaient initialement les bases de données sources doivent demeurer disponibles et opérationnels pour pouvoir être activés dans le cadre d'un remplacement. Toutes les modifications fonctionnelles apportées aux clients accédant aux bases de données cibles doivent également être apportées aux clients accédant aux bases de données sources afin de garantir une équivalence fonctionnelle.
Bien qu'un remplacement soit une opération à effectuer en dernier recours, sa mise en œuvre est essentielle et doit être traitée comme une migration complète des bases de données, ce qui inclut des tests.
Modifications dynamiques pendant la migration
En général, les bases de données sont des systèmes dynamiques, car le schéma et les valeurs de données peuvent changer. Les schémas de base de données peuvent changer en fonction de facteurs tels que les exigences métier. Quant aux valeurs des données, elles peuvent changer en même temps que les modifications de schéma, ou indépendamment. Les changements de valeur des données peuvent se produire de manière dynamique à tout moment avec les modifications correspondantes de la mise en œuvre d'une application. Les sections suivantes présentent certaines des modifications possibles et leurs conséquences pour une migration de bases de données.
Modifications du schéma
Les bases de données peuvent être classées en systèmes nécessitant un schéma prédéfini ou systèmes sans schéma. En général, les systèmes qui nécessitent un schéma prédéfini sont compatibles avec les opérations de modification du schéma, par exemple, l'ajout d'attributs ou de colonnes dans un système relationnel.
Dans ces systèmes, vous contrôlez les modifications via un processus de gestion des modifications. Ce type de processus permet d'effectuer des modifications de manière contrôlée. Toutes les opérations qui dépendent du schéma, telles que les requêtes ou les processus de migration de données, sont modifiées simultanément pour garantir une modification globale cohérente.
Les systèmes de base de données qui ne nécessitent pas de schéma prédéfini peuvent être modifiés à tout moment. Une modification du schéma ne peut pas être effectuée uniquement par un utilisateur autorisé. Dans certains cas, elle est possible par programmation. Dans ce cas, le schéma peut être modifié à tout moment. Les opérations qui dépendent du schéma peuvent échouer (par exemple, des requêtes ou des processus de migration de données). Pour éviter les modifications de schéma non contrôlées dans ces systèmes de base de données, vous devez mettre en œuvre un processus de gestion des modifications en tant que convention et règle acceptée plutôt que par application du système.
Modifications des données
En général, les schémas contrôlent les valeurs de données possibles pour les différents attributs de données. Les systèmes sans schéma n'ont aucune contrainte sur les valeurs des données.
Dans les deux cas, des valeurs de données qui n'étaient pas stockées auparavant peuvent apparaître. Par exemple, les types d'énumération sont souvent mis en œuvre sous la forme d'un ensemble de chaînes dans les systèmes de base de données. Au niveau du langage de programmation, ils peuvent être mis en œuvre dans les clients en tant que types d'énumération réels, mais pas nécessairement. Il est possible qu'un client stocke ce qu'il considère comme une valeur d'énumération valide, mais que d'autres clients ne considèrent pas comme valide. En outre, un processus de migration de données peut détourner sa fonctionnalité des valeurs d'énumération. Si de nouvelles valeurs apparaissent, le processus de migration des données peut échouer.
Un autre exemple réside dans le stockage des structures JSON. Dans de nombreux cas, les structures JSON sont stockées dans une chaîne de type de données. Toutefois, ces valeurs sont interprétées comme des valeurs JSON au moment de l'accès. Si la structure JSON change, le système de base de données ne le détecte pas. Les processus de migration de données qui interprètent une chaîne comme une valeur JSON peuvent échouer.
Modifications du processus de migration
La gestion des modifications lors d'une migration continue de bases de données est difficile et complexe, et peut entraîner des échecs du processus ou des incohérences de données. Dans l'idéal, les modifications requises doivent être retardées jusqu'à la fin de la phase de drainage, moment auquel les systèmes de base de données sources et cibles sont synchronisés. Les modifications apportées à ce stade sont ensuite limitées aux bases de données cibles et à leurs clients (sauf si un remplacement est également mis en œuvre).
Si vous devez modifier votre processus de migration pendant une migration de données, nous vous recommandons de limiter ces modifications au minimum et éventuellement d'apporter plusieurs modifications mineures plutôt qu'une seule plus complexe. En outre, vous pouvez commencer par tester ces modifications en utilisant des instances de test de vos bases de données sources et cibles. Idéalement, chargez la source de test avec des données de production que vous migrez ensuite vers la cible de test. Cette approche vous permet de valider les modifications proposées sans que cela n'affecte votre migration de production en cours. Après avoir testé et validé vos modifications, vous pouvez les appliquer à votre système de production.
Pour que les modifications soient possibles pendant une migration de données en cours, vous devez pouvoir arrêter le système de migration de données et le redémarrer, éventuellement avec des processus de migration de données modifiés. Dans ce cas, il n'est pas nécessaire de commencer depuis le départ, par une phase de chargement initial des données. Si le système de migration de données est compatible avec une fonctionnalité d'exécution d'une migration test, vous pouvez également l'utiliser.
Nous vous recommandons d'éviter de modifier le schéma, les valeurs de données ou les processus de migration de données lors d'une migration de données. Si vous devez apporter des modifications, vous pouvez envisager de recommencer la migration des données depuis le début pour vous assurer que vous disposez d'un état de départ défini. Dans tous les cas, il est primordial d'effectuer des tests à l'aide de données de production et de sauvegarder les bases de données avant d'appliquer les modifications afin de pouvoir, si nécessaire, rétablir un état cohérent du système global.
Atténuation des échecs de migration
Des problèmes inattendus peuvent survenir lors d'une migration de bases de données. Voici quelques éléments qui peuvent nécessiter une planification préalable :
- Débit insuffisant. Un système de migration peut présenter un débit insuffisant malgré les tests de charge. Ce problème peut avoir plusieurs causes, telles qu'une augmentation imprévue du nombre de modifications des bases de données sources ou une limitation de bande passante réseau. Vous pouvez vous préparer à ce cas de figure en préparant des ressources supplémentaires en vue du scaling dynamique (à la hausse ou horizontal) de tous les composants concernés.
- Instabilité des base de données. Les bases de données sources ou cibles peuvent présenter une instabilité, ce qui peut ralentir les processus de migration de données ou empêcher l'accès de manière intermittente. Les processus de migration de données peuvent nécessiter une récupération fréquente. Dans ce cas, un basculement intentionnel en haute disponibilité ou en reprise après sinistre peut résoudre le problème. Un basculement modifie l'environnement non fonctionnel (machines et espace de stockage) et peut aider à résoudre le problème. Dans ce cas, vous devez tester les processus de basculement et de récupération de la migration de bases de données pour vous assurer que le basculement n'entraîne pas d'incohérences des données dans les bases de données cibles.
- Taille maximale des fichiers journaux de transactions atteinte. Dans certains cas, les journaux de transactions sont stockés dans des fichiers ayant une limite supérieure. Il est possible que cette limite soit atteinte et que la migration des bases de données échoue. Il est important de comprendre quelles parties d'un système de base de données peuvent être reconfigurées de manière dynamique pour résoudre les problèmes de limites de ressources dès qu'ils surviennent. Si certains aspects ne peuvent pas être configurés de manière dynamique, le dimensionnement initial doit être déterminé avec soin.
Plus vos tests initiaux sont réalistes et complets, plus vous êtes susceptible de détecter les problèmes potentiels afin de les résoudre à l'avance.
Étapes suivantes
- Consultez les ressources suivantes sur la migration de bases de données :
- Consultez la page Migration de bases de données pour obtenir d'autres guides sur la migration de bases de données.
- Découvrez des architectures de référence, des schémas et des bonnes pratiques concernant Google Cloud. Consultez notre Centre d'architecture cloud.