Automatiser les modifications de rôle de base de données pour Oracle Data Guard configuré manuellement dans les services de base de données OCI à l'aide d'OCI Full Stack DR et de scripts personnalisés

Introduction

Oracle Cloud Infrastructure Full Stack Disaster Recovery (OCI Full Stack DR) orchestre la transition du calcul, de la base de données et des applications entre les régions Oracle Cloud Infrastructure (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 métier sans repenser ou modifier l'architecture de l'infrastructure, des bases de données ou des applications existantes et sans avoir besoin de serveurs de gestion ou de conversion spécialisés.

OCI Full Stack DR offre une prise en charge entièrement intégrée de divers services Oracle Database sur OCI. Ces bases de données peuvent être ajoutées en tant que membres d'un groupe de protection de récupération après sinistre OCI Full Stack, ce qui permet des opérations de récupération après sinistre coordonnées.

Pour les services gérés par des bases de données Oracle dans OCI, il est fortement recommandé de configurer Oracle Data Guard à l'aide de la console OCI, de l'interface de ligne de commande Oracle Cloud Infrastructure (interface de ligne de commande OCI) ou des kits SDK OCI. Ainsi, OCI Full Stack DR peut détecter automatiquement la configuration Data Guard et générer des groupes de plans intégrés pour les transitions de rôle dans le cadre de votre plan de récupération après sinistre.

Toutefois, dans certains scénarios, la configuration manuelle d'Oracle Data Guard (en dehors des interfaces natives d'OCI) devient nécessaire en raison d'exigences techniques ou opérationnelles spécifiques, telles que :

• Contraintes propres aux applications.
• Configurations de secours en cascade.
• Utilisation d'anciennes versions de base de données en raison de la compatibilité des applications.

Dans ce cas, bien que le plan de contrôle des services OCI Database ne reconnaisse pas la configuration Oracle Data Guard, OCI Full Stack DR offre toujours de la flexibilité. Vous pouvez gérer les transitions de rôle en créant des scripts personnalisés et en les intégrant à des groupes de plans définis par l'utilisateur dans vos plans de récupération après sinistre.

Cette solution n'est pas compatible avec les services Oracle Database Cloud où les configurations Data Guard sont gérées via la console OCI, les kits SDK ou les API.

Dans ce tutoriel, nous aborderons une approche standardisée de gestion des transitions de rôle Oracle Data Guard à l'aide de scripts de gestionnaire de base de données personnalisés pour les services OCI Database dans lesquels Oracle Data Guard a été configuré manuellement.

Remarque : cette solution de script personnalisé s'applique aux services OCI Database suivants :

• Oracle Base Database Service
• Oracle Exadata Database Service on Dedicated Infrastructure
• Oracle Exadata Database Service on Exascale Infrastructure
• Oracle Exadata Database Service on Cloud@Customer

Description de l'architecture

Dans ce tutoriel, nous allons utiliser Oracle Base Database Service avec deux systèmes de base de données déployés dans deux régions OCI, où Oracle Data Guard a été configuré manuellement.

Figure A : Configuration Data Guard personnalisée à l'aide d'Oracle Base Database Service

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

• Régions:

  • Région 1 (Ashburn) : Ashburn servira initialement de région principale.

  • Région 2 (Phoenix) : Phoenix fonctionnera initialement en tant que région de secours.

• Compartiments : vous êtes libre d'organiser ce déploiement et OCI Full Stack DR 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.

Objectifs

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

• Tâche 1 : vérifiez la configuration Oracle Data Guard et mettez à jour les balises.
• Tâche 2 : créez et associez des groupes de protection de récupération après sinistre.
• Tâche 3 : ajoutez des membres aux groupes de protection de récupération après sinistre.
• Tâche 4 : créez et personnalisez les plans de récupération après sinistre dans la région 2.
• Tâche 5 : exécutez des prévérifications pour les plans de récupération après sinistre dans la région 2.
• Tâche 6 : exécutez le plan de permutation dans la région 2.
• Tâche 7 : créez et personnalisez les plans de récupération après sinistre dans la région 2.

Prérequis

Nous allons utiliser les ressources suivantes pour commencer avec le tutoriel.

Ressources	Région 1 - Ashburn	Région 2 - Phoenix
Compartiment	application	application
Système de base de données	adghol-12345	adghol-12345
Nom de base de données	adghol	adghol
Nom unique de la base de données	adghol-site0	adghol-site1
Rôle de BdD	principal	standby
Machine virtuelle de calcul	script-iad	script-phx
Bucket	IAD	PHX

Remarque : remplissez tous les prérequis requis avant de continuer. Ces étapes jettent les bases d'une configuration OCI Full Stack DR fluide et réussie.

1. Administrateur ou stratégies Oracle Cloud Infrastructure Identity and Access Management (OCI IAM) requises.

   Assurez-vous de disposer de privilèges d'administrateur ou configurez les stratégies OCI IAM et les groupes dynamiques nécessaires pour utiliser OCI Full Stack DR. Dans cette solution, le script de gestionnaire de base de données lance en interne une instance de conteneur OCI. Vous devez donc ajouter des stratégies en conséquence.

   Remarque : remplacez toutes les occurrences de <compartment_ocid> et <compartment_name> par l'OCID et le nom réels du compartiment OCI.

   1. Créer un groupe dynamique : créez un groupe dynamique portant le nom d'exemple (FullStackDR_Database_DG) et ajoutez les règles de mise en correspondance suivantes :

       Any {instance.compartment.id = '<compartment_ocid>'}
       Any {resource.type = 'instance', resource.compartment.id = '<compartment_ocid>'}
       Any {resource.type = 'computecontainerinstance', resource.compartment.id = '<compartment_ocid>'}
       Any {resource.type = 'drprotectiongroup', resource.compartment.id = '<compartment_ocid>'}
      

   2. Création d'une stratégie OCI IAM : créez une stratégie avec le nom d'exemple (FullStackDR_Database_Group_Policies) et ajoutez les instructions d'autorisation suivantes :

       Allow dynamic-group FullStackDR_Database_DG to read secret-family in compartment <compartment_name>
       Allow dynamic-group FullStackDR_Database_DG to manage virtual-network-family in compartment <compartment_name>
       Allow dynamic-group FullStackDR_Database_DG to manage instance-agent-command-family in compartment <compartment_name>
       Allow dynamic-group FullStackDR_Database_DG to manage instance-agent-command-execution-family in compartment <compartment_name>
       Allow dynamic-group FullStackDR_Database_DG to manage objects in compartment <compartment_name>
       Allow dynamic-group FullStackDR_Database_DG to manage database-family in compartment <compartment_name>
       Allow dynamic-group FullStackDR_Database_DG to manage compute-container-family in compartment <compartment_name>
      

   Pour plus d'informations, reportez-vous à Stratégies de récupération après sinistre OCI – Documents officiels et à Configuration de stratégies IAM (Blog Oracle).

2. Provisionner des instances OCI Compute dans les deux régions : créez une instance OCI Compute dans chaque région afin de servir de Jumphost pour héberger et exécuter les étapes détaillées scripts.For. Reportez-vous à Création d'une instance OCI. Pour plus de simplicité, nous ferons référence à cette instance OCI Compute en tant qu'Jumphost sur l'ensemble du site tutorial.If pour lequel vous disposez déjà d'instances OCI Compute existantes qui peuvent fonctionner en tant que Jumphost. Vous pouvez ignorer cette étape. Assurez-vous que l'agent Oracle Cloud de Jumphost est en cours d'exécution et que le module d'extension d'exécution de commande est activé. Pour plus d'informations, reportez-vous à Agent Oracle Cloud.

3. Accès aux commandes d'exécution sur les instances OCI Compute : veillez à configurer les prérequis de la commande d'exécution dans l'hôte Jumphost, car nous utilisons des groupes de plans définis par l'utilisateur pour exécuter des scripts lors des opérations de récupération après sinistre. Pour plus d'informations, reportez-vous à Exécution de commandes sur une instance.

4. Installer l'interface de ligne de commande OCI dans l'hôte de saut sur les deux régions : en fonction du système d'exploitation de l'hôte de saut, installez l'interface de ligne de commande OCI sur les deux régions et assurez-vous que vous pouvez appeler des commandes d'interface de ligne de commande OCI. Dans le script, nous utiliserons le principal d'instance. Pour plus d'informations, reportez-vous à Installation de l'interface de ligne de commande OCI.

5. Configuration de réseaux cloud virtuels dans les deux régions avec l'appairage VCN distant : créez des réseaux cloud virtuels dans les régions principale et de secours, et configurez l'appairage VCN distant. Cette opération est requise pour configurer Oracle Data Guard inter-région. Pour plus d'informations, reportez-vous à Configuration réseau OCI Base DB.

6. Configuration manuelle d'Oracle Data Guard : configurez manuellement la configuration d'Oracle Data Guard en fonction des exigences du broker Oracle Data Guard. Pour plus d'informations, reportez-vous à Oracle Data Guard Broker et Oracle Clusterware.

7. Télécharger les scripts de gestionnaire de base de données dans Jumphost : les scripts doivent être téléchargés et conservés dans Jumphost dans les deux régions.

   1. Téléchargez les scripts de gestionnaire de base de données Oracle Data Guard à partir du référentiel suivant : Script de gestionnaire de base de données Data Guard.

   2. Copiez les scripts dans le répertoire /home/opc/ (ou tout autre chemin préféré) sur l'hôte Jumphost dans les deux régions.

   3. Assurez-vous que les fichiers de script disposent des droits d'accès exécutables.

   4. full_stack_dr_non_std_db_handler.py est le script Python responsable de la gestion du rôle Oracle Data Guard. Les scripts bash associés transitions.The sont fournis en tant que modèles et peuvent être modifiés pour répondre à vos besoins spécifiques. Ne modifiez pas le script de modification de rôle Python lui-même.

8. Créer un coffre OCI et des clés secrètes : vous devez créer un coffre OCI et stocker les informations d'identification de base de données en tant que clés secrètes dans les deux régions.

   1. Créez un coffre OCI dans chaque région à l'aide de la console ou de l'interface de ligne de commande OCI.
   2. Créez une clé secrète dans le coffre afin de stocker le mot de passe utilisateur SYS pour la base de données.

   Pour plus d'informations, reportez-vous à Coffrets OCI.

9. Vérifications de connectivité à partir de Jumphost : assurez-vous que le service OCI Database, le service OCI Vault et le service d'instance de conteneur OCI sont accessibles à partir de l'instance de calcul. Cela est requis car les scripts de récupération après sinistre de pile complète OCI effectuent une introspection pour extraire les détails de base de données des régions principales et de secours.

   1. La connectivité doit fonctionner depuis le jumphost. Exécutez les commandes suivantes à partir de l'hôte Jumphost.

        # Primary Region
        curl -v telnet://database.<primary_region>.oraclecloud.com:443
        curl -v telnet://secrets.vaults.<primary_region>.oci.oraclecloud.com:443
        curl -v telnet://iaas.<primary_region>.oraclecloud.com:443
        curl -v telnet://compute-containers.<primary_region>.oci.oraclecloud.com:443
      
        # Standby Region
        curl -v telnet://database.<standby_region>.oraclecloud.com:443
        curl -v telnet://secrets.vaults.<standby_region>.oci.oraclecloud.com:443
        curl -v telnet://iaas.<standby_region>.oraclecloud.com:443
        curl -v telnet://compute-containers.<standby_region>.oci.oraclecloud.com:443
      

      Remarque : remplacez <primary_region> et <standby_region> par des identificateurs de région OCI réels.
      Exemple :

      • us-ashburn-1 pour Ashburn
      • us-phoenix-1 pour Phoenix

      Pour obtenir la liste complète, reportez-vous à Identificateurs de région OCI.

      Sortie attendue : chaque commande doit renvoyer un message similaire à Connected to ....

      Si une connexion échoue, vérifiez les listes de sécurité, les tables de routage et la configuration de passerelle de service du VCN/sous-réseaux de l'hôte jumphost.

10. Créer des buckets Object Storage : créez des buckets OCI Object Storage dans les régions principale et de secours pour stocker les journaux générés par OCI Full Stack DR lors des opérations de récupération après sinistre, comme expliqué ici : Préparation de l'emplacement des journaux d'opération.

11. Utilisation et personnalisation des scripts de gestionnaire de base de données : vous pouvez télécharger les scripts de gestionnaire de base de données à partir du référentiel GitHub mentionné. Voici l'utilisation du script du gestionnaire de base de données et les paramètres requis.

    
    Fig B : utilisation des scripts de gestionnaire de base de données

    Les options --db_operation sont prises en charge :

    • PERMUTATION DE RÔLES
    • SWITCHOVER_PRECHECK
    • Basculement
    • FAILOVER_PRECHECK
    • CONVERT_PHYSICAL_TO_SNAPSHOT_STANDBY
    • CONVERT_PHYSICAL_TO_SNAPSHOT_STANDBY_PRECHECK
    • REVERT_SNAPSHOT_TO_PHYSICAL_STANDBY_PRECHECK
    • REVERT_SNAPSHOT_TO_PHYSICAL_STANDBY

    OCI Full Stack DR s'attend à ce que tous les paramètres requis soient transmis lors de l'exécution du script de gestionnaire de base de données. Pour une meilleure convivialité et répétabilité, il est recommandé de créer un script bash wrapper qui :

    • Fournit les paramètres requis.
    • Active la journalisation pour l'audit et le dépannage.

    Exemple : Script de permutation de base de données (db-switchover-iad-phx.sh).

    #!/bin/bash
    
    # Define log file with date and time
    LOG_FILE="db-switchover-iad-phx-$(date +%Y%m%d_%H%M%S).log"
    
    # Define Python script and argument
    PYTHON_SCRIPT="full_stack_dr_non_std_db_handler.py"
    ARGUMENT="--database_ocid="ocid1.database.oc1.phx.xxxxxxxx" --vault_ocid="ocid1.vaultsecr
    et.oc1.phx.xxxxx" --region="us-phoenix-1" --primary_db_unique_name="adghol_site0" --st
    andby_db_unique_name="adghol_site1" --drpg_ocid="ocid1.drprotectiongroup.oc1.phx.axxxxxxax
    " --db_operation="SWITCHOVER" --auth_type=INSTANCE_PRINCIPAL"
    
    # Execute Python script and log output
    echo "Executing Python script: $PYTHON_SCRIPT with argument: $ARGUMENT" | tee -a $LOG_FILE
    /usr/bin/python3 $PYTHON_SCRIPT $ARGUMENT 2>&1 | tee -a $LOG_FILE
    
    echo "Execution completed. Logs saved in $LOG_FILE"
    

    Remarque : stockez ce script wrapper au même emplacement que vos scripts de gestionnaire de base de données et assurez-vous qu'il est exécutable. Les OCID sont anonymisés dans le script.

    chmod +x db-switchover-wrapper.sh
    

    Mappage de script de plan de récupération après sinistre où la base de données exécutée dans la région 1 (Ashburn) est principale et la région 2 (Phoenix) est de secours

    Type de plan de récupération après sinistre	Instance cible	Nom du script	Commentaire
    Switchover	script-phx	db-prechk-switchover-iad-phx.sh	Permutation de base de données Prechk d'IAD vers PHX
    Switchover	script-phx	db-switchover-iad-phx.sh	Basculement de la base de données d'IAD vers PHX
    Failover	script-phx	db-prechk-failover-iad-phx.sh	Basculement de base de données Prechk d'IAD vers PHX
    Failover	script-phx	db-failover-iad-phx.sh	Basculement de la base de données d'IAD vers PHX
    Start drill	script-phx	db-prechk-startdrill-phx.sh	Exploration de récupération après sinistre avant démarrage dans PHX
    Start drill	script-phx	db-startdrill-phx.sh	Démarrer l'exploration de récupération après sinistre dans PHX
    Stop drill	script-phx	db-prechk-stopdrill-phx.sh	Analyse de récupération après sinistre avant arrêt dans PHX
    Stop drill	script-phx	db-stopdrill-phx.sh	Arrêter l'exploration de récupération après sinistre dans PHX

    Mappage de script de plan de récupération après sinistre où la base de données exécutée dans la région 2 (Phoenix) est principale et la région 2 (Ashburn) est de secours

    Type de plan de récupération après sinistre	Instance cible	Nom du script	Commentaire
    Switchover	script-iad	db-prechk-switchover-phx-iad.sh	Préchk DB Switchover de PHX à IAD
    Switchover	script-iad	db-switchover-phx-iad.sh	Basculement de la base de données de PHX vers IAD
    Failover	script-iad	db-prechk-failover-phx-iad.sh	Basculement de base de données Prechk de PHX vers IAD
    Failover	script-iad	db-failover-phx-iad.sh	Basculement de la base de données de PHX vers IAD
    Start drill	script-iad	db-prechk-startdrill-iad.sh	Exploration de récupération après sinistre avant démarrage dans IAD
    Start drill	script-iad	db-startdrill-iad.sh	Démarrer l'exploration de récupération après sinistre dans IAD
    Stop drill	script-iad	db-prechk-stopdrill-iad.sh	Exploration de récupération après sinistre avant arrêt dans IAD
    Stop drill	script-iad	db-stopdrill-iad.sh	Arrêter l'exploration DR dans IAD

Remarque : pour plus de clarté et de facilité d'utilisation, nous avons créé plusieurs scripts de wrapper bash adaptés à des types et régions de plan de récupération après sinistre spécifiques. Ces scripts utilisent un script Python partagé pour les transitions de rôle de base de données, que vous pouvez personnaliser en fonction de vos propres exigences et de votre environnement.

Tâche 1 : vérifier la configuration d'Oracle Data Guard et mettre à jour la balise

Dans cette tâche, nous allons vérifier la configuration manuelle d'Oracle Data Guard à l'aide d'Oracle Base Database Service. Nous allons créer une *balise** dans la base de données pour indiquer une configuration Oracle Data Guard non standard. OCI Full Stack DR peut ainsi créer un plan de récupération après sinistre sans s'appuyer sur des groupes de plans intégrés.

1. Connectez-vous à la console OCI et accédez à Oracle Database, puis cliquez sur Oracle Base Database Service.

2. Assurez-vous que le contexte de région OCI est défini sur Région 1 (Ashburn).

3. Sélectionnez le système de base de données. Dans notre exemple, il s'agit de adghol0-12345.

   
   Figure 1.1 : Système de base de données de la région 1

4. Accédez à l'onglet Bases de données et sélectionnez la base de données adghol.

   
   Figure 1.2 : Base de données dans la région 1

5. Vérifiez que le statut Data Guard est Non activé, ce qui confirme qu'Oracle Data Guard n'est pas configuré à l'aide de la console OCI.

   
   Figure 1.3 : Statut du plan de contrôle Data Guard dans la région 1

6. Accédez à l'onglet Balises et créez les balises à format libre. Vous devez remplacer la valeur de Peer DB OCID en fonction de votre configuration. Dans cet exemple, vous devez ajouter l'OCID de base de données de la région Phoenix.

   Clé de balise	Value
   FsdrNonStandardDataGuardPeerDatabaseId	Peer DB OCID
   FsdrNonStandardDataGuardFlag	True

   
   Figure 1.4 : Balises de base de données dans la région 1

7. Accédez aux systèmes de base de données et sélectionnez noeuds.

   
   Figure 1.5 : Noeud de base de données dans la région 1

   Remarque : il s'agit d'une configuration non RAC. Un noeud de base de données unique apparaît. S'il s'agissait d'une configuration Oracle Real Application Clusters, vous verrez deux noeuds.

8. Connectez-vous au noeud de base de données et passez à l'utilisateur oracle. Utilisez le broker Oracle Data Guard pour vérifier les rôles.

   dgmgrl
   show configuration
   

   
   Figure 1.6 : Statut Data Guard dans la région 1

   Sortie attendue :

   • adghol_site0 doit apparaître en tant que base de données principale.
   • adghol_site1 doit apparaître en tant que base de secours physique.
   • Configuration Status doit apparaître comme Succès.

   Si des erreurs se produisent et que les rôles de base de données ne sont pas ceux attendus, vous devez les corriger à l'aide de la documentation Oracle Data Guard.

9. Connectez-vous à la console OCI et accédez à Oracle Database, puis cliquez sur Oracle Base Database Service.

10. Assurez-vous que le contexte de région OCI est défini sur Région 2 (Phoenix).

11. Sélectionnez le système de base de données. Dans notre exemple, il s'agit de adghol1-12345

    
    Figure 1.7 : Système de base de données de la région 2

12. Accédez à l'onglet Bases de données et sélectionnez la base de données adghol.

    
    Figure 1.8 : Base de données dans la région 2

13. Vérifiez que le statut Data Guard est Non activé, ce qui confirme qu'Oracle Data Guard n'est pas configuré à l'aide de la console OCI.

    
    Figure 1.9 : Statut du plan de contrôle Data Guard dans la région 2

14. Accédez à l'onglet Balises et créez les balises à format libre. Vous devez remplacer la valeur de Peer DB OCID en fonction de votre configuration. Dans cet exemple, vous devez ajouter l'OCID de base de données de la région Ashburn.

    Clé de balise	Value
    FsdrNonStandardDataGuardPeerDatabaseId	Peer DB OCID
    FsdrNonStandardDataGuardFlag	True

    
    Figure 1.10 : Balises de base de données dans la région 2

15. Répétez les étapes 7 et 8, mais cette fois, connectez-vous au noeud de base de données de la région 2 (région de secours).

    • Assurez-vous que vous êtes connecté en tant qu'utilisateur oracle sur le noeud de base de données Région 2.
    • Vérifiez les rôles Oracle Data Guard à l'aide de dgmgrl, comme à l'étape 8.

Tâche 2 : créer et associer des groupes de protection de récupération après sinistre

Créez des groupes de protection de récupération après sinistre 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

1. Accédez à la console OCI et accédez à Groupes de protection de récupération après sinistre comme illustré dans la figure 2.1.

   1. Assurez-vous que le contexte de région OCI est défini sur Région 1 (Ashburn).
   2. Cliquez sur Migration et récupération après sinistre.
   3. Cliquez sur Groupes de protection de récupération après sinistre.

   
   Figure 2.1 : Accédez aux groupes de protection de récupération après sinistre.

2. Créez un groupe de protection de récupération après sinistre de base dans la région 1, comme illustré dans la figure 2.2. Le pair, le rôle et les membres seront affectés dans des étapes ultérieures.

   1. Sélectionnez le compartiment dans lequel créer le groupe de protection de récupération après sinistre.
   2. Cliquez sur Créer un groupe de protection de récupération après sinistre.
   3. Utilisez un nom explicite pour le groupe de protection de récupération après sinistre.
   4. Sélectionnez Bucket OCI Object Storage pour les journaux OCI Full Stack DR.
   5. Cliquez sur Créer.

   
   Figure 2.2 : Paramètres nécessaires pour créer un groupe de protection de récupération après sinistre dans la région 1

Tâche 2.2 : créer un groupe de protection dans la région 2

1. Accédez à la console OCI, puis à Groupes de protection de récupération après sinistre, comme illustré à la figure 2.3.

   1. Assurez-vous que le contexte de région OCI est défini sur Région 2 (Phoenix).
   2. Cliquez sur Migration et récupération après sinistre.
   3. Cliquez sur Groupes de protection de récupération après sinistre.

   
   Figure 2.3 : Accédez aux groupes de protection de récupération après sinistre.

2. Créez un groupe de protection de récupération après sinistre de base dans la région 2, comme illustré à la figure 2.4. Le pair, le rôle et les membres seront affectés dans des étapes ultérieures.

   1. Sélectionnez le compartiment dans lequel créer le groupe de protection de récupération après sinistre.
   2. Cliquez sur Créer un groupe de protection de récupération après sinistre.
   3. Utilisez un nom explicite pour le DRPG.
   4. Sélectionnez Bucket OCI Object Storage pour les journaux OCI Full Stack DR.
   5. Cliquez sur Créer.

   
   Figure 2.4 : Paramètres nécessaires pour créer un groupe de protection de récupération après sinistre dans la région 2

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

Associez les DRPG de chaque région en tant que pairs et affectez les rôles homologues de la base de données principale et de la base de données de secours. Les rôles de la base de données principale et de la base de données de secours sont automatiquement modifiés par OCI Full Stack DR dans le cadre de toute exécution d'opération de récupération après sinistre/de plan de récupération après sinistre. Il n'est pas nécessaire de gérer les rôles manuellement à tout moment.

1. Accédez à la page des détails du groupe de protection de récupération après sinistre.

   1. Assurez-vous que le contexte de région OCI est défini sur Région 1 (Ashburn).
   2. Cliquez sur le menu déroulant Actions, puis sur Associer pour lancer le processus.

   
   Fig 2.5 : Commencer l'association DRPG

2. Saisissez les informations suivantes .

   1. Rôle : sélectionnez le rôle Principal. OCI Full Stack DR affectera automatiquement le rôle de secours à la région 2.
   2. Région homologue : sélectionnez la région 2 (Phoenix), où l'autre groupe de protection de récupération après sinistre a été créé.
   3. Groupe de protection de récupération après sinistre homologue : sélectionnez le groupe de protection de récupération après sinistre homologue qui a été créé.
   4. Cliquez sur Associer.

   
   Fig 2.6 : paramètres nécessaires pour associer les DRPG

Une fois l'association terminée, la récupération après sinistre complète de la pile OCI affiche un résultat similaire à celui illustré dans l'image suivante.

• Le DRPG homologue principal actuel est Ashburn (région 1).
• Le pair de secours actuel DRPG est Phoenix (région 2).

Fig 2.7 : affichage de la relation homologue du point de vue du DRPG individuel

Les mêmes informations peuvent être trouvées chaque fois que le contexte/la vue est d'un point de vue global montrant tous les groupes de protection de récupération après sinistre comme indiqué dans l'image suivante.

• Le DRPG homologue principal actuel est Ashburn (région 1).
• Le pair de secours actuel DRPG est Phoenix (région 2).

Fig 2.8 : Affichage de la relation homologue du point de vue global du DRPG

Tâche 3 : ajout de membres aux groupes de protection de récupération après sinistre

Dans cette tâche, nous ajouterons les ressources OCI suivantes au groupe de protection de récupération après sinistre principal dans la région 1.

1. L'instance OCI Compute hébergeant le script de gestionnaire de base de données sera ajoutée en tant que machine virtuelle mobile.
2. Le système de base de données principal.

Tâche 3.1 : ajouter des membres au groupe de protection de récupération après sinistre dans la région 1

1. Sélectionnez le groupe de protection de récupération après sinistre dans la région 1, comme indiqué dans l'image suivante.

   1. Assurez-vous que le contexte de région OCI est Région 1 (Ashburn).
   2. Sélectionnez le groupe de protection de récupération après sinistre dans la région 1.
   3. Accédez à l'onglet Membres.
   4. Cliquez sur Gérer les membres.

   
   Fig 3.1 : comment commencer à ajouter des membres au groupe de protection de récupération après sinistre dans la région 1

2. Ajoutez une instance de calcul pour les scripts de gestionnaire de base de données.

   1. Sélectionnez Ajouter un membre.
   2. Sélectionnez Instance sous Calcul en tant que type de ressource de membre.
   3. Sélectionnez l'instance de calcul hébergeant les scripts de gestionnaire de base de données.
   4. Sélectionnez Instance non mobile.
   5. Cliquez sur Ajouter.

   
   Fig 3.2 : ajout d'une instance de calcul au DRPG dans la région 1

   Vérifiez l'instance de calcul ajoutée.

   
   Fig 3.2 : instance de calcul ajoutée au DRPG dans la région 1

3. Ajoutez la base de données principale. Cliquez sur Ajouter un membre.

   1. Sélectionnez Ajouter un membre.
   2. Sélectionnez Oracle Database -> Base de données (Base DB,ExaDB-D,ExaCC,ExaXS) en tant que type de ressource de membre.
   3. Sélectionnez Oracle Base Database en tant que type de base de données.
   4. Sélectionnez Système de base de données.
   5. Sélectionnez Répertoire de base de la base de données.
   6. Sélectionnez Base de données.
   7. Sélectionner une clé secrète de mot de passe
   8. Cliquez sur Ajouter.

   
   Fig 3.3 : paramètres nécessaires pour ajouter la base de données principale

   Vérifiez la base principale ajoutée et publiez les deux membres.

   
   Fig 3.4 : base de données principale ajoutée au DRPG dans la région 1

   
   Fig 3.5 : publier des membres dans le DRPG de la région 1

   Après quelques minutes, les deux membres devraient être disponibles sous les membres.

   
   Fig 3.6 : membres ajoutés au DRPG dans la région 1

Tâche 3.2 : Ajouter des membres au groupe de protection de récupération après sinistre dans la région 2

1. Sélectionnez le groupe de protection de récupération après sinistre dans la région 2, comme indiqué dans l'image suivante.

   1. Assurez-vous que le contexte de région OCI est Région 2 (Phoenix).
   2. Sélectionnez le groupe de protection de récupération après sinistre dans la région 2.
   3. Accédez à l'onglet Membres.
   4. Cliquez sur Gérer les membres.

   
   Fig 3.7 : comment commencer à ajouter des membres au groupe de protection de récupération après sinistre dans la région 2

2. Ajoutez une instance de calcul pour les scripts de gestionnaire de base de données.

   1. Sélectionnez Ajouter un membre.
   2. Sélectionnez Instance sous Calcul en tant que type de ressource de membre.
   3. Sélectionnez l'instance de calcul hébergeant les scripts de gestionnaire de base de données.
   4. Sélectionnez Instance non mobile.
   5. Cliquez sur Ajouter.

   
   Fig 3.8 : ajout d'une instance de calcul au DRPG dans la région 2

   Vérifiez l'instance de calcul ajoutée.

   
   Fig 3.9 : instance de calcul ajoutée au DRPG dans la région 2

3. Ajout de la base de données de secours. Cliquez sur Ajouter un membre.

   1. Sélectionnez Ajouter un membre.
   2. Sélectionnez Oracle Database -> Base de données (Base DB,ExaDB-D,ExaCC,ExaXS) en tant que type de ressource de membre.
   3. Sélectionnez Oracle Base Database en tant que type de base de données.
   4. Sélectionnez Système de base de données.
   5. Sélectionnez Répertoire de base de la base de données.
   6. Sélectionnez Base de données.
   7. Sélectionner une clé secrète de mot de passe
   8. Cliquez sur Ajouter.

   
   Fig 3.10 : paramètres nécessaires pour ajouter la base de données de secours

   Vérifiez la base de données de secours ajoutée et publiez les deux membres.

   
   Fig 3.11 : base de données de secours ajoutée au DRPG dans la région 2

   
   Fig 3.12 : publier des membres dans le DRPG dans la région 2

   Après quelques minutes, les deux membres devraient être disponibles sous les membres.

   
   Fig 3.13 : membres ajoutés au DRPG dans la région 2

Tâche 4 : Créer et personnaliser les plans de récupération après sinistre dans la région 2

Dans cette tâche, nous allons créer les plans Switchover, Failover et Start Drill initiaux associés au groupe de protection de récupération après sinistre de secours dans la région 2 (Phoenix).

Ces plans sont conçus pour faire passer la charge globale de la région principale (région 1) à la région de secours (région 2).

• OCI Full Stack DR pré-alimente ces plans avec des étapes intégrées en fonction des ressources membres ajoutées précédemment.
• Toutefois, dans ce tutoriel, étant donné qu'Oracle Data Guard est configuré manuellement (en dehors du plan de contrôle de base de données), aucun groupe de plans intégré n'est disponible pour les transitions de rôle de base de données Oracle.
• Nous allons donc :
  • Personnalisez les plans de récupération après sinistre avec des groupes de plans définis par l'utilisateur.
  • Ajoutez des scripts de gestionnaire de base de données pour gérer les transitions de rôle pendant chaque type de plan (permutation, basculement, exploration).

Les plans de récupération après sinistre sont toujours créés dans le groupe de protection qui détient le rôle de secours.

Etant donné que la région 2 (Phoenix) est actuellement la base de secours, nous y créerons tous les plans de récupération après sinistre initiaux.

Tâche 4.1 : Créer des plans de récupération après sinistre

1. Créer des plans de récupération après sinistre en sélectionnant le DRPG dans la région 2 (Phoenix)

   1. Assurez-vous que le contexte de région OCI est Région 2 (Phoenix).
   2. Sélectionnez le DRPG de secours dans la région 2.
   3. Accédez à l'onglet Plans.
   4. Cliquez sur Créer un plan.

   
   Fig 4.1 : Comment créer des plans de récupération après sinistre de base dans la région 2

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 Basculement (planifié).

   
   Fig 4.2 : paramètres nécessaires à la création du plan de permutation de récupération après sinistre

3. Créez un plan de basculement.

   Suivez la même procédure pour créer un plan de basculement de base, comme indiqué dans l'image suivante.

   1. Entrez le nom du plan de basculement simple mais significatif.
   2. Sélectionnez Type de plan comme Basculement (non planifié).

   
   Fig 4.3 : paramètres nécessaires à la création du plan de basculement de récupération après sinistre

4. Créez un plan d'analyse de démarrage.

   Suivez la même procédure pour créer un plan de basculement de base, comme indiqué dans l'image suivante.

   1. Entrez le nom du plan d'analyse de démarrage simple mais significatif.
   2. Sélectionnez Type de plan comme Basculement (non planifié).

   
   Fig 4.4 : paramètres nécessaires à la création d'un plan d'analyse de démarrage de récupération après sinistre

   Le groupe de protection de récupération après sinistre de secours de la région 2 doit désormais disposer des trois plans de récupération après sinistre, comme indiqué dans l'image suivante. Ils gèrent la transition des charges de travail de la région 1 vers la région 2. Vous allez créer des plans similaires dans la région 1 pour transférer les charges globales de la région 2 vers la région 1 dans une tâche ultérieure.

   
   Fig 4.5 : affichage des trois plans de récupération après sinistre qui doivent exister dans la région 2 avant de poursuivre

Remarque : OCI Full Stack DR vous permet de créer un plan d'exploration d'arrêt uniquement une fois que le plan d'exploration de démarrage a été exécuté et que le groupe de protection de récupération après sinistre est à l'état Inactif (exploration en cours).

Tâche 4.2 : Personnaliser les plans de récupération après sinistre à l'aide de groupes de plans définis par l'utilisateur

Les plans de récupération après sinistre créés dans la tâche 4.1 ne généreront aucun groupe de plans intégré pour les transitions de rôle de base de données Oracle depuis que la configuration Oracle Data Guard a été effectuée manuellement.

Dans cette tâche, vous allez :

• Découvrez comment ajouter des groupes de plans de récupération après sinistre personnalisés et définis par l'utilisateur.
• Définissez les étapes nécessaires à la gestion des transitions de rôle Oracle Data Guard.

Ainsi, vos plans de récupération après sinistre peuvent entièrement gérer les scénarios de basculement, de permutation et d'exploration impliquant un environnement Data Guard configuré manuellement.

1. Accédez au plan de permutation créé dans la tâche 4.1 et sélectionnez Groupes de plans.

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

2. Commencez par ajouter des groupes de plans de récupération après sinistre définis par l'utilisateur personnalisés pour adapter le workflow de récupération après sinistre aux besoins spécifiques des modifications de rôle de base de données Oracle. Ces groupes de plans appellent les scripts nécessaires à partir de l'hôte jumphost script-iad dans la région 1.

3. Ajoutez un groupe de plans défini par l'utilisateur à permutation de base de données.

   1. Cliquez sur Ajouter un groupe,
   2. Entrez un nom de groupe de plans simple mais descriptif. Dans cet exemple, nous allons utiliser DB Switchover.

   3. Cliquez sur Ajouter une étape pour ouvrir la boîte de dialogue dans laquelle nous indiquerons le script permettant de modifier le rôle de base de données.

      
      Fig 4.7 : Paramètres permettant de créer un groupe de plans pour effectuer un changement de rôle de base de données

      Dans Ajouter une étape de groupe de plans, entrez les informations suivantes.

   4. Entrez un nom d'étape simple mais descriptif. Dans cet exemple, nous allons utiliser DB Switchover from IAD to PHX.
   5. Sélectionnez une région d'instance contenant l'instance sur laquelle cette étape est exécutée. Dans cet exemple, le script sera exécuté sur l'hôte jumphost dans la région 2. Sélectionnez donc Phoenix.
   6. Sélectionnez Exécuter un script local.
   7. Sélectionnez Instance cible, qui est l'hôte de saut script-phx dans la région 2.
   8. Dans Paramètres de script, entrez le chemin complet du script avec les paramètres. Par exemple : /home/opc/db-switchover-iad-phx.sh.
   9. Dans Exécuter en tant qu'utilisateur, entrez opc.

   10. Cliquez sur Ajouter une étape.

       
       Fig 4.8 : Paramètres permettant d'ajouter une étape pour le changement de rôle de base de données

   11. Vérifiez l'étape ajoutée.

       
       Fig 4.9 : Ajouté pour le changement de rôle de base de données

   12. Cliquez sur Ajouter.

       
       Fig 4.10 : ajout d'un groupe de modifications de rôle de base de données

       Le groupe de plans sera désormais disponible.

       
       Fig 4.11 : groupe de plans de permutation de bases de données

4. Ajoutez une étape de prévérification définie par l'utilisateur à un plan de récupération après sinistre de permutation. La prévérification définie par l'utilisateur sera exécutée avec les étapes de prévérification intégrées.

   1. Accédez à Groupes de plans, cliquez sur … en face de Prévérifications créées et sélectionnez Ajouter une prévérification définie par l'utilisateur.

      
      Fig 4.12 : ajoutez une prévérification personnalisée pour la permutation de base de données

   2. Entrez un nom d'étape simple mais descriptif. Dans cet exemple, nous allons utiliser DB Switchover precheck from IAD to PHX.
   3. Sélectionnez une région d'instance contenant l'instance sur laquelle cette étape est exécutée. Dans cet exemple, le script sera exécuté sur l'hôte jumphost dans la région 2. Sélectionnez donc Phoenix.
   4. Sélectionnez Exécuter un script local.
   5. Sélectionnez Instance cible, qui est l'hôte de saut script-phx dans la région.
   6. Dans Paramètres de script, entrez le chemin complet du script avec les paramètres. Par exemple : /home/opc/db-prechk-switchover-iad-phx.sh.
   7. Dans Exécuter en tant qu'utilisateur, entrez opc.

   8. Cliquez sur Ajouter une étape.

      
      Fig 4.13 : paramètres permettant d'ajouter une étape de prévérification personnalisée pour le changement de rôle de base de données

   9. Vérifiez l'étape ajoutée.

      
      Fig 4.14 : ajout d'une étape de prévérification personnalisée pour le changement de rôle de base de données

      La personnalisation du plan de permutation est terminée.

      
      Fig 4.15 : Plan de permutation final

5. De même, personnalisez les plans de basculement, de démarrage de l'exploration, utilisez l'instance cible et les scripts appropriés à l'aide des détails tabulaires disponibles dans les prérequis : Utilisation et personnalisation des scripts de gestionnaire de base de données.

6. Les plans Basculement et Démarrer l'exploration sont présentés ci-dessous une fois le groupe de plans défini par l'utilisateur et l'étape de prévérification personnalisée ajoutés.

   
   Fig 4.16 : plan de basculement final

   
   Fig. 4.17 : Plan d'analyse de début final

Tâche 5 : exécuter des prévérifications pour les plans de récupération après sinistre dans la région 2

Avec la permutation, le basculement, les plans de récupération après sinistre de démarrage ont été créés avec succès dans la région de secours 2. Ces plans permettent à OCI Full Stack DR de faire passer les charges de travail de la région 1 à la région 2 ou d'effectuer une analyse DR. La tâche suivante consiste à exécuter les prévérifications pour les plans de récupération après sinistre afin de garantir la préparation et de valider le processus de transition.

Tâche 5.1 : lancer les prévérifications pour le plan de permutation

Exécutez des prévérifications pour le plan de récupération après sinistre de permutation.

1. Assurez-vous que le contexte de région est défini sur la région de secours 2.
2. Assurez-vous que le groupe de protection de récupération après sinistre correct dans la région 2 est sélectionné, il doit s'agir du rôle de secours.
3. Cliquez sur le menu déroulant Actions.
4. Cliquez sur Exécuter les prévérifications.
5. Sélectionnez le plan Basculement de base de données d'IAD vers PHX.
6. Entrez le nom de l'exécution du plan, sinon la génération automatique sera effectuée.

7. Cliquez sur Exécuter les prévérifications.

   
   Fig 5.1 : indique comment exécuter des prévérifications du plan de permutation

8. Vérifiez le statut Succès dans l'onglet Exécutions de plan.

   
   Fig 5.2 : affichage des prévérifications terminées du plan de permutation

Tâche 5.2 : lancer les prévérifications du plan de basculement

Exécutez les prévérifications pour le plan de récupération après sinistre de basculement.

1. Assurez-vous que le contexte de région est défini sur la région de secours 2.
2. Assurez-vous que le groupe de protection de récupération après sinistre correct dans la région 2 est sélectionné, il doit s'agir du rôle de secours.
3. Cliquez sur le menu déroulant Actions.
4. Cliquez sur Exécuter les prévérifications.
5. Sélectionnez le plan Basculement de base de données d'IAD vers PHX.
6. Entrez le nom de l'exécution du plan, sinon la génération automatique sera effectuée.

7. Cliquez sur Exécuter les prévérifications.

   
   Fig 5.3 : indique comment exécuter des prévérifications du plan de basculement

8. Vérifiez le statut Succès dans l'onglet Exécutions de plan.

   
   Fig 5.4 : affichage des prévérifications terminées du plan de basculement

Tâche 5.3 : Commencer les prévérifications pour le plan d'exploration de début

Exécutez les prévérifications pour le plan de récupération après sinistre d'exploration de début.

1. Assurez-vous que le contexte de région est défini sur la région de secours 2.
2. Assurez-vous que le groupe de protection de récupération après sinistre correct dans la région 2 est sélectionné, il doit s'agir du rôle de secours.
3. Cliquez sur le menu déroulant Actions.
4. Cliquez sur Exécuter les prévérifications.
5. Sélectionnez le plan Démarrer l'analyse dans PHX.
6. Entrez le nom de l'exécution du plan, sinon la génération automatique sera effectuée.

7. Cliquez sur Exécuter les prévérifications.

   
   Fig 5.5 : indique comment exécuter des prévérifications du plan d'analyse de début

8. Vérifiez le statut Succès dans l'onglet Exécutions de plan.

   
   Fig 5.6 : affichage des prévérifications terminées du plan de basculement

Tâche 6 : exécuter le plan de permutation de rôles dans la région 2

Exécutez le plan de récupération après sinistre de permutation pour lancer la transition du rôle de base de données Oracle de la région 1 (principale) vers la région 2 (de secours).

1. Assurez-vous que le contexte de région est défini sur la région de secours 2.
2. Assurez-vous que le groupe de protection de récupération après sinistre correct dans la région 2 est sélectionné, il doit s'agir du rôle de secours.
3. Cliquez sur le menu déroulant Actions.

4. Cliquez sur Exécuter le plan.

   
   Fig 6.1 : indique comment exécuter le plan de permutation

5. Sélectionnez le plan Basculement de base de données d'IAD vers PHX.
6. Cette tâche exécute le plan de permutation dans la région 2.
7. Désélectionnez Activer les prévérifications, car les prévérifications ont déjà été exécutées dans la tâche 5. Si vous souhaitez l'exécuter à nouveau, vous pouvez l'activer.
8. Entrez le nom de l'exécution du plan, sinon la génération automatique sera effectuée.

9. Cliquez sur Exécuter le plan.

   
   Fig 6.2 : indique comment exécuter le plan de permutation

10. Accédez à l'onglet Exécutions de plan et sélectionnez l'exécution du plan de permutation.

    
    Fig 6.3 : affichage du plan de permutation en cours

11. Surveillez le plan de permutation jusqu'à ce que la charge globale complète passe de la région 1 à la région 2. L'exécution du plan de permutation s'est terminée avec succès en environ 8 minutes.

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

12. Vous pouvez vérifier le statut du rôle de base de données à l'aide des détails fournis dans la tâche 1.8.

    
    Figure 6.5 : Statut Data Guard après permutation

    Sortie attendue :

    • adghol_site1 doit apparaître en tant que base de données principale.
    • adghol_site0 doit apparaître en tant que base de secours physique.
    • Configuration Status doit apparaître comme Succès.

13. Le rôle du groupe de protection de récupération après sinistre est échangé, la région 2 est affichée en tant que principale et la région 1 en tant que de secours.

    
    Fig 6.6 : modification du rôle de protection de récupération après sinistre après la permutation

Tâche 7 : créer et personnaliser des plans de récupération après sinistre dans la région 1

Avec l'exécution réussie du plan de reprise après sinistre de la région 1 vers la région 2, la région 2 a désormais pris le rôle de base principale, tandis que la région 1 est passée au rôle de base de données de secours.

Suivez la même approche détaillée dans la tâche 4 pour créer et personnaliser les plans de permutation, de basculement et d'exploration de récupération après sinistre au sein du groupe de protection de récupération après sinistre pour la région 1, qui sert désormais de région homologue de secours.

Une fois ces plans créés et mis à jour avec des groupes de plans définis par l'utilisateur et une étape de prévérification personnalisée, ils ressemblent aux images suivantes.

Fig 7.1 : Plans de récupération après sinistre créés dans la région 1

Fig 7.2 : Plan de permutation dans la région 1

Fig 7.3 : Plan de basculement en cas d'incident dans la région 1

Fig 7.4 : Démarrer le plan d'analyse dans la région 1

Si nécessaire, vous pouvez exécuter le plan de permutation pour promouvoir la base de données de la région 1 vers le rôle principal, tandis que la base de données de la région 2 devient la de secours.

De même, vous pouvez exécuter le plan Démarrer l'analyse pour simuler un événement de récupération après sinistre, puis créer et exécuter le plan Arrêter l'analyse pour rétablir l'état d'origine du système.

• Au cours du plan Démarrer l'exploration, la base de données est convertie d'une base de secours physique en une base de secours cliché. Les applications peuvent ainsi accéder temporairement à la base de données de secours et interagir avec elle à des fins de test.

• Au cours du plan d'arrêt de l'exploration, la base de données est reconvertie de base de secours cliché en base de secours physique, ce qui garantit sa resynchronisation avec la base de données principale.

Etapes suivantes

Pour plus d'informations, reportez-vous à la documentation sur OCI Full Stack DR, Oracle Base Database Service et Oracle Data Guard dans la section Liens associés.

Liens connexes

• Documentation Oracle Cloud Infrastructure (OCI) Full Stack Disaster Recovery

• Fonctionnement de la Full Stack Disaster Recovery

• Page du produit OCI Full Stack Disaster Recovery

• Scripts de modification de rôle Oracle DB

• Services OCI Oracle Database Cloud

• Oracle Database Data Guard

• broker Oracle Database Data Guard

• Oracle Live Labs : automatiser la récupération après sinistre sur OCI à l'aide de Full Stack Disaster Recovery

• Rejoindre le canal slack #full-stack-dr

Accusés de réception

• Auteur - Suraj Ramesh (chef de produit principal principal pour OCI Full Stack DR)
• Contributeurs - Santhosh Shankaramanchi (membre consultant du personnel technique pour OCI Full Stack DR)

Ressources de formation supplémentaires

Explorez d'autres ateliers sur le site docs.oracle.com/learn ou accédez à d'autres contenus d'apprentissage gratuits sur le canal Oracle Learning YouTube. En outre, visitez le site education.oracle.com/learning-explorer pour devenir un explorateur Oracle Learning.

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

---

Informations relatives au titre et au copyright

Automate Role Changes for Manually Configured Oracle Data Guard in OCI Database Services Using OCI Full Stack DR and Custom Scripts

G45725-03

Copyright ©2025,

Oracle et/ou ses affiliés.