Automatisation de la récupération après sinistre pour MySQL HeatWave avec des canaux de réplication à l'aide de la récupération après sinistre de pile complète pour OCI
Présentation
Oracle Cloud Infrastructure Full Stack Disaster Recovery (OCI Full Stack DR) orchestre la transition des instances de calcul, de base de données et d'applications entre les régions OCI du monde entier en un seul clic. Les clients peuvent automatiser les étapes nécessaires à la récupération d'un ou de plusieurs systèmes d'affaires sans reconcevoir ou modifier l'infrastructure, les bases de données ou les applications existantes et sans avoir besoin de serveurs de gestion ou de conversion spécialisés.
MySQL HeatWave est un service de base de données entièrement géré déployé dans Oracle Cloud Infrastructure (OCI) qui prend en charge les opérateurs et les développeurs qui cherchent à déployer rapidement des applications en nuage natives et sécurisées. MySQL HeatWave est la seule offre MySQL qui offre la possibilité d'utiliser HeatWave, un accélérateur d'interrogation intégré haute performance en mémoire. HeatWave permet aux clients d'exécuter des analyses sophistiquées directement sur leur base de données MySQL opérationnelle, éliminant ainsi l'exigence de migration et d'intégration de données complexes, chronophages et coûteuses avec une base de données d'analyse distincte. HeatWave accélère considérablement les performances de MySQL pour les analyses et les charges de travail mixtes. HeatWave est entièrement optimisé pour OCI et MySQL HeatWave est construit, géré et pris en charge à 100 % par les équipes d'ingénierie OCI et MySQL.
Dans ce tutoriel, vous apprendrez à automatiser les plans de reprise après sinistre pour MySQL HeatWave dans OCI avec la réplication de canal. Il décrit les procédures d'utilisation de la récupération après sinistre de pile complète pour OCI, qui prend désormais en charge de manière native MySQL HeatWave pour gérer les opérations de permutation et de basculement.
Description de l'architecture
L'architecture présentée dans ce tutoriel présente MySQL HeatWave où la réplication entrante est utilisée pour activer la réplication de données asynchrone entre le système de base de données principal et une réplique distante, assurant ainsi une synchronisation efficace des données entre les régions.

Description de l'illustration full-stack-disaster-recovery-heatwave.png
Note : Le mode Lecture seule doit être activé pour la réplique MySQL HeatWave dans la région de récupération après sinistre afin de garantir l'intégrité des données et d'éviter toute modification involontaire.
Préalables (préparation de l'utilisateur)
Avant de lancer la configuration de la réplication, assurez-vous que les préalables suivants sont satisfaits. Ces exigences incluent à la fois des exigences propres à la réplication et des préalables d'infrastructure et de configuration supplémentaires nécessaires pour prendre en charge une architecture Récupération après sinistre de pile complète robuste pour MySQL HeatWave sur Oracle Cloud Infrastructure (OCI).
- Connectivité réseau
Établissez une communication sécurisée entre les régions source et cible à l'aide des éléments suivants :- Passerelle de routage dynamique (DRG)
- Connexions d'appairage distant
- Configuration du réseau
Configurez les éléments suivants pour autoriser le trafic MySQL inter-région :- Listes de sécurité** ou **Groupes de sécurité de réseau
- Tables de routage
- Récupération après sinistre de pile complète Configurez les politiques OCI IAM requises pour la reprise après sinistre de pile complète OCI, comme indiqué dans les documents suivants.
- Politiques pour la récupération après sinistre de pile complète pour OCI
- Configuration des politiques de gestion des identités et des accès (IAM) pour utiliser la reprise après sinistre de pile complète
La reprise après sinistre de pile complète OCI doit pouvoir contrôler et gérer d'autres services OCI clés tels que le calcul, le réseau, le stockage et d'autres services divers. Pour configurer les politiques OCI IAM requises pour d'autres services, voir Politiques pour les autres services gérés par la récupération après sinistre de pile complète et Politiques OCI IAM.
Note : pour MySQL HeatWave
Comme préalable à la configuration de MySQL HeatWave avec FSDR, les clés secrètes du service de chambre forte OCI doivent être créées dans les deux régions. Ces clés secrètes doivent stocker en toute sécurité le mot de passe de l'utilisateur administrateur ainsi que le mot de passe de l'utilisateur de réplication.
Configuration du système MySQL HeatWave - Sommaire de haut niveau
Vous trouverez ci-dessous un sommaire de haut niveau des étapes requises pour configurer la réplication inter-région pour MySQL HeatWave sur Oracle Cloud Infrastructure (OCI), afin de garantir une synchronisation des données sécurisée, fiable et évolutive entre les régions.
- Déployer une base de données MySQL HeatWave principale dans la région source.
- Créez un utilisateur de réplication sur le serveur MySQL source avec les privilèges appropriés.
- Créez manuellement une sauvegarde de la base de données principale.
- Copiez la sauvegarde dans la région cible à l'aide de la fonction Copier la sauvegarde d'OCI.
- Restaurer la sauvegarde dans la région cible pour créer un nouveau système de base de données de secours.
- Remplacez le mode du système de base de données de secours par Lecture seule.
- Dans la région cible, configurez le canal de réplication à l'aide des éléments suivants :
- Nom d'hôte de la base de données source, port
- Données d'identification de l'utilisateur pour la réplication
- Surveillez régulièrement le statut de réplication de la base de données MySQL cible.
- Effectuez des vérifications de cohérence des données pour valider l'exactitude de la réplication et le maintien de l'intégrité des données.
En suivant ces étapes, vous pouvez mettre en oeuvre une configuration robuste de réplication inter-région pour MySQL sur OCI, améliorant ainsi la résilience et la disponibilité de votre application dans toutes les régions géographiques.
Note : Le tutoriel suivant : Configurer la copie de récupération après sinistre MySQL HeatWave inter-région dans OCI, fournit un guide complet pour déployer la récupération après sinistre pour le système de base de données MySQL, afin d'assurer la résilience et la continuité en cas de défaillance du système.
Définitions et hypothèses tout au long du tutoriel
-
Régions :
-
La région 1 est Ashburn : Ashburn servira initialement de région principale. Toutefois, ce rôle passera à la base de secours au cours du processus de permutation, qui sera effectué dans les tâches ultérieures dans le cadre du plan de reprise après sinistre.
-
La région 2 est Phoenix : Phoenix fonctionnera initialement en tant que région de secours. Ce rôle passera ensuite au rôle principal après le processus de permutation, qui sera effectué dans les tâches suivantes dans le cadre de la procédure de reprise après sinistre.
-
-
Compartiments : Vous pouvez organiser ce déploiement et la reprise après sinistre de pile complète OCI en n'importe quel modèle de compartiment conforme à vos normes de gouvernance des TI. Nous avons choisi d'organiser toutes les ressources OCI pour ce tutoriel dans un seul compartiment.
Objectifs
Les tâches suivantes seront traitées dans ce tutoriel :
- Tâche 1 : Créer des groupes de protection RS (DRPG) dans les deux régions
- Tâche 2 : Ajouter MySQL HeatWave aux groupes de protection RS des deux régions
- Tâche 3 : Créer des plans RS dans la région 2
- Tâche 4 : Exécuter les vérifications préalables des plans RS dans la région 2
- Tâche 5 : Exécuter le plan de permutation dans la région 2
- Tâche 6 : Créer des plans RS dans la région 1
Tâche 1 : Créer des groupes de protection RS (DRPG) dans les deux régions
Créez des groupes de protection RS dans les régions 1 et 2 si les groupes de protection pour cette pile d'applications n'existent pas encore.
Tâche 1.1 : Créer un groupe de protection dans la région 1
-
Allez à la console OCI et naviguez jusqu'à Groupes de protection RS, comme illustré dans la figure 1.1.
- Assurez-vous que le contexte de région OCI est réglé à Région 1 (Ashburn).
- Cliquez sur Migration et récupération après sinistre.
- Cliquez sur Groupes de protection RS.
Figure 1.1 : Naviguez jusqu'aux groupes de protection RS -
Cliquez sur Créer un groupe de protection RS pour ouvrir la boîte de dialogue.
Figure 1.2 : Cliquez sur Créer une protection RS -
Créez un groupe de protection RS de base dans la région 1, comme illustré à la figure 1.3. Le pair, le rôle et les membres seront affectés aux étapes ultérieures.
- Utilisez un nom significatif pour la passerelle DRPG.
- Sélectionnez le compartiment dans lequel vous souhaitez créer la passerelle DRPG.
- Sélectionnez le seau de stockage d'objets OCI pour les journaux RS de pile complète OCI.
- Cliquez sur Créer.
Figure 1.3 : Paramètres nécessaires pour créer un groupe de protection RS dans la région 1
Tâche 1.2 : Créer un groupe de protection dans la région 2
-
Allez à la console OCI, naviguez jusqu'à Groupes de protection RS, comme illustré à la figure 1.4.
- Assurez-vous que le contexte de région OCI est réglé à Région 2 (Phoenix).
- Cliquez sur Migration et récupération après sinistre.
- Cliquez sur Groupes de protection RS.
Figure 1.4 : Naviguez jusqu'aux groupes de protection RS -
Cliquez sur Créer un groupe de protection RS pour ouvrir la boîte de dialogue.
Figure 1.5 : Cliquez sur Créer une protection RS -
Créez un groupe de protection RS de base dans la région 2, comme illustré à la figure 1.6. Le pair, le rôle et les membres seront affectés aux étapes ultérieures.
- Utilisez un nom significatif pour la passerelle DRPG.
- Sélectionnez le compartiment dans lequel vous souhaitez créer la passerelle DRPG.
- Sélectionnez le seau de stockage d'objets OCI pour les journaux RS de pile complète OCI.
- Cliquez sur Créer.
Figure 1.6 : Paramètres nécessaires pour créer un groupe de protection RS dans la région 2
Tâche 1.3 : Associer des groupes de protection dans la région 1 et la région 2
Associez les DRPG de chaque région en tant que pairs et affectez les rôles de pairs de la base principale et de la base de secours. Les rôles de base de données principale et de base de secours sont automatiquement modifiés par la récupération après sinistre de pile complète OCI dans le cadre de toute opération de récupération après sinistre/exécution de plan de récupération après sinistre. Il n'est pas nécessaire de gérer les rôles manuellement à tout moment.
-
Allez à la page Détails du groupe de protection RS.
- Assurez-vous que le contexte de région OCI est réglé à Région 1 (Ashburn).
- Cliquez sur Action
- Cliquez sur Associer pour lancer le processus.
Figure 1.7 : Démarrer l'association DRPG -
Entrez les paramètres tels qu'ils apparaissent dans l'image suivante.
- Rôle : Sélectionnez le rôle Principal. La récupération après sinistre de pile complète OCI affectera automatiquement le rôle de secours à la région 2.
- Région d'appairage : Sélectionnez la région 2 (Phoenix), où l'autre passerelle DRPG a été créée.
- Groupe de protection RS pair : Sélectionnez la passerelle DRPG pair qui a été créée.
- Cliquez sur associer.
Figure 1.8 : Paramètres nécessaires pour associer les passerelles DRPG -
Autorisez la fin de la demande de travail avant de continuer.
Figure 1.9 : Association DRPG terminée.
La récupération après sinistre de pile complète pour OCI affiche une valeur similaire à celle indiquée dans l'image suivante, une fois l'association terminée.
- La passerelle DRPG principale courante est Ashburn (région 1).
- Le DRPG pair de secours courant est Phoenix (région 2).
Figure 1.10 : Affichage de la relation entre pairs du point de vue des DRPG individuels
Les mêmes informations peuvent être trouvées chaque fois que le contexte/vue est d'une perspective globale montrant tous les groupes de protection RS, comme indiqué dans l'image suivante.
- La passerelle DRPG principale courante est Ashburn (région 1).
- Le DRPG pair de secours courant est Phoenix (région 2).
Figure 1.11 : Affichage de la relation entre pairs du point de vue de la passerelle DRPG globale
Tâche 2 : Ajouter MySQL HeatWave au groupe de protection RS
Tâche 2.1 : Ajouter MySQL HeatWave à DRPG dans la région 1
-
Sélectionnez la passerelle DRPG dans la région 1, comme illustré dans l'image suivante.
- Assurez-vous que le contexte de région OCI est Région 1 (Ashburn).
- Sélectionnez la passerelle DRPG dans la région 1.
- Sélectionnez Membres.
- Cliquez sur Gérer les membres pour commencer le processus.
Figure 2.1 : Comment commencer à ajouter des membres au groupe de protection RS dans la région 1 -
Cliquez sur Ajouter un membre.
Figure 2.2 : Commencez à ajouter des membres au groupe de protection RS dans la région 1 -
Ajoutez MySQL HeataWave à la passerelle DRPG de la région 1.
- Entrez Système MySQL Database comme type de ressource de membre.
- Sélectionnez le compartiment approprié, puis choisissez le nom MySQL HeatWave principal dans la région 1 dans le champ Système de base de données.
- Sélectionnez le compartiment approprié, puis choisissez le nom MySQL HeatWave de la réplique dans la région 2 dans le champ Système de base de données pair.
- Entrez le nom d'utilisateur de l'administrateur.
- Sélectionnez le compartiment approprié, puis sélectionnez la clé secrète du mot de passe de l'administrateur.
- Entrez le nom d'utilisateur de réplication.
- Sélectionnez le compartiment approprié, puis sélectionnez la clé secrète du mot de passe de réplication.
- Cliquez sur Ajouter.
Paramètres facultatifs :
- Temporisation de rapprochement : Indique le temps, en secondes, d'attente de la synchronisation de l'identificateur global de transaction (GTID) au cours du processus de rapprochement. Ce paramètre de temporisation garantit que le système accorde suffisamment de temps pour la synchronisation GTID avant de considérer que l'opération a échoué ou s'est terminée.
- Continuer sur la temporisation de rapprochement : En activant cette option, le système contournera le processus de validation du GTID une fois la temporisation dépassée. Cela permet au basculement ou à la permutation de se poursuivre, même si la synchronisation GTID est incomplète.
Figure 2.3 : Paramètres nécessaires pour ajouter MySQL HeatWave -
Publier les modifications dans la région DRPG 1
Cliquez sur Publier les modifications.
Figure 2.4 : Publier les modificationsConfirmez, en cliquant sur Publier les modifications
Figure 2.4 : Publier les modifications
Figure 2.5 : MySQL HeatWave ajoutée à la passerelle DRPG de la région 1.
Tâche 2.2 : Ajouter MySQL HeatWave à DRPG dans la région 2
-
Sélectionnez la passerelle DRPG dans la région 2, comme illustré dans l'image suivante.
- Assurez-vous que le contexte de région OCI est Région 2 (Phoenix).
- Sélectionnez la passerelle DRPG dans la région 2.
- Sélectionnez Membres.
- Cliquez sur Gérer les membres pour commencer le processus.
Figure 2.6 : Comment commencer à ajouter des membres au groupe de protection RS dans la région 2 -
Cliquez sur Ajouter un membre.
Figure 2.7 : Commencez à ajouter des membres au groupe de protection RS dans la région 2 -
Ajoutez MySQL HeataWave à la passerelle DRPG de la région 2.
- Entrez Système MySQL Database comme type de ressource de membre.
- Sélectionnez le compartiment approprié, puis choisissez le nom MySQL HeatWave de la réplique dans la région 2 dans le champ Système de base de données.
- Sélectionnez le compartiment approprié, puis choisissez le nom MySQL HeatWave principal dans la région 1 dans le champ Système de base de données pair.
- Entrez le nom d'utilisateur de l'administrateur.
- Sélectionnez le compartiment approprié, puis sélectionnez la clé secrète du mot de passe de l'administrateur.
- Entrez le nom d'utilisateur de réplication.
- Sélectionnez le compartiment approprié, puis sélectionnez la clé secrète du mot de passe de réplication.
- Cliquez sur Ajouter.
Paramètres facultatifs :
- Temporisation de rapprochement : Indique le temps, en secondes, d'attente de la synchronisation de l'identificateur global de transaction (GTID) au cours du processus de rapprochement. Ce paramètre de temporisation garantit que le système accorde suffisamment de temps pour la synchronisation GTID avant de considérer que l'opération a échoué ou s'est terminée.
- Continuer sur la temporisation de rapprochement : En activant cette option, le système contournera le processus de validation du GTID une fois la temporisation dépassée. Cela permet au basculement ou à la permutation de se poursuivre, même si la synchronisation GTID est incomplète.
Figure 2.8 : Paramètres nécessaires pour ajouter MySQL HeatWave -
Publiez les modifications dans la région DRPG 2.
Cliquez sur Publier les modifications.
Figure 2.9 : Publier les modificationsConfirmez, en cliquant sur Publier les modifications.
Figure 2.10 : Publier les modifications
Figure 2.11 : MySQL HeatWave ajoutée à la passerelle DRPG de la région 2
Tâche 3 : Créer des plans RS dans la région 2
Dans cette tâche, nous allons créer les plans de permutation et de basculement initiaux associés au groupe de protection RS de secours dans la région 2 (Phoenix).
L'objectif de ces plans est de faire passer de manière transparente la charge de travail de la région principale (Région 1) à la région de secours (Région 2). Dans le cadre d'une opération de récupération après sinistre, les rôles des groupes de protection RS dans les deux régions sont automatiquement inversés : le groupe de protection dans la région 1 devient la base de secours, tandis que le groupe de protection dans la région 2 assume le rôle principal à la suite d'un basculement ou d'une permutation.
La récupération après sinistre de pile complète OCI préalimentera ces plans avec des étapes intégrées dérivées des ressources membres ajoutées au cours des tâches précédentes. Les plans de reprise après sinistre sont automatiquement préalimentés avec les tâches de récupération MySQL HeatWave appropriées, car MySQL HeatWave est intégré à la récupération après sinistre de pile complète.
Les plans RS sont toujours créés au sein du groupe de protection détenant le rôle de secours. Étant donné que Region 2 (Phoenix) est actuellement le groupe de protection de secours, nous allons commencer à y créer les plans.
Tâche 3.1 : Créer des plans RS
-
Créez un plan de base en sélectionnant le DRPG dans la région 2 (Phoenix)
- Assurez-vous que le contexte de région OCI est Région 2 (Phoenix).
- Sélectionnez la passerelle DRPG de secours dans la région 2.
- Sélectionnez Plans.
- Cliquez sur Créer un plan pour commencer le processus.
Figure 3.1 : Comment commencer à créer des plans RS de base dans la région 2 -
Créez un plan de permutation.
- Entrez un nom simple mais significatif pour le plan Permutation. Le nom devrait être aussi court que possible, mais facile à comprendre en un coup d'œil pour aider à réduire la confusion et l'erreur humaine pendant une crise.
- Sélectionnez Type de plan comme Permutation (planifiée).
Figure 3.2 : Paramètres nécessaires pour créer un plan de permutation RS
Figure 3.3 : Plan de permutation RSCliquez sur le nom du plan RS pour voir les détails du plan RS et les groupes de plans.
Figure 3.4 : Permutation RS pour le groupe de plans MySQL HeatWave -
Créez un plan de basculement.
- Entrez un nom simple mais significatif pour le plan de basculement. Le nom devrait être aussi court que possible, mais facile à comprendre en un coup d'œil pour aider à réduire la confusion et l'erreur humaine pendant une crise.
- Sélectionnez Type de plan comme Basculement (non planifié).
Figure 3.5 : Paramètres nécessaires à la création d'un plan de basculement RS
Figure 3.6 : Plan de basculement RSCliquez sur le nom du plan RS pour voir les détails du plan RS et les groupes de plans.
Figure 3.7 : Basculement de reprise après sinistre pour le groupe de plans MySQL HeatWave
Le groupe de protection RS de secours dans la région 2 doit maintenant avoir les deux plans RS. Ceux-ci traiteront les charges de travail de transition de la région 1 à la région 2.
Note : Après l'exécution initiale du plan de permutation, nous créerons plus tard des plans correspondants dans la région 1 pour rétablir la transition des charges de travail à partir de la région 2.
- (Facultatif) Créer des plans de forage RS - Démarrer le forage et arrêter le forage.
Tout comme les plans de permutation et de basculement, vous pouvez créer un plan RS Démarrer le forage. Lors du démarrage du forage, un nouveau système de base de données sera créé à l'aide des dernières sauvegardes disponibles, simulant un scénario de récupération après sinistre réel où vous devez récupérer des opérations dans la région RS.
- Entrez un nom simple mais significatif pour le plan Démarrer le forage. Le nom devrait être aussi court que possible, mais facile à comprendre en un coup d'œil pour aider à réduire la confusion et l'erreur humaine pendant une crise.
-
Sélectionnez Type de plan comme Démarrer le forage.
Figure 3.8 : Paramètres nécessaires à la création du plan de forage Démarrer
L'arrêt du forage doit être créé/exécuté une fois le démarrage du forage terminé. Ce plan est chargé de mettre fin aux systèmes de base de données créés lors de l'exécution de Start Drill et de nettoyer toutes les ressources temporaires utilisées à des fins de test.
Tâche 4 : Exécuter les vérifications préalables dans la région 2
Les plans RS de permutation et de basculement ont été créés avec succès dans la région de secours 2. Ces plans permettent à la reprise après sinistre de pile complète OCI de faire la transition des charges de travail de la région 1 vers la région 2. La tâche suivante consiste à exécuter les vérifications préalables pour les plans de permutation et de basculement afin de garantir la disponibilité et de valider le processus de transition.
Tâche 4.1 : Commencer les vérifications préalables pour le plan de permutation
Exécutez des vérifications préalables pour le plan RS de permutation.
- Assurez-vous que le contexte de région est réglé à Région de secours 2.
- Assurez-vous que le groupe de protection RS approprié dans la région 2 est sélectionné. Il doit s'agir du rôle de secours.
- Cliquez sur le nom du plan de permutation.
- Cliquez sur Action.
- Cliquez sur Exécuter les vérifications préalables.
Figure 4.1 : Présentation de l'exécution des vérifications préalables du plan de permutation
Figure 4.2 : Présentation de l'exécution des vérifications préalables du plan de permutation
Planifier les groupes d'exécution des vérifications préalables de permutation.
Figure 4.3 : Affichage des vérifications préalables terminées du plan de permutation
Tâche 4.2 : Commencer les vérifications préalables pour le plan de basculement
Exécutez les vérifications préalables pour le plan RS de basculement.
- Assurez-vous que le contexte de région est réglé à Région de secours 2.
- Assurez-vous que le groupe de protection RS approprié dans la région 2 est sélectionné. Il doit s'agir du rôle de secours.
- Cliquez sur le nom du plan de basculement.
- Cliquez sur Action.
- Cliquez sur Exécuter les vérifications préalables.
Figure 4.4 : Présentation de l'exécution des vérifications préalables du plan de basculement
Figure 4.5 : Présentation de l'exécution des vérifications préalables du plan de basculement
Planifier les groupes d'exécution des vérifications préalables de permutation.
Figure 4.6 : Affichage des vérifications préalables terminées du plan de basculement
Tâche 5 : Exécuter le plan de permutation dans la région 2
Exécutez le plan RS de permutation pour commencer le processus de transition de l'application WordPress avec la base de données MySQL HeatWave de la région 1 vers la région 2.
- Assurez-vous que le contexte de région est réglé à Région de secours 2.
- Assurez-vous que le groupe de protection RS approprié dans la région 2 est sélectionné. Il doit s'agir du rôle de secours.
- Cliquez sur le nom du plan de permutation.
- Cliquez sur Action.
- Cliquez sur Exécuter le plan.
Figure 5.1 : Présentation de l'exécution du plan de permutation
Cette tâche exécute le plan de permutation dans la région 2.
- Désélectionnez Activer les vérifications préalables, car elles ont déjà été exécutées dans la tâche 4.
- Cliquez sur Exécuter le plan RS.
Figure 5.2 : Présentation de l'exécution du plan de permutation
Cliquez sur Exécuter le plan RS pour commencer
Figure 5.3 : Affichage de la confirmation de l'exécution du plan de permutation
Surveillez le plan de permutation jusqu'à ce que la charge de travail complète soit entièrement passée de la région 1 à la région 2.
Figure 5.4 : Affichage de l'exécution en cours du groupe de plans de permutation.
L'exécution du plan de permutation a réussi.
Figure 5.5 : Affichage d'une exécution de plan de permutation terminée.
Tâche 6 : Créer des plans RS dans la région 1
Avec la permutation réussie par la reprise après sinistre de pile complète OCI, la région 2 a désormais assumé le rôle de région principale, tandis que la région 1 a effectué une transition pour servir de région de secours.
Suivez la même approche décrite dans la tâche 3. Procédez à la création des plans de permutation et de basculement au sein du groupe de protection RS pour la région 1, qui sert désormais de région pair de secours.
Figure 6.1 : Capture d'écran présentant les plans créés dans la région 1
Figure 6.2 : Capture d'écran présentant le plan de permutation dans la région 1
Figure 6.3 : Capture d'écran présentant le plan de basculement dans la région 1
Étapes suivantes
Pour plus d'informations, voir la documentation sur la récupération après sinistre de pile complète OCI et MySQL HeatWave dans la section Liens connexes.
Liens connexes
-
Récupération après sinistre de pile complète d'Oracle Cloud Infrastructure (OCI)
-
Joindre le canal de marge #full-stack-dr
Remerciements
-
Auteur - Antoun Moubarak (Architecte, Bureau de la technologie - EMEA Technology Engineering)
-
Contributeur - Suraj Ramesh (Gestionnaire de produits pour la reprise après sinistre de pile complète OCI)
Ressources d'apprentissage supplémentaires
Explorez d'autres laboratoires sur le site docs.oracle.com/learn ou accédez à plus de contenu d'apprentissage gratuit sur le canal Oracle Learning YouTube. De plus, visitez education.oracle.com/learning-explorer pour devenir un explorateur Oracle Learning.
Pour obtenir la documentation sur le produit, visitez Oracle Help Center.
Automate Disaster Recovery for MySQL HeatWave with Replication Channels Using OCI Full Stack Disaster Recovery
G42704-02