Note :

Ce tutoriel nécessite l'accès à Oracle Cloud. Pour vous inscrire à un compte gratuit, voir Introduction à l' niveau gratuit d'Oracle Cloud Infrastructure.
Il utilise des exemples de valeurs pour les données d'identification, la location et les compartiments Oracle Cloud Infrastructure. À la fin de votre laboratoire, remplacez ces valeurs par celles propres à votre environnement en nuage.

Automatiser la récupération après sinistre à froid pour Oracle HeatWave MySQL à 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 (RD de pile complète OCI) orchestre la transition du calcul, de la base de données et des 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 repenser ou réorganiser 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.

Oracle HeatWave MySQL 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. Oracle HeatWave MySQL est la seule offre MySQL qui permet 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 opérationnelle MySQL, é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 la performance de MySQL pour les analyses et les charges de travail mixtes. HeatWave est entièrement optimisé pour OCI et Oracle HeatWave MySQL est créé, géré et pris en charge à 100 % par les équipes d'ingénierie OCI et MySQL.

Dans ce tutoriel, vous apprendrez à automatiser une récupération après sinistre à froid pour Oracle HeatWave MySQL dans OCI. Il décrit les procédures d'utilisation du service de reprise après sinistre de pile complète OCI pour gérer les processus de permutation et de basculement.

Note : Ce type de stratégie de récupération après sinistre repose sur un mécanisme de sauvegarde et de restauration, ce qui le rend le mieux adapté aux applications non critiques où les exigences d'affaires relatives aux objectifs de délai de récupération (ODR) et aux objectifs de point de récupération (OPR) ne sont pas trop strictes.

Description de l'architecture

L'architecture présentée dans ce tutoriel présente une application WordPress s'exécutant sur des machines virtuelles OCI intégrées de façon transparente à Oracle HeatWave MySQL. En outre, la configuration tire parti du service de stockage de fichiers OCI en tant que partage NFS (Network File System) pour stocker le contenu WordPress. Ce stockage partagé est monté sur chaque machine virtuelle pour assurer un accès immédiat et synchronisé à tous les nouveaux contenus dans l'environnement.

Un équilibreur de charge OCI est déployé dans un sous-réseau public pour gérer efficacement les connexions d'utilisateurs externes, en répartissant le trafic entrant entre les machines virtuelles WordPress.

Description de l'architecture de récupération après sinistre

La stratégie de récupération après sinistre pour les machines virtuelles d'application WordPress implique une approche complète, notamment la réplication complète de chaque volume de démarrage de machine virtuelle avec réplication de groupe de volumes et l'utilisation de la réplication du stockage de fichiers pour assurer la synchronisation du contenu WordPress.

Un équilibreur de charge est préprovisionné dans la région distante, ce qui lui permet de gérer le trafic de façon transparente lors de la transition des machines virtuelles WordPress vers la région distante lors d'un scénario de permutation ou de basculement.

Pour Oracle HeatWave MySQL, les sauvegardes sont régulièrement copiées dans la région distante pour assurer la protection des données et la préparation pour la récupération après sinistre. Ce processus peut être lancé à partir d'une machine virtuelle d'application à l'aide d'un script personnalisé, qui peut être programmé au moyen de crontab pour une exécution automatisée et cohérente.

Le diagramme suivant illustre le flux de travail de copie de la dernière sauvegarde MySQL disponible de la région principale vers la région distante.

fsdr_mds_copy_restore_bkp-Logical_Workflow_Copy_Backup_to_Remote.png

La configuration crontab suivante a été configurée sous l'utilisateur opc dans l'application WordPress VM1 pour exécuter le script mds_copy_bkp.py toutes les 4 heures. Cela garantit la synchronisation automatique des sauvegardes vers la région de secours, ce qui contribue à améliorer la récupération après sinistre :

15 */4 * * * /home/opc/mds_copy_restore_bkp/mds_copy_bkp.py mds01

Ce travail exécute le script à la minute 15 après toutes les 4 heures.

Tous les scripts sont disponibles sur GitHub et sont détaillés dans les sections suivantes.

Note : Veillez à programmer ce script (ou un script similaire) selon vos besoins d'affaires pour copier régulièrement la sauvegarde MySQL dans la région distante. Sans cette étape, le processus de restauration peut échouer car la sauvegarde n'est pas disponible dans la région secondaire.

Comment fonctionne la récupération?

Après l'exécution d'une permutation planifiée, les rôles sont inversés : la charge globale principale s'exécute dans la région 2, tandis que la base de secours s'exécute dans la région 1. L'architecture apparaîtra comme suit :

fsdr_mds_copy_restore_bkp-Physical_Switchover_Architecture.png

Dans la configuration courante, nous utilisons le service DNS privé OCI pour gérer un enregistrement DNS qui dirige le trafic vers le point d'extrémité Oracle HeatWave MySQL actif. Au cours du processus de récupération, cet enregistrement DNS est mis à jour au moyen d'un script personnalisé afin de refléter le nouveau langage Oracle HeatWave MySQL, ce qui assure un basculement en toute transparence et une continuité de service.

Le diagramme suivant illustre le flux de travail de restauration de la sauvegarde MySQL la plus récente dans la région de secours.

fsdr_mds_copy_restore_bkp-Logical_Workflow_Restore_Backup_to_Remote.png

La solution de récupération pour ce déploiement nécessite la récupération après sinistre de pile complète OCI pour exécuter une série de scripts Python personnalisés lors d'une opération de récupération telle qu'un basculement ou une permutation. Les scripts référencés dans ce tutoriel sont fournis par l'équipe de spécialistes en architecture en nuage EMEA et disponibles ici : Récupération après sinistre complète, qui est spécialement adaptée à cette solution de reprise après sinistre.

Ce tutoriel explique comment télécharger les scripts et comment les utiliser dans une tâche ultérieure.

Note : Les scripts suivants sont fournis à des fins d'orientation générique. Vous pouvez utiliser vos propres scripts ou les personnaliser en fonction de vos exigences en matière de politique d'entreprise et de sécurité.

Définitions et hypothèses tout au long du tutoriel

Régions :
- La région 1 est Dubaï : Dubaï servira initialement de région principale. Toutefois, ce rôle passera à la base de secours lors 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 Abu Dhabi : Abu Dhabi 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 êtes libre d'organiser ce déploiement et la récupération après sinistre de pile complète OCI dans n'importe quel modèle de compartiment qui respecte vos normes de gouvernance informatique. Nous avons choisi d'organiser toutes les ressources OCI pour ce tutoriel dans un seul compartiment.

WordPress Machines virtuelles d'application et stockage de fichiers OCI

L'architecture utilisée dans ce tutoriel est conçue autour du service de stockage de fichiers OCI pour garantir que toutes les machines virtuelles d'application ont un accès partagé au même contenu WordPress.

Pour plus d'informations sur le montage correct du système de fichiers sur les instances Linux, voir Configuration d'un système de fichiers pour le montage automatique (instances Linux).

Voici un exemple de configuration de fichier /etc/fstab pour le montage du système de fichiers sur la machine virtuelle de l'application WordPress.

xxx.xxx.xxx.xxx:/wordpress /var/www/html nfs nfsvers=3,noacl,nosuid,nofail 0 0

Remplacez xxx.xxx.xxx.xxx par l'adresse IP de la cible de montage située dans la région 1 pour assurer une connectivité appropriée.

Objectifs

Les tâches suivantes seront traitées dans ce tutoriel :

Tâche 1 : Préparer l'environnement pour la récupération après sinistre
Tâche 2 : Créer des groupes de protection RS (DRPG) dans les deux régions
Tâche 3 : Ajouter des membres au groupe de protection RS
Tâche 4 : Créer des plans RS de base dans la région 2
Tâche 5 : Personnaliser le plan de permutation dans la région 2
Tâche 6 : Personnaliser le plan de basculement dans la région 2
Tâche 7 : Exécuter les vérifications préalables des plans RS dans la région 2
Tâche 8 : Exécuter le plan de permutation dans la région 2
Tâche 9 : Créer et personnaliser des plans RS dans la région 1

Tâche 1 : Préparer l'environnement pour la récupération après sinistre

Tâche 1.1 : Créer des groupes de volumes et activer la réplication

Créez un groupe de volumes pour les machines virtuelles d'application WordPress dans la région 1 et assurez-vous qu'il est répliqué dans la région 2. Assurez-vous que le volume de démarrage de chaque machine virtuelle d'application (WordPress) est membre du groupe de volumes et que le groupe de volumes est répliqué dans la région 2.

L'image suivante illustre l'affichage du groupe de volumes créé, qui inclut les volumes de démarrage des deux machines virtuelles d'application WordPress, avec la réplication activée dans la région 2. Pour plus d'informations, voir Création d'un groupe de volumes.

Tâche 1.2 : Activer la réplication du stockage de fichiers pour le contenu WordPress

Dans la région 2, créez un système de fichiers spécifiquement désigné pour la réplication. Ce système de fichiers sera utilisé pour répliquer de façon transparente les données de la région 1 vers la région 2.
Dans la région 2, créez une cible de montage qui sera utilisée lors du processus de récupération de la région 1 à la région 2.
Utilisez le système de fichiers créé à l'étape 1 pour activer et configurer la réplication à partir du stockage de fichiers OCI source dans la région 1.

L'image suivante illustre les détails de réplication du stockage de fichiers dans la région 2.

Pour plus d'informations, voir Réplication des systèmes de fichiers.

Tâche 1.3 : Préparer les machines virtuelles d'application à exécuter l'automatisation personnalisée

Installer et configurer l'interface de ligne de commande d'Oracle Cloud Infrastructure. Pour ce tutoriel, Oracle Linux 8 est utilisé pour la machine virtuelle de l'application WordPress. Pour plus d'informations, voir Installation de l'interface de ligne de commande.
Déployez le script à partir du référentiel GitHub (mds_colddr_scripts) dans le dossier /home/opc.
Installez les pandas et tabulez les modules utilisés par le script fourni.
```
pip install pandas
pip install tabulate
```
Mettez à jour le fichier config.csv avec les détails nécessaires pour Oracle HeatWave MySQL dans la région 1.
- Remplacez MYSQL_DB_SYSTEM_OCID par l'OCID d'Oracle HeatWave MySQL. Vous pouvez conserver ou personnaliser l'étiquette MySQL pour l'aligner sur vos exigences spécifiques.
- Remplacez COMPARTMENT_OCID par l'OCID du compartiment où se trouve le système MySQL.
- Remplacez PRIMARY_SUBNET_OCID et STANDBY_SUBNET_OCID par les OCID du sous-réseau dans les deux régions.
- Remplacez PRIMARY_DNS_VIEW_OCID et STANDBY_DNS_VIEW_OCID par les OCID des vues DNS privées associées à la zone DNS privée gérant l'enregistrement de point d'extrémité Oracle HeatWave MySQL.
Note : Assurez-vous que toutes les valeurs sont mises à jour avec précision.

Dans le cadre du tutoriel, nous utiliserons cette même machine virtuelle pour exécuter des scripts définis par l'utilisateur. Assurez-vous que la machine virtuelle agissant en tant que noeud de contrôle RS a été configurée pour exécuter des commandes. Pour plus d'informations, voir Appeler des scripts personnalisés à l'aide de la commande d'exécution avec Oracle Cloud Infrastructure Full Stack Disaster Recovery.

Tâche 1.4 : Créer des politiques IAM OCI pour la récupération après sinistre de pile complète OCI

Configurez les politiques OCI IAM requises pour la récupération après sinistre de pile complète OCI, comme indiqué dans les documents suivants.

Tâche 1.5 : Créer des politiques IAM OCI pour d'autres services gérés par la récupération après sinistre de pile complète OCI

La récupération après sinistre de pile complète OCI doit avoir la capacité de contrôler et de 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 IAM OCI requises pour d'autres services, voir Politiques pour d'autres services gérés par la récupération après sinistre de pile complète et Politiques IAM pour OCI.

Tâche 2 : 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 de cette pile d'applications n'existent pas encore.

Tâche 2.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é à la figure 2.1.
1. Assurez-vous que le contexte de région OCI est réglé à Région 1 (Dubaï).
2. Cliquez sur Migration et récupération après sinistre.
3. Cliquez sur Groupes de protection RS.
Image 2.1 : Naviguez jusqu'aux groupes de protection RS
Créez un groupe de protection RS de base (DRPG) dans la région 1, comme le montre la figure 2.2. Le pair, le rôle et les membres seront affectés dans les étapes suivantes.
1. Sélectionnez le compartiment dans lequel vous souhaitez créer la passerelle DRPG.
2. Cliquez sur Créer un groupe de protection RS pour ouvrir la boîte de dialogue.
3. Utilisez un nom significatif pour la passerelle DRPG.
4. Sélectionnez le seau de stockage d'objets OCI pour les journaux de récupération après sinistre de pile complète OCI.
5. Cliquez sur Créer.
Figure 2.2 : Paramètres nécessaires pour créer un groupe de protection RS dans la région 1

Tâche 2.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 2.3.
1. Assurez-vous que le contexte de la région OCI est réglé à Région 2 (Abu Dhabi).
2. Cliquez sur Migration et récupération après sinistre.
3. Cliquez sur Groupes de protection RS.
Image 2.3 : Naviguez jusqu'aux groupes de protection RS
Créez un groupe de protection RS de base (DRPG) dans la région 2, comme le montre la figure 2.4. Le pair, le rôle et les membres seront affectés dans les étapes suivantes.
1. Sélectionnez le compartiment dans lequel vous souhaitez créer la passerelle DRPG.
2. Cliquez sur Créer un groupe de protection RS pour ouvrir la boîte de dialogue.
3. Utilisez un nom significatif pour la passerelle DRPG.
4. Sélectionnez le seau de stockage d'objets OCI pour les journaux de récupération après sinistre de pile complète OCI.
5. Cliquez sur Créer.
Figure 2.4 : Paramètres nécessaires pour créer un groupe de protection RS dans la région 2

Tâche 2.3 : Associer des groupes de protection dans les régions 1 et 2

Associez les passerelles DRPG de chaque région en tant que pairs les uns des autres et affectez les rôles pairs de base principale et de base de secours. Les rôles de la base principale et de la 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.
1. Assurez-vous que le contexte de région OCI est réglé à Région 1 (Dubaï).
2. Cliquez sur Associer pour lancer le processus.
Fig : Commencer l'association DRPG
Entrez les paramètres comme indiqué dans l'image suivante.
1. 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.
2. Région pair : Sélectionnez la région 2 (Abu Dhabi), où l'autre passerelle DRPG a été créée.
3. Groupe de protection RS pair : Sélectionnez la passerelle DRPG pair qui a été créée.
4. Cliquez sur Association.
Fig : Paramètres nécessaires pour associer les passerelles DRPG

La récupération après sinistre de pile complète OCI affiche quelque chose comme illustré dans l'image suivante, une fois l'association terminée.

Le DRPG principal actuel est Dubaï (région 1).
Le DRPG de secours actuel est Abu Dhabi (région 2).

Fig : Affichage de la relation de pair du point de vue DRPG individuel

Les mêmes informations peuvent être trouvées chaque fois que le contexte/la vue est d'une perspective globale montrant tous les groupes de protection RS comme indiqué dans l'image suivante.

Le DRPG principal actuel est Dubaï (région 1).
Le DRPG de secours actuel est Abu Dhabi (région 2).

Fig : Affichage de la relation de pair dans la perspective DRPG globale

Tâche 3 : Ajouter des membres au groupe de protection RS

Dans cette tâche, nous ajouterons les ressources OCI suivantes à la passerelle DRPG principale de la région 1.

Les deux instances de calcul hébergeant l'application WordPress seront ajoutées en tant que machines virtuelles mobiles. De plus, assurez-vous que la section Systèmes de fichiers des options avancées est correctement configurée.
Groupe de volumes qui contient le volume de démarrage des noeuds de calcul d'application WordPress.
Stockage de fichiers OCI contenant le contenu WordPress.
L'équilibreur de charge principal.

Tâche 3.1 : Ajouter des membres à la passerelle DRPG dans la région 1

Sélectionnez la passerelle DRPG dans la région 1, comme illustré dans l'image suivante.
1. Assurez-vous que le contexte de la région OCI est Région 1 (Dubaï).
2. Sélectionnez la passerelle DRPG dans la région 1.
3. Sélectionnez Membres.
4. Cliquez sur Ajouter un membre pour commencer le processus.
Fig : Comment commencer à ajouter des membres au groupe de protection RS dans la région 1
Ajoutez une instance de calcul pour les machines virtuelles d'application WordPress.
1. Accusez réception de l'avertissement concernant les plans RS.
2. Entrez le calcul comme type de ressource de membre.
3. Sélectionnez l'instance de calcul hébergeant l'application WordPress.
4. Sélectionnez Instance mobile.
5. Cliquez sur Ajouter un mappage de carte VNIC pour sélectionner le VCN et le sous-réseau à affecter aux cartes VNIC de la région 2 lors d'une récupération.
6. Cliquez sur Afficher les options avancées.
7. Dans Paramètres, sélectionnez Conserver le domaine d'erreur.
8. Dans Systèmes de fichiers, remplissez la section Mappage d'exportation en fonction de votre configuration, comme illustré dans les images suivantes.
Fig : Paramètres nécessaires pour ajouter la machine virtuelle de l'application WordPress

Fig : Paramètres nécessaires pour mapper la carte VNIC de la région 2

Fig : Options avancées, Conserver le domaine d'erreur

Fig : Mappage des options avancées et des systèmes de fichiers

Fig : Instance de calcul ajoutée à la passerelle DRPG dans la région 1

Note : Répétez les sous-étapes précédentes pour toutes les instances de calcul des machines virtuelles d'application WordPress.

Fig : Deux instances de calcul ajoutées à la passerelle DRPG dans la région 1
Ajoutez le groupe de volumes par blocs contenant le volume de démarrage des machines virtuelles d'application WordPress.
1. Accusez réception de l'avertissement concernant les plans RS.
2. Sélectionnez Groupe de volumes comme type de ressource de membre.
3. Assurez-vous que le compartiment approprié contenant le groupe de volumes est sélectionné et sélectionnez le groupe de volumes.
Fig : Paramètres nécessaires pour ajouter le groupe de volumes pour le service de calcul WordPress

Fig : Groupe de volumes pour le service de calcul WordPress ajouté à la passerelle DRPG dans la région 1
Ajoutez le service de stockage de fichiers OCI qui contient le contenu WordPress.
1. Accusez réception de l'avertissement concernant les plans RS.
2. Sélectionnez Système de fichiers comme type de ressource de membre.
3. Assurez-vous que le compartiment approprié contenant le système de fichiers est sélectionné et sélectionnez le système de fichiers.
4. Sélectionnez le domaine de disponibilité de destination à utiliser dans la région 2.
5. Sélectionnez Chemin d'exportation source pour ce système de fichiers. Ce chemin d'exportation est créé dans la région de destination 2 après la restauration du système de fichiers.
6. Sélectionnez la cible de montage de destination dans la région 2 utilisée pour créer une exportation pour le système de fichiers restauré.
Fig : Paramètres nécessaires pour ajouter le système de fichiers pour le contenu WordPress

Fig : Système de fichiers pour le contenu WordPress ajouté à la passerelle DRPG dans la région 1
Ajoutez un équilibreur de charge OCI.

Dans cet exemple, nous allons ajouter l'équilibreur de charge en tant que membre de la passerelle DRPG dans la région 1.
1. Accusez réception de l'avertissement concernant les plans RS.
2. Sélectionnez Équilibreur de charge comme type de ressource de membre.
3. Assurez-vous que les compartiments appropriés sont sélectionnés pour l'équilibreur de charge et sélectionnez celui que vous voulez ajouter.
4. Sélectionnez l'équilibreur de charge de destination à utiliser dans la région 2.
5. Sélectionnez Jeu dorsal source, il s'agit du jeu dorsal utilisé par les machines virtuelles d'application WordPress. Un équilibreur de charge OCI peut être partagé entre plusieurs applications et plusieurs jeux dorsaux peuvent être configurés. Lors d'une permutation RS, seule la configuration des jeux dorsaux spécifiés ici sera déplacée vers la région de secours.
6. Sélectionnez Jeu dorsal de destination. Il s'agit du jeu dorsal vide créé dans la région 2.
Fig : Paramètres nécessaires pour ajouter un équilibreur de charge

Fig : Équilibreur de charge ajouté à la passerelle DRPG dans la région 1

Tâche 3.2 : Ajouter des membres à la passerelle DRPG dans la région 2

Sélectionnez la passerelle DRPG dans la région 2, comme illustré dans l'image suivante.
1. Assurez-vous que le contexte de la région OCI est la région 1 (Abu Dhabi).
2. Sélectionnez la passerelle DRPG dans la région 2.
3. Sélectionnez Membres.
4. Cliquez sur Ajouter un membre pour commencer le processus.
Fig : Comment commencer à ajouter des membres au groupe de protection RS dans la région 2
Ajoutez un équilibreur de charge OCI.

Dans cet exemple, nous ajouterons l'équilibreur de charge en tant que membre de la passerelle DRPG dans la région 2.
1. Accusez réception de l'avertissement concernant les plans RS.
2. Sélectionnez Équilibreur de charge comme type de ressource de membre.
3. Assurez-vous que le compartiment correct pour l'équilibreur de charge est sélectionné et sélectionnez l'équilibreur de charge à ajouter.
4. Sélectionnez l'équilibreur de charge de destination à utiliser dans la région 1.
5. Sélectionnez Jeu dorsal source, il s'agit du jeu dorsal utilisé par les machines virtuelles d'application WordPress. Un équilibreur de charge OCI peut être partagé entre plusieurs applications et plusieurs jeux dorsaux peuvent être configurés. Lors d'une permutation RS, seule la configuration des jeux dorsaux spécifiés ici sera déplacée vers la région de secours.
6. Sélectionnez Jeu dorsal de destination, ce jeu dorsal est créé dans la région 2.
Fig : Paramètres nécessaires pour ajouter un équilibreur de charge

Fig : Équilibreur de charge ajouté à la passerelle DRPG dans la région 2

Tâche 4 : Créer des plans RS de base dans la région 2

Dans cette tâche, nous allons créer les plans initiaux de permutation et de basculement associés au groupe de protection RS de secours dans la région 2 (Abu Dhabi).

L'objectif de ces plans est de faire passer de façon 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 de récupération après sinistre 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 lors des tâches précédentes. Ces plans seront ensuite personnalisés pour gérer les tâches propres à Oracle HeatWave MySQL pendant le processus de récupération.

Les plans de permutation sont toujours créés au sein du groupe de protection qui détient le rôle de base de secours. Puisque la Région 2 (Abu Dhabi) est actuellement le groupe de protection de secours, nous allons commencer à créer les plans là-bas.

Tâche 4.1 : Créer des plans RS

Créez un plan de base en sélectionnant la passerelle DRPG dans la région 2 (Abu Dhabi)
1. Assurez-vous que le contexte de la région OCI est la région 2 (Abu Dhabi).
2. Sélectionnez la passerelle DRPG de secours dans la région 2.
3. Sélectionnez Plans.
4. Cliquez sur Créer un plan pour lancer le processus.
Fig : Comment commencer à créer des plans RS de base dans la région 2
Créez un plan de permutation.
1. Entrez un nom simple mais significatif pour le plan de permutation. Le nom doit ê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.
2. Sélectionnez Type de plan comme Permutation (planifiée).
Fig : Paramètres nécessaires pour créer un plan de permutation RS
Créez un plan de basculement.

Suivez le même processus pour créer un plan de basculement de base, comme illustré dans l'image suivante.
1. Entrez le nom du plan de basculement, simple mais significatif. Le nom doit ê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.
2. Sélectionnez Type de plan comme Basculement (non planifié).
Fig : Paramètres nécessaires pour créer un plan de basculement RS

Le groupe de protection RS de secours dans la région 2 doit maintenant avoir les deux plans RS comme indiqué dans l'image suivante. Ceux-ci traiteront les charges de travail de transition de la région 1 à la région 2. Vous allez créer des plans similaires dans la région 1 pour transférer les charges de travail de la région 2 vers la région 1 dans une tâche ultérieure.

plan-créer-auh-completed.png
Fig : Affichage des deux plans RS de base qui doivent exister dans la région 2 avant de poursuivre

Tâche 5 : Personnaliser le plan de permutation dans la région 2

Les plans de récupération après sinistre de base créés dans la tâche 4 contiennent des étapes préalimentées pour les tâches de récupération qui sont intégrées à la récupération après sinistre de pile complète OCI et ne contiennent rien pour gérer les tâches de récupération propres à Oracle HeatWave MySQL. Cette tâche explique comment ajouter des groupes de plans RS personnalisés définis par l'utilisateur et les étapes de gestion des tâches à effectuer lors d'une permutation :

Créez une sauvegarde de base de données après avoir arrêté correctement les machines virtuelles d'application pour assurer la cohérence des données.
Transférez la dernière sauvegarde de base de données vers la région OCI distante 2 pour la redondance et la récupération après sinistre.
Restaurez la sauvegarde de base de données la plus récente dans la région 2 pour préparer l'environnement pour la permutation.
Mettez à jour l'enregistrement de DNS de base de données privée, ce qui permet aux machines virtuelles d'application de se connecter de façon transparente à la base de données de la région 2.
Mettez fin à la base de données MySQL source dans la région 1.

Tâche 5.1 : Sélectionner le plan de permutation

Accédez au plan de permutation créé dans la tâche 4.

Fig : Comment commencer à personnaliser le plan de permutation dans la région 2

Tâche 5.2 : (Facultatif) Activer les groupes de plans RS qui mettent fin aux artefacts

Trois groupes de plans sont désactivés par défaut dans les plans de permutation, comme illustré dans l'illustration suivante. Ces groupes de plans sont désactivés pour être rassurés lors des tests, afin de s'assurer qu'aucun artefact n'est supprimé et qu'une copie de sauvegarde viable reste intacte en cas de problèmes au cours de la phase de test.

Toutefois, ces trois groupes de plans sont conçus pour mettre fin (supprimer) aux artefacts qui ne seront plus nécessaires pour les opérations de récupération après sinistre futures. Si ces groupes de plans ne sont pas activés, les artefacts non utilisés continueront de s'accumuler au fil du temps lors des permutations entre les deux régions, ce qui peut entraîner une confusion quant aux instances de calcul, au stockage de fichiers OCI et aux groupes de volumes qui doivent être actifs.

Si vous le souhaitez, l'activation de ces groupes de plans permet d'éviter le nettoyage manuel des artefacts inutiles avant la mise en production. Cette étape proactive peut simplifier la transition vers la production et maintenir un environnement plus propre et plus facile à gérer.

Fig : Groupes de plans désactivés par défaut

Pour activer les groupes de plans, sélectionnez Activer toutes les étapes dans le menu contextuel à droite du nom du groupe de plans.

Fig : Comment activer l'arrêt du système de fichiers

Fig : Cliquez sur Activer pour valider.

Fig : Comment activer l'arrêt des instances de calcul

Fig : Cliquez sur Activer pour valider.

Fig : Comment activer l'arrêt du groupe de volumes

Fig : Cliquez sur Activer pour valider.

Tâche 5.3 : Reclasser les groupes de plans RS

Il est nécessaire de monter le système de fichiers sur les nouvelles machines virtuelles déplacées dans la région 2 avant de mettre à jour les jeux dorsaux de l'équilibreur de charge. Cela garantit que l'application dispose d'un accès adéquat aux ressources de stockage requises, ce qui facilite une transition en douceur pendant le processus de permutation.

plan-personnalisé-so-auh-reorder-initial.png
Fig : Capture d'écran montrant l'ordre initial du plan de permutation et comment commencer à réorganiser

plan-personnalisé-so-auh-reorder-start.png
Fig : Démarrez le reclassement

Déplacez les systèmes de fichiers - Montage sur des instances de calcul avant les équilibreurs de charge - Mettre à jour les jeux dorsaux de destination.
Click Save changes.

plan-personnalisé-so-auh-reorder-final.png
Fig : Ordre final du plan de permutation

Tâche 5.4 : Créer un groupe de plans pour exécuter des scripts personnalisés

Commencez par ajouter des groupes de plans RS personnalisés définis par l'utilisateur pour adapter le flux de travail RS aux besoins spécifiques du processus de récupération après sinistre de sauvegarde/restauration MySQL.

Ces groupes de plans appellent les scripts nécessaires à partir de WordPress VM1 dans la région 1 et doivent être positionnés dans le flux de travail RS avant de démarrer les machines virtuelles d'application WordPress. Cela garantit que la base de données MySQL est entièrement restaurée et opérationnelle avant la mise en ligne des machines virtuelles d'application.

Le plan personnalisé suivant doit être ajouté au plan de permutation préalimenté : Créer une sauvegarde MySQL Database, Copier la sauvegarde MySQL Database, Restaurer la sauvegarde MySQL Database, Mettre à jour le DNS de MySQL Database et Mettre fin à la source MySQL Database.

Ajoutez un groupe de plans personnalisé pour créer la sauvegarde de base de données MySQL.
1. Cliquez sur Ajouter un groupe.
2. Entrez un nom de groupe de plans simple mais descriptif. Dans cet exemple, nous utiliserons Create MySQL DB Backup.
3. Sélectionnez le poste où le groupe de plans sera inséré dans le plan RS. Dans cet exemple, sélectionnez Ajouter après pour insérer notre groupe de plans défini par l'utilisateur après le groupe de plans intégré Instances de calcul - Lancement.
4. Cliquez sur Ajouter une étape pour ouvrir la boîte de dialogue dans laquelle nous spécifierons le script pour créer la sauvegarde de base de données MySQL.
Fig : Paramètres de création du groupe de plans Créer une sauvegarde de base de données MySQL

Dans Ajouter une étape de groupe de plans, entrez les informations suivantes.
1. Entrez un nom d'étape simple mais descriptif. Dans cet exemple, nous utiliserons Create MySQL DB Backup. Identique au nom du groupe de plans.
2. Sélectionnez une région qui contient l'instance sur laquelle cette étape sera exécutée. Dans cet exemple, le script sera exécuté sur l'application WordPress VM1 dans la région 1.
3. Sélectionnez Exécuter le script local.
4. Sélectionnez Instance cible, qui est l'application WordPress VM1 dans la région 1.
5. Dans Paramètres de script, entrez le chemin complet du script avec les paramètres. Par exemple : /home/opc/mds_copy_restore_bkp/mds_create_bkp.py mds01.
6. Dans Exécuter en tant qu'utilisateur, entrez opc.
7. Cliquez sur Ajouter une étape.
Fig : Paramètres de création d'une étape Créer une sauvegarde de base de données MySQL

Cliquez sur Ajouter.

Fig : Ajouter un groupe de plans Créer une sauvegarde de base de données MySQL
Ajoutez un groupe de plans personnalisé pour copier la sauvegarde de la base de données MySQL.
1. Cliquez sur Ajouter un groupe.
2. Entrez un nom de groupe de plans simple mais descriptif. Dans cet exemple, nous utiliserons Copy MySQL DB Backup.
3. Sélectionnez le poste où le groupe de plans sera inséré dans le plan RS. Dans cet exemple, sélectionnez Ajouter après pour insérer notre groupe de plans défini par l'utilisateur après le groupe de plans intégré Créer une sauvegarde de base de données MySQL.
4. Cliquez sur Ajouter une étape pour ouvrir la boîte de dialogue dans laquelle nous spécifierons le script pour copier la sauvegarde de base de données MySQL.
Fig : Paramètres de création du groupe de plans Copier la sauvegarde de base de données MySQL

Dans Ajouter une étape de groupe de plans, entrez les informations suivantes.
1. Entrez un nom d'étape simple mais descriptif. Dans cet exemple, nous utiliserons Copy MySQL DB Backup. Identique au nom du groupe de plans.
2. Sélectionnez une région qui contient l'instance sur laquelle cette étape sera exécutée. Dans cet exemple, le script sera exécuté sur l'application WordPress VM1 dans la région 1.
3. Sélectionnez Exécuter le script local.
4. Sélectionnez l'instance cible qui est l'application WordPress VM1 dans la région 1.
5. Dans Paramètres de script, entrez le chemin complet du script avec les paramètres. Par exemple : /home/opc/mds_copy_restore_bkp/mds_copy_bkp.py mds01.
6. Dans Exécuter en tant qu'utilisateur, entrez opc.
7. Cliquez sur Ajouter une étape.
Fig : Paramètres d'ajout d'une étape Copier la sauvegarde de base de données MySQL

Cliquez sur Ajouter.

Fig : Ajouter un groupe de plans Copier la sauvegarde de base de données MySQL
Ajoutez un groupe de plans personnalisé pour restaurer la sauvegarde de la base de données MySQL.
1. Cliquez sur Ajouter un groupe.
2. Entrez un nom de groupe de plans simple mais descriptif. Dans cet exemple, nous utiliserons Restore MySQL DB Backup.
3. Sélectionnez le poste où le groupe de plans sera inséré dans le plan RS. Dans cet exemple, sélectionnez Ajouter après pour insérer notre groupe de plans défini par l'utilisateur après le groupe de plans intégré Copier la sauvegarde de base de données MySQL.
4. Cliquez sur Ajouter une étape pour ouvrir la boîte de dialogue dans laquelle nous spécifierons le script pour restaurer la sauvegarde de base de données MySQL.
Fig : Paramètres de création du groupe de plans Restaurer la sauvegarde de base de données MySQL

Dans Ajouter une étape de groupe de plans, entrez les informations suivantes.
1. Entrez un nom d'étape simple mais descriptif. Dans cet exemple, nous utiliserons Restore MySQL DB Backup. Identique au nom du groupe de plans.
2. Sélectionnez une région qui contient l'instance sur laquelle cette étape sera exécutée. Dans cet exemple, le script sera exécuté sur l'application WordPress VM1 dans la région 1.
3. Sélectionnez Exécuter le script local.
4. Sélectionnez l'instance cible qui est l'application WordPress VM1 dans la région 1.
5. Dans Paramètres de script, entrez le chemin complet du script avec les paramètres. Par exemple : /home/opc/mds_copy_restore_bkp/mds_restore_bkp.py mds01 1 --config --switch.
6. Dans Exécuter en tant qu'utilisateur, entrez opc.
7. Cliquez sur Ajouter une étape.
Fig : Paramètres d'ajout d'une sauvegarde de base de données MySQL pour la restauration d'étape

Cliquez sur Ajouter.

Fig : Ajouter un groupe de plans Restaurer la sauvegarde de base de données MySQL
Ajoutez un groupe de plans personnalisé pour mettre à jour le DNS de la base de données MySQL.
1. Cliquez sur Ajouter un groupe.
2. Entrez un nom de groupe de plans simple mais descriptif. Dans cet exemple, nous utiliserons Update MySQL DB DNS.
3. Sélectionnez le poste où le groupe de plans sera inséré dans le plan RS. Dans cet exemple, sélectionnez Ajouter après pour insérer notre groupe de plans défini par l'utilisateur après le groupe de plans intégré Restaurer la sauvegarde de base de données MySQL.
4. Cliquez sur Ajouter une étape pour ouvrir la boîte de dialogue dans laquelle nous spécifierons le script pour mettre à jour le DNS de la base de données MySQL.
Fig : Paramètres de création du groupe de plans Mettre à jour MySQL DB DNS

Dans Ajouter une étape de groupe de plans, entrez les informations suivantes.
1. Entrez un nom d'étape simple mais descriptif. Dans cet exemple, nous utiliserons Update MySQL DB DNS. Identique au nom du groupe de plans.
2. Sélectionnez une région qui contient l'instance sur laquelle cette étape sera exécutée. Dans cet exemple, le script sera exécuté sur l'application WordPress VM1 dans la région 1.
3. Sélectionnez Exécuter le script local.
4. Sélectionnez l'instance cible qui est l'application WordPress VM1 dans la région 1.
5. Dans Paramètres de script, entrez le chemin complet du script avec les paramètres. Par exemple : /home/opc/mds_copy_restore_bkp/mds_update_dns.py mds01 demo.local mds01.demo.local --remote.
6. Dans Exécuter en tant qu'utilisateur, entrez opc.
7. Cliquez sur Ajouter une étape.
Fig : Paramètres d'ajout d'une mise à jour d'étape MySQL DB DNS

Cliquez sur Ajouter.

Fig : Ajouter un groupe de plans Mettre à jour MySQL DB DNS
Ajoutez un groupe de plans personnalisé pour mettre fin à la base de données source MySQL.
1. Cliquez sur Ajouter un groupe.
2. Entrez un nom de groupe de plans simple mais descriptif. Dans cet exemple, nous utiliserons Terminate MySQL DB Source.
3. Sélectionnez le poste où le groupe de plans sera inséré dans le plan RS. Dans cet exemple, sélectionnez Ajouter après pour insérer notre groupe de plans défini par l'utilisateur après le groupe de plans intégré Systèmes de fichiers - Supprimer du groupe de protection RS.
4. Cliquez sur Ajouter une étape pour ouvrir la boîte de dialogue dans laquelle nous spécifierons le script pour mettre fin à la source de base de données MySQL.
Fig : Paramètres de création du groupe de plans Mettre fin à la base de données source MySQL

Dans Ajouter une étape de groupe de plans, entrez les informations suivantes.
1. Entrez un nom d'étape simple mais descriptif. Dans cet exemple, nous utiliserons Terminate MySQL Source DB. Identique au nom du groupe de plans.
2. Sélectionnez une région qui contient l'instance sur laquelle cette étape sera exécutée. Dans cet exemple, le script sera exécuté sur l'application WordPress VM1 dans la région 1.
3. Sélectionnez Exécuter le script local.
4. Sélectionnez l'instance cible qui est l'application WordPress VM1 dans la région 1.
5. Dans Paramètres de script, entrez le chemin complet du script avec les paramètres. Par exemple : /home/opc/mds_copy_restore_bkp/mds_terminate_db.py mds01.
6. Dans Exécuter en tant qu'utilisateur, entrez opc.
7. Cliquez sur Ajouter une étape.
Fig : Paramètres d'ajout d'une étape Mettre fin à la base de données source MySQL

Cliquez sur Ajouter.

Fig : Ajouter un groupe de plans Mettre fin à la base de données source MySQL
(Facultatif) Ajoutez un groupe de plans personnalisé pour arrêter l'application WordPress.
1. Cliquez sur Ajouter un groupe.
2. Entrez un nom de groupe de plans simple mais descriptif. Dans cet exemple, nous utiliserons Application - Stop.
3. Sélectionnez le poste où le groupe de plans sera inséré dans le plan RS. Dans cet exemple, sélectionnez Ajouter après pour insérer notre groupe de plans défini par l'utilisateur à la fin après le groupe de plans intégré Équilibreurs de charge - Mettre à jour les jeux dorsaux sources.
4. Cliquez sur Ajouter une étape pour ouvrir la boîte de dialogue dans laquelle nous spécifierons le script pour arrêter l'application.
Fig : Paramètres de création d'une application de groupe de plans - Arrêter

Dans Ajouter une étape de groupe de plans, entrez les informations suivantes.
1. Entrez un nom d'étape simple mais descriptif. Dans cet exemple, nous utiliserons Application - Stop - VM1.
2. Sélectionnez une région qui contient l'instance sur laquelle cette étape sera exécutée. Dans cet exemple, le script sera exécuté sur l'application WordPress VM1 dans la région 1.
3. Sélectionnez Exécuter le script local.
4. Sélectionnez l'instance cible qui est l'application WordPress VM1 dans la région 1.
5. Dans Paramètres de script, entrez le chemin complet du script avec les paramètres. Par exemple : /home/opc/fsdrscripts/wdp_stop.sh.
6. Dans Exécuter en tant qu'utilisateur, entrez opc.
7. Cliquez sur Ajouter une étape.
Fig : Paramètres de création d'une application d'étape - Arrêter - VM1

Cliquez sur Ajouter une étape pour ajouter une deuxième étape pour arrêter l'application sur VM2.

Fig : Ajouter une application d'étape - Arrêter - VM2

Dans Ajouter une étape de groupe de plans, entrez les informations suivantes.
1. Entrez un nom d'étape simple mais descriptif. Dans cet exemple, nous utiliserons Application - Stop - VM2.
2. Sélectionnez une région qui contient l'instance sur laquelle cette étape sera exécutée. Dans cet exemple, le script sera exécuté sur l'application WordPress VM2 dans la région 1.
3. Sélectionnez Exécuter le script local.
4. Sélectionnez l'instance cible qui est l'application WordPress VM2 dans la région 1.
5. Dans Paramètres de script, entrez le chemin complet du script avec les paramètres. Par exemple : /home/opc/fsdrscripts/wdp_stop.sh.
6. Dans Exécuter en tant qu'utilisateur, entrez opc.
7. Cliquez sur Ajouter une étape.
Fig : Paramètres de création d'une application d'étape - Arrêter - VM2

Cliquez sur Ajouter.

Fig : Ajouter une application de groupe de plans - Arrêter
(Facultatif) Ajoutez un groupe de plans personnalisé pour démarrer l'application WordPress.
1. Cliquez sur Ajouter un groupe.
2. Entrez un nom de groupe de plans simple mais descriptif. Dans cet exemple, nous utiliserons Application - Start.
3. Sélectionnez le poste où le groupe de plans sera inséré dans le plan RS. Dans ce cas, sélectionnez Ajouter après pour insérer notre groupe de plans défini par l'utilisateur à la fin, après le groupe de plans intégré Systèmes de fichiers - Montage sur des instances de calcul.
4. Cliquez sur Ajouter une étape pour ouvrir la boîte de dialogue dans laquelle nous spécifierons le script pour démarrer l'application.
Fig : Paramètres de création d'une application de groupe de plans - Démarrer

Dans Ajouter une étape de groupe de plans, entrez les informations suivantes.
1. Entrez un nom d'étape simple mais descriptif. Dans cet exemple, nous utiliserons Application - Start - VM1.
2. Sélectionnez une région qui contient l'instance sur laquelle cette étape sera exécutée. Dans ce cas, le script sera exécuté sur l'application WordPress VM1 dans la région 1.
3. Sélectionnez Exécuter le script local.
4. Sélectionnez l'instance cible qui est l'application WordPress VM1 dans la région 1.
5. Dans Paramètres de script, entrez le chemin complet du script avec les paramètres. Par exemple : /home/opc/fsdrscripts/wdp_start.sh.
6. Dans Exécuter en tant qu'utilisateur, entrez opc.
7. Cliquez sur Ajouter une étape.
Fig : Paramètres de création d'une application d'étape - Démarrer - VM1

Cliquez sur Ajouter une étape pour ajouter une deuxième étape pour démarrer l'application sur VM2.

Fig : Ajouter une application d'étape - Démarrer - VM2

Dans Ajouter une étape de groupe de plans, entrez les informations suivantes.
1. Entrez un nom d'étape simple mais descriptif. Dans cet exemple, nous utiliserons Application - Start - VM2.
2. Sélectionnez une région qui contient l'instance sur laquelle cette étape sera exécutée. Dans ce cas, le script sera exécuté sur l'application WordPress VM2 dans la région 1.
3. Sélectionnez Exécuter le script local.
4. Sélectionnez l'instance cible qui est l'application WordPress VM2 dans la région 1.
5. Dans Paramètres de script, entrez le chemin complet du script avec les paramètres. Par exemple : /home/opc/fsdrscripts/wdp_start.sh.
6. Dans Exécuter en tant qu'utilisateur, entrez opc.
7. Cliquez sur Ajouter une étape.
Fig : Paramètres de création d'une application d'étape - Démarrer - VM2

Cliquez sur Ajouter.

Fig : Ajouter une application de groupe de plans - Démarrer

La personnalisation du plan de permutation est terminée.

plan-personnalisé-so-auh-complete.png

Tâche 6 : Personnaliser le plan de basculement dans la région 2

Dans cette tâche, ajoutez des groupes de plans RS personnalisés définis par l'utilisateur et des étapes pour gérer les tâches qui doivent être effectuées lors d'un basculement.

Restaurez la sauvegarde de base de données la plus récente dans la région 2 pour préparer l'environnement pour la permutation.
Mettez à jour l'enregistrement de DNS de base de données privée, ce qui permet aux machines virtuelles d'application de se connecter de façon transparente à la base de données de la région 2.

Tâche 6.1 : Sélectionner le plan de basculement

Accédez au plan de basculement créé dans la tâche 4.

Fig : Comment commencer à personnaliser le plan de basculement dans la région 2

Tâche 6.2 : Créer un groupe de plans pour exécuter des scripts personnalisés dans la région 2

Ces groupes de plans appellent les scripts nécessaires à partir de la machine virtuelle de l'application WordPress et doivent être positionnés dans le flux de travail RS avant de redémarrer les machines virtuelles de l'application WordPress. Cela garantit que la base de données MySQL est entièrement restaurée et opérationnelle avant la mise en ligne des machines virtuelles d'application.

Le plan personnalisé suivant doit être ajouté au plan de basculement préalimenté : Restaurer la sauvegarde MySQL Database et Mettre à jour le DNS de MySQL Database.

Ajoutez un groupe de plans personnalisé pour restaurer la sauvegarde de la base de données MySQL.
1. Cliquez sur Ajouter un groupe pour commencer.
2. Entrez un nom de groupe de plans simple mais descriptif. Dans cet exemple, nous utiliserons Restore MySQL DB Backup.
3. Sélectionnez le poste où le groupe de plans sera inséré dans le plan RS. Dans cet exemple, sélectionnez Ajouter après pour insérer notre groupe de plans défini par l'utilisateur après le groupe de plans intégré Instances de calcul - Lancement.
4. Cliquez sur Ajouter une étape pour ouvrir la boîte de dialogue dans laquelle nous spécifierons le script pour restaurer la sauvegarde de base de données MySQL.
Fig : Paramètres de création du groupe de plans Restaurer la sauvegarde de base de données MySQL

Dans Ajouter une étape de groupe de plans, entrez les informations suivantes.
1. Entrez un nom d'étape simple mais descriptif. Dans cet exemple, nous utiliserons Restore MySQL DB Backup. Identique au nom du groupe de plans.
2. Sélectionnez une région qui contient l'instance sur laquelle cette étape sera exécutée. Dans cet exemple, le script sera exécuté sur l'application WordPress VM1 dans la région 1.
3. Sélectionnez Exécuter le script local.
4. Sélectionnez l'instance cible qui est l'application WordPress VM1 dans la région 1.
5. Dans Paramètres de script, entrez le chemin complet du script avec les paramètres. Par exemple : /home/opc/mds_copy_restore_bkp/mds_restore_bkp.py mds01 1 --config.
6. Dans Exécuter en tant qu'utilisateur, entrez opc.
7. Cliquez sur Ajouter une étape.
Fig : Paramètres d'ajout d'une sauvegarde de base de données MySQL pour la restauration d'étape

Cliquez sur Ajouter

Fig : Ajouter un groupe de plans Restaurer la sauvegarde de base de données MySQL
Ajoutez un groupe de plans personnalisé pour mettre à jour le DNS de la base de données MySQL.
1. Cliquez sur Ajouter un groupe pour commencer.
2. Entrez un nom de groupe de plans simple mais descriptif. Dans cet exemple, nous utiliserons Update MySQL DB DNS.
3. Sélectionnez le poste où le groupe de plans sera inséré dans le plan RS. Dans cet exemple, sélectionnez Ajouter après pour insérer notre groupe de plans défini par l'utilisateur après le groupe de plans intégré Restaurer la sauvegarde de base de données MySQL.
4. Cliquez sur Ajouter une étape pour ouvrir la boîte de dialogue dans laquelle nous spécifierons le script pour mettre à jour le DNS de la base de données MySQL.
Fig : Paramètres de création du groupe de plans Mettre à jour MySQL DB DNS

Dans Ajouter une étape de groupe de plans, entrez les informations suivantes.
1. Entrez un nom d'étape simple mais descriptif. Dans cet exemple, nous utiliserons Update MySQL DB DNS. Identique au nom du groupe de plans.
2. Sélectionnez une région qui contient l'instance sur laquelle cette étape sera exécutée. Dans cet exemple, le script sera exécuté sur l'application WordPress VM1 dans la région 1.
3. Sélectionnez Exécuter le script local.
4. Sélectionnez l'instance cible qui est l'application WordPress VM1 dans la région 1.
5. Dans Paramètres de script, entrez le chemin complet du script avec les paramètres. Par exemple : /home/opc/mds_copy_restore_bkp/mds_update_dns.py mds01 demo.local mds01.demo.local.
6. Dans Exécuter en tant qu'utilisateur, entrez opc.
7. Cliquez sur Ajouter une étape.
Fig : Paramètres de création d'une mise à jour d'étape MySQL DB DNS

Cliquez sur Ajouter.

Fig : Ajouter un groupe de plans Mettre à jour MySQL DB DNS
(Facultatif) Ajoutez un groupe de plans personnalisé pour redémarrer l'application WordPress.
1. Cliquez sur Ajouter un groupe.
2. Entrez un nom de groupe de plans simple mais descriptif. Dans cet exemple, nous utiliserons Application - Restart.
3. Sélectionnez le poste où le groupe de plans sera inséré dans le plan RS. Dans cet exemple, sélectionnez Ajouter après pour insérer notre groupe de plans défini par l'utilisateur après le groupe de plans intégré Systèmes de fichiers - Montage sur des instances de calcul.
4. Cliquez sur Ajouter une étape pour ouvrir la boîte de dialogue dans laquelle nous spécifierons le script pour démarrer l'application.
Fig : Paramètres de création d'une application de groupe de plans - Redémarrer

Dans Ajouter une étape de groupe de plans, entrez les informations suivantes.
1. Entrez un nom d'étape simple mais descriptif. Dans cet exemple, nous utiliserons Application - Restart - VM1.
2. Sélectionnez une région qui contient l'instance sur laquelle cette étape sera exécutée. Dans cet exemple, le script sera exécuté sur l'application WordPress VM1 dans la région 1.
3. Sélectionnez Exécuter le script local.
4. Sélectionnez l'instance cible qui est l'application WordPress VM1 dans la région 1.
5. Dans Paramètres de script, entrez le chemin complet du script avec les paramètres. Par exemple : /home/opc/fsdrscripts/wdp_restart.sh.
6. Dans Exécuter en tant qu'utilisateur, entrez opc.
7. Cliquez sur Ajouter une étape.
Fig : Paramètres de création d'une application d'étape - Redémarrer - VM1

Cliquez sur Ajouter une étape pour ajouter une deuxième étape pour redémarrer l'application sur VM2.

Fig : Ajouter une application d'étape - Redémarrer - VM2

Dans Ajouter une étape de groupe de plans, entrez les informations suivantes.
1. Entrez un nom d'étape simple mais descriptif. Dans cet exemple, nous utiliserons Application - Start - VM2.
2. Sélectionnez une région qui contient l'instance sur laquelle cette étape sera exécutée. Dans cet exemple, le script sera exécuté sur l'application WordPress VM2 dans la région 1.
3. Sélectionnez Exécuter le script local.
4. Sélectionnez l'instance cible qui est l'application WordPress VM2 dans la région 1.
5. Dans Paramètres de script, entrez le chemin complet du script avec les paramètres. Par exemple : /home/opc/fsdrscripts/wdp_restart.sh.
6. Dans Exécuter en tant qu'utilisateur, entrez opc.
7. Cliquez sur Ajouter une étape.
Fig : Paramètres de création d'une application d'étape - Redémarrer - VM2

Cliquez sur Ajouter.

Fig : Ajouter une application de groupe de plans - Redémarrer

La personnalisation du plan de basculement s'est terminée avec succès.

plan-personnalisé-fo-auh-complete.png

Tâche 7 : Exécuter les vérifications préalables dans la région 2

Les plans RS de permutation et de basculement ont été créés dans la région de secours 2. Ces plans permettent à la récupération après sinistre de pile complète OCI de faire passer les charges de travail de la région 1 à 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 d'assurer l'état de préparation et de valider le processus de transition.

Tâche 7.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 correct 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 Exécuter les vérifications préalables.

vérification préalable-so-auh-begin.png
Fig : Affichage de l'exécution des vérifications préalables du plan de permutation

vérification préalable-so-auh-complete.png
Fig : Affichage des vérifications préalables terminées du plan de permutation

Tâche 7.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 correct 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 Exécuter les vérifications préalables.

vérification préalable-fo-auh-begin.png
Fig : Affichage de l'exécution des vérifications préalables du plan de basculement

vérification préalable-fo-auh-complete.png
Fig : Affichage des vérifications préalables terminées du plan de basculement

Tâche 8 : 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 Oracle HeatWave MySQL 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 correct 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 Exécuter le plan.

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 7.
Cliquez sur Exécuter le plan RS pour commencer.

Fig : Affichage de l'exécution du plan de permutation

Fig : Affichage du plan de permutation en cours

Surveillez le plan de permutation jusqu'à ce que la charge globale complète ait été entièrement transférée de la région 1 à la région 2.

L'exécution du plan de permutation a réussi en environ 52 minutes.

Fig : Affichage d'une exécution de plan de permutation terminée.

Tâche 9 : Créer et personnaliser des plans RS dans la région 1

Avec l'achèvement réussi de la permutation par la reprise après sinistre de pile complète OCI, la région 2 a maintenant assumé le rôle de région principale, tandis que la région 1 est passée à la région de secours.

Suivez la même approche détaillée dans les tâches 1 à 8, créez et personnalisez les plans de permutation et de basculement dans le groupe de protection RS pour la région 1, qui sert maintenant de région pair de secours.

plan-créer-dxb.png
Fig : Capture d'écran présentant les plans créés dans la région 1

Fig : Capture d'écran présentant le plan de permutation dans la région 1

Fig : Capture d'écran présentant le plan de basculement dans la région 1

Étapes suivantes

Pour plus d'informations, voir la documentation OCI sur la récupération après sinistre de pile complète et Oracle HeatWave MySQL dans la section Liens connexes.

Récupération après sinistre de pile complète pour Oracle Cloud Infrastructure (OCI)
Oracle HeatWave MySQL
OCI - Récupération après sinistre de pile complète
HeatWave MySQL
Rejoindre le canal latent #full-stack-dr

Confirmation

Auteur - Antoun Moubarak (Hyperscaler pour spécialiste OCI)
Contributeur - Suraj Ramesh (Gestionnaire de produit pour la récupération après sinistre de pile complète OCI)

Autres ressources d'apprentissage

Explorez d'autres laboratoires sur la page docs.oracle.com/learn ou accédez à plus de contenu d'apprentissage gratuit sur le canal YouTube d'Oracle Learning. De plus, visitez education.oracle.com/learning-explorer pour devenir un explorateur Oracle Learning.

Pour obtenir de la documentation sur le produit, visitez Oracle Help Center.

Titre et Copyright

Automate Cold Disaster Recovery for Oracle HeatWave MySQL using OCI Full Stack Disaster Recovery

G24410-01

January 2025

Oracle et/ou ses sociétés affiliées.