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 de la reprise après sinistre sur pile complète OCI et de scripts personnalisés

Présentation

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

La reprise après sinistre de pile complète pour OCI 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 RS de pile complète OCI, ce qui permet des opérations de récupération après sinistre coordonnées.

Pour les services gérés de 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 trousses SDK OCI. Cela garantit qu'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 RS.

Toutefois, il existe des scénarios où 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 à l'application;
• Configurations de secours en cascade.
• Utilisation d'anciennes versions de base de données en raison de la compatibilité des applications.

Dans de tels cas, bien que le plan de contrôle des services de base de données OCI ne reconnaisse pas la configuration d'Oracle Data Guard, la récupération après sinistre de pile complète OCI 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 dans des groupes de plans définis par l'utilisateur dans vos plans RS.

Notez que cette solution n'est pas compatible avec les services Oracle Database Cloud où les configurations Data Guard sont gérées au moyen de la console OCI, des trousses SDK ou des API.

Dans ce tutoriel, nous présenterons une approche standardisée pour la gestion des transitions de rôle Oracle Data Guard à l'aide de scripts de programme de traitement de base de données personnalisés pour les services de base de données OCI où Oracle Data Guard a été configuré manuellement.

Note : Cette solution de script personnalisé s'applique aux services de base de données OCI suivants :

• Service de base de données de base Oracle
• Service Oracle Exadata Database sur une infrastructure dédiée
• Service Oracle Exadata Database sur une infrastructure exaflopique
• Service Oracle Exadata Database sur Cloud@Customer

Description de l'architecture

Dans ce tutoriel, nous utiliserons le service 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 de Data Guard personnalisé à 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 pouvez organiser ce déploiement et la reprise après sinistre de pile complète OCI en n'importe quel modèle de compartiment conforme à vos normes de gouvernance des TI. Nous avons choisi d'organiser toutes les ressources OCI pour ce tutoriel dans un seul compartiment.

Objectifs

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

• Tâche 1 : Vérifiez la configuration d'Oracle Data Guard et mettez à jour les marqueurs.
• Tâche 2 : Créez et associez des groupes de protection RS.
• Tâche 3 : Ajoutez des membres aux groupes de protection RS.
• Tâche 4 : Créez et personnalisez les plans RS dans la région 2.
• Tâche 5 : Exécutez des vérifications préalables pour les plans RS de 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 RS dans la région 2.

Conditions requises

Nous utiliserons les ressources suivantes pour commencer avec le tutoriel.

Ressources	Région 1 - Ashburn	Région 2 - Phoenix
Compartiment	application	application
Système de BD	adghol-12345	adghol-12345
Nom de la BD	adghol	adghol
Nom unique de la base de données	adghol-site0	adghol-site1
Rôle de base de données	principal	de secours
MV de calcul	script-iad	script-phx
Seau	IAD	PHX

Note : Terminez tous les préalables requis avant de continuer. Ces étapes jettent les bases d'une configuration de récupération après sinistre de pile complète OCI fluide et réussie.

1. Accès de l'administrateur ou politiques requises pour Oracle Cloud Infrastructure Identity and Access Management (OCI IAM).

   Assurez-vous de disposer des privilèges d'administrateur ou configurez les politiques OCI IAM et les groupes dynamiques nécessaires pour utiliser la reprise après sinistre de pile complète OCI. Dans cette solution, le script du programme de traitement de base de données lance en interne une instance de conteneur OCI. Vous devez donc ajouter des politiques en conséquence.

   Note : Remplacez toutes les occurrences de <compartment_ocid> et <compartment_name> par l'OCID et le nom réels de votre compartiment OCI.

   1. Créer un groupe dynamique : Créez un groupe dynamique avec l'exemple de nom (FullStackDR_Database_DG) et ajoutez les règles de 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éer une politique IAM pour OCI : Créez une politique avec l'exemple de nom (FullStackDR_Database_Group_Policies) et ajoutez les énoncés d'autorisation suivants :

       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, voir Politiques de récupération après sinistre OCI - Documents officiels et Configuration des politiques IAM (blogue Oracle).

2. Provisionner les instances de calcul OCI dans les deux régions : Créez une instance de calcul OCI dans chaque région pour servir d'hôte rapide pour l'hébergement et l'exécution des étapes détaillées de scripts.For, voir Créer une instance OCI. Pour simplifier, nous désignerons cette instance de calcul OCI comme Jumphost dans tutorial.If car vous avez déjà des instances de calcul OCI existantes pouvant fonctionner en tant que Jumphost, vous pouvez ignorer cette étape. Assurez-vous que Jumphost a Oracle Cloud Agent en cours d'exécution et que le plugiciel d'exécution de commande est activé. Pour plus de détails, voir Oracle Cloud Agent.

3. Accès aux commandes d'exécution sur les instances de calcul OCI : Assurez-vous de configurer les préalables d'exécution de commande dans l'hôte de saut, car nous utilisons des groupes de plans définis par l'utilisateur pour l'exécution de scripts pendant les opérations RS. Pour plus d'informations, voir Exécution de commandes dans une instance.

4. Installer l'interface de ligne de commande OCI dans l'hôte de saut dans les deux régions : Selon le système d'exploitation de l'hôte de saut, installez l'interface de ligne de commande OCI dans les deux régions et assurez-vous de pouvoir appeler les commandes de l'interface de ligne de commande OCI. Dans le script, nous utiliserons le principal d'instance. Pour plus d'informations, voir Installation de l'interface de ligne de commande OCI.

5. Configurer des réseaux en nuage virtuels dans les deux régions avec appairage distant de VCN : Créez des réseaux en nuage virtuels dans les régions principale et de secours et configurez l'appairage distant de VCN. Cette opération est requise pour configurer Oracle Data Guard inter-région. Pour plus d'informations, voir Configuration du réseau de la base de données de base OCI.

6. Configuration manuelle d'Oracle Data Guard : Configurez manuellement la configuration d'Oracle Data Guard en fonction des exigences avec Oracle Data Guard Broker. Pour plus d'informations, voir Oracle Data Guard Broker et Oracle Clusterware.

7. Télécharger les scripts du programme de traitement 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 du programme de traitement de base de données Oracle Data Guard à partir du référentiel suivant : Scripts du programme de traitement de base de données Data Guard.

   2. Copiez les scripts dans le répertoire /home/opc/ (ou tout autre chemin privilégié) sur l'hôte de saut dans les deux régions.

   3. Assurez-vous que les fichiers de script ont des autorisations exécutables.

   4. full_stack_dr_non_std_db_handler.py est le script Python chargé de gérer les scripts bash associés au rôle Oracle Data Guard 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 une chambre forte et des clés secrètes OCI : Vous devez créer une chambre forte OCI et stocker les données d'identification de base de données en tant que clés secrètes dans les deux régions.

   1. Créez une chambre forte 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 la chambre forte pour stocker le mot de passe de l'utilisateur SYS pour la base de données.

   Pour plus d'informations, voir Chambres fortes OCI.

9. Vérifications de connectivité à partir du Jumphost : Assurez-vous que le service de base de données OCI, le service de chambre forte OCI 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 la base de données des deux régions Principale et De secours.

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

        # 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
      

      Note : Remplacez <primary_region> et <standby_region> par des identificateurs de région OCI réels.
      Par exemple :

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

      Pour obtenir la liste complète, voir Identificateurs de région OCI.

      Sortie attendue : Chaque commande doit retourner un message similaire à Connected to ....

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

10. Créer des seaux de stockage d'objets : Créez des seaux de stockage d'objets OCI dans les régions principale et de secours pour stocker les journaux générés par la récupération après sinistre de pile complète OCI lors des opérations de récupération, comme expliqué ici : Préparation de l'emplacement des journaux pour les journaux d'opérations.

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

    
    Fig B : Utilisation du script du programme de traitement de base de données

    Les options --db_operation prises en charge sont les suivantes :

    • PERMUTATION
    • SWITCHOVER_PRECHECK
    • BASCULER
    • FAILOVER_PRECHECK
    • CONVERT_PHYSICAL_TO_SNAPSHOT_STANDBY
    • CONVERT_PHYSICAL_TO_SNAPSHOT_STANDBY_PRECHECK
    • REVERT_SNAPSHOT_TO_PHYSICAL_STANDBY_PRECHECK
    • REVERT_SNAPSHOT_TO_PHYSICAL_STANDBY

    La récupération après sinistre de pile complète OCI s'attend à ce que tous les paramètres requis soient transmis lors de l'exécution du script du programme de traitement 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 la vérification 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"
    

    Note : Stockez ce script d'encapsuleur au même emplacement que vos scripts de programme de traitement 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 RS dans lequel 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 RS	Instance cible	Nom du script	Commentaire
    Switchover	script-phx	db-prechk-switchover-iad-phx.sh	Préchèque la permutation de base de données d'IAD à PHX
    Switchover	script-phx	db-switchover-iad-phx.sh	Basculement de base de données de IAD vers PHX
    Failover	script-phx	db-prechk-failover-iad-phx.sh	Préchèque le basculement de base de données d'IAD vers PHX
    Failover	script-phx	db-failover-iad-phx.sh	Basculement de base de données de IAD vers PHX
    Start drill	script-phx	db-prechk-startdrill-phx.sh	Avant de lancer le forage RS dans PHX
    Start drill	script-phx	db-startdrill-phx.sh	Démarrer le forage RS dans PHX
    Stop drill	script-phx	db-prechk-stopdrill-phx.sh	Précher l'arrêt du forage RS dans PHX
    Stop drill	script-phx	db-stopdrill-phx.sh	Arrêter le forage RS dans PHX

    Mappage de script de plan RS dans lequel 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 RS	Instance cible	Nom du script	Commentaire
    Switchover	script-iad	db-prechk-switchover-phx-iad.sh	Préchèque la permutation de base de données de PHX à IAD
    Switchover	script-iad	db-switchover-phx-iad.sh	Basculement de base de données de PHX vers IAD
    Failover	script-iad	db-prechk-failover-phx-iad.sh	Préchèque le basculement de base de données de PHX vers IAD
    Failover	script-iad	db-failover-phx-iad.sh	Basculement de base de données de PHX vers IAD
    Start drill	script-iad	db-prechk-startdrill-iad.sh	Avant de lancer le forage RS dans IAD
    Start drill	script-iad	db-startdrill-iad.sh	Démarrer le forage RS dans IAD
    Stop drill	script-iad	db-prechk-stopdrill-iad.sh	Précher l'arrêt du forage RS dans IAD
    Stop drill	script-iad	db-stopdrill-iad.sh	Arrêter le forage RS dans IAD

Note : Pour plus de clarté et de facilité d'utilisation, nous avons créé plusieurs scripts d'encapsuleur bash adaptés à des types de plan RS et à des régions 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 besoins et de votre environnement.

Tâche 1 : Vérifier la configuration d'Oracle Data Guard et mettre à jour le marqueur

Dans cette tâche, nous vérifierons la configuration manuelle d'Oracle Data Guard à l'aide d'Oracle Base Database Service. Nous allons créer un *marqueur** sur la base de données pour indiquer une configuration Oracle Data Guard non standard. Cela permet à la récupération après sinistre de pile complète OCI de créer un plan RS sans avoir recours à des groupes de plans intégrés.

1. Connectez-vous à la console OCI et naviguez jusqu'à Oracle Database et cliquez sur Oracle Base Database Service.

2. Assurez-vous que le contexte de région OCI est réglé à 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 dans la région 1

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

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

5. Vérifiez que le statut Data Guard est Non activé. Cela 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. Naviguez jusqu'à l'onglet Marqueurs et créez les marqueurs à structure libre. Vous devez remplacer la valeur de Peer DB OCID en fonction de votre configuration. Dans cet exemple, vous devez ajouter l'OCID de la base de données de la région Phoenix.

   Clé d'étiquette	Valeur
   FsdrNonStandardDataGuardPeerDatabaseId	Peer DB OCID
   FsdrNonStandardDataGuardFlag	True

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

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

   Note : Il s'agit d'une configuration non RAC. Vous verrez donc un noeud de base de données unique. S'il s'agissait d'une configuration d'Oracle Real Application Clusters, vous verriez deux noeuds.

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

   dgmgrl
   show configuration
   

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

   Résultat attendu :

   • adghol_site0 doit apparaître en tant que base de données principale.
   • adghol_site1 doit apparaître en tant que base de données de secours physique.
   • Configuration Status doit apparaître Réussite.

   S'il y a des erreurs et que les rôles de base de données ne sont pas conformes aux attentes, vous devez corriger les erreurs à l'aide de la documentation d'Oracle Data Guard.

9. Connectez-vous à la console OCI et naviguez jusqu'à Oracle Database et cliquez sur Oracle Base Database Service.

10. Assurez-vous que le contexte de région OCI est réglé à Région 2 (Phoenix).

11. Sélectionnez le système de base de données, dans notre exemple, adghol1-12345

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

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

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

13. Vérifiez que le statut Data Guard est Non activé. Cela 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. Naviguez jusqu'à l'onglet Marqueurs et créez les marqueurs à structure libre. Vous devez remplacer la valeur de Peer DB OCID en fonction de votre configuration. Dans cet exemple, vous devez ajouter l'OCID de la base de données de la région Ashburn.

    Clé d'étiquette	Valeur
    FsdrNonStandardDataGuardPeerDatabaseId	Peer DB OCID
    FsdrNonStandardDataGuardFlag	True

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

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

    • Assurez-vous d'être 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 RS

Créez des groupes de protection RS dans les régions 1 et 2 si les groupes de protection pour cette pile d'applications n'existent pas encore.

Tâche 2.1 : Créer un groupe de protection dans la région 1

1. Allez à la console OCI et naviguez jusqu'à Groupes de protection RS, comme illustré dans la figure 2.1.

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

   
   Figure 2.1 : Naviguez jusqu'aux groupes de protection RS

2. Créez un groupe de protection RS de base dans la région 1, comme illustré à la figure 2.2. Le pair, le rôle et les membres seront affectés aux étapes ultérieures.

   1. Sélectionnez le compartiment dans lequel vous souhaitez créer le groupe de protection RS.
   2. Cliquez sur Créer un groupe de protection RS.
   3. Utilisez un nom significatif pour le groupe de protection RS.
   4. Sélectionnez 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

1. Allez à la console OCI, naviguez jusqu'à Groupes de protection RS, comme illustré à la figure 2.3.

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

   
   Figure 2.3 : Naviguez jusqu'aux groupes de protection RS

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

   1. Sélectionnez le compartiment dans lequel vous souhaitez créer le groupe de protection RS.
   2. Cliquez sur Créer un groupe de protection RS.
   3. Utilisez un nom significatif pour la passerelle DRPG.
   4. Sélectionnez 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 la région 1 et la région 2

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

1. 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 (Ashburn).
   2. Cliquez sur le menu déroulant Actions et cliquez sur Associer pour lancer le processus.

   
   Fig 2.5 : Démarrer l'association DRPG

2. Entrez les informations suivantes .

   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 d'appairage : Sélectionnez la région 2 (Phoenix), où l'autre groupe de protection RS a été créé.
   3. Groupe de protection RS pair : Sélectionnez le groupe de protection RS pair qui a été créé.
   4. Cliquez sur associer.

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

La récupération après sinistre de pile complète pour OCI affiche une valeur similaire à celle indiquée dans l'image suivante, une fois l'association terminée.

• La passerelle DRPG principale courante est Ashburn (région 1).
• Le DRPG pair de secours courant est Phoenix (région 2).

Fig 2.7 : Affichage de la relation d'appairage du point de vue DRPG individuel

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

• La passerelle DRPG principale courante est Ashburn (région 1).
• Le DRPG pair de secours courant est Phoenix (région 2).

Fig 2.8 : Affichage de la relation d'appairage dans la perspective DRPG globale

Tâche 3 : Ajouter des membres aux groupes de protection RS

Dans cette tâche, nous ajouterons les ressources OCI suivantes au groupe de protection RS principal dans la région 1.

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

Tâche 3.1 : Ajouter des membres au groupe de protection RS dans la région 1

1. Sélectionnez le groupe de protection RS dans la région 1, comme illustré 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 RS dans la région 1.
   3. Naviguez jusqu'à l'onglet Membres.
   4. Cliquez sur Gérer les membres.

   
   Fig 3.1 : Comment commencer à ajouter des membres au groupe de protection RS dans la région 1

2. Ajoutez une instance de calcul pour les scripts du programme de traitement de base de données.

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

   
   Fig 3.2 : Ajout d'une instance de calcul à la passerelle DRPG dans la région 1

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

   
   Fig 3.2 : Instance de calcul ajoutée à la passerelle 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 de données de base,ExaDB-D,ExaCC,ExaXS) en tant que membre Type de ressource.
   3. Sélectionnez Base de données de base Oracle comme type de base de données.
   4. Sélectionner un système de base de données.
   5. Sélectionner un répertoire de base.
   6. Sélectionnez Base de données.
   7. Sélectionnez Clé secrète du mot de passe de la base de données
   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 à la passerelle DRPG dans la région 1

   
   Fig 3.5 : Publier des membres dans la passerelle DRPG de la région 1

   Au bout de quelques minutes, les deux membres devraient être disponibles sous les membres.

   
   Fig 3.6 : Membres ajoutés à la passerelle DRPG de la région 1

Tâche 3.2 : Ajouter des membres au groupe de protection RS dans la région 2

1. Sélectionnez le groupe de protection RS dans la région 2, comme illustré 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 RS dans la région 2.
   3. Naviguez jusqu'à l'onglet Membres.
   4. Cliquez sur Gérer les membres.

   
   Fig 3.7 : Comment commencer à ajouter des membres au groupe de protection RS dans la région 2

2. Ajoutez une instance de calcul pour les scripts du programme de traitement de base de données.

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

   
   Fig 3.8 : Ajout d'une instance de calcul à la passerelle DRPG dans la région 2

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

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

3. Ajoutez 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 de données de base,ExaDB-D,ExaCC,ExaXS) en tant que membre Type de ressource.
   3. Sélectionnez Base de données de base Oracle comme type de base de données.
   4. Sélectionner un système de base de données.
   5. Sélectionner un répertoire de base.
   6. Sélectionnez Base de données.
   7. Sélectionnez Clé secrète du mot de passe de la base de données
   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 à la passerelle DRPG dans la région 2

   
   Fig 3.12 : Publier des membres dans la passerelle DRPG de la région 2

   Au bout de quelques minutes, les deux membres devraient être disponibles sous les membres.

   
   Fig 3.13 : Membres ajoutés à la passerelle DRPG dans la région 2

Tâche 4 : Créer et personnaliser les plans RS dans la région 2

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

Ces plans sont conçus pour assurer une transition transparente de la charge de travail de la région principale (Région 1) vers la région de secours (Région 2).

• La récupération après sinistre de pile complète OCI préalimente ces plans avec des étapes intégrées basées sur les ressources membres ajoutées précédemment.
• Toutefois, dans ce tutoriel, comme Oracle Data Guard est configuré manuellement (en dehors du plan de contrôle de la base de données), aucun groupe de plans intégré ne sera disponible pour les transitions de rôle de base de données Oracle.
• Par conséquent, nous allons :
  • Personnalisez les plans RS 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 au cours de chaque type de plan (switchover, failover, drill).

Les plans RS sont toujours créés dans le groupe de protection qui détient le rôle de secours.

Étant donné que la région 2 (Phoenix) est actuellement la base de secours, nous y créerons tous les plans RS initiaux.

Tâche 4.1 : Créer des plans RS

1. Créer des plans RS 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 la passerelle DRPG de secours dans la région 2.
   3. Naviguez jusqu'à l'onglet Plans.
   4. Cliquez sur Créer un plan.

   
   Fig 4.1 : Comment commencer à créer des plans RS 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 devrait être aussi court que possible, mais facile à comprendre en un coup d'œil pour aider à réduire la confusion et l'erreur humaine pendant une crise.
   2. Sélectionnez Type de plan comme Permutation (planifiée).

   
   Fig 4.2 : Paramètres nécessaires pour créer un plan de permutation RS

3. Créez un plan de basculement.

   Suivez le même processus pour créer un plan de basculement de base, comme illustré dans l'illustration 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 pour créer un plan de basculement RS

4. Créer un plan de forage de début.

   Suivez le même processus pour créer un plan de basculement de base, comme illustré dans l'illustration suivante.

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

   
   Fig 4.4 : Paramètres nécessaires pour créer un plan de forage de démarrage RS

   Le groupe de protection RS de secours dans la région 2 doit maintenant avoir les trois plans RS indiqués 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 faire passer les charges de travail de la région 2 à la région 1 dans une tâche ultérieure.

   
   Fig 4.5 : Affichage des trois plans RS qui doivent exister dans la région 2 avant de poursuivre

Note : La récupération après sinistre de pile complète OCI vous permet de créer un plan de forage d'arrêt seulement une fois que le plan de forage de début a été exécuté avec succès et que le groupe de protection RS est à l'état Inactif (Forage en cours).

Tâche 4.2 : Personnaliser les plans RS avec des groupes de plans définis par l'utilisateur

Les plans RS créés dans la tâche 4.1 ne généreront pas de groupes de plans intégrés pour les transitions de rôle de base de données Oracle car la configuration d'Oracle Data Guard a été effectuée manuellement.

Au cours de cette tâche, vous devrez :

• Voyez comment ajouter des groupes de plans RS personnalisés définis par l'utilisateur.
• Définissez les étapes nécessaires à la gestion des transitions de rôle Oracle Data Guard.

Cela garantit que vos plans de reprise après sinistre peuvent gérer entièrement les scénarios de basculement, de permutation et de forage impliquant un environnement Data Guard configuré manuellement.

1. Naviguez jusqu'au plan de permutation créé dans la tâche 4.1 et sélectionnez Groupes de régimes.

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

2. Commencez par ajouter des groupes de plans RS définis par l'utilisateur personnalisés pour adapter le flux de travail 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 vont appeler les scripts nécessaires à partir de l'hôte script-iad dans la région 1.

3. Ajoutez un groupe de plans défini par l'utilisateur à la 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 utiliserons DB Switchover.

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

      
      Fig 4.7 : Paramètres permettant de créer un groupe de plans pour effectuer une modification 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 utiliserons DB Switchover from IAD to PHX.
   5. Sélectionnez la région d'instance qui contient l'instance sur laquelle cette étape sera exécutée. Dans cet exemple, le script sera exécuté sur l'hôte de saut dans la région 2, sélectionnez Phoenix.
   6. Sélectionnez Exécuter le script local.
   7. Sélectionnez Instance cible, qui est l'hôte 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 la modification du rôle de base de données

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

       
       Fig 4.9 : Ajouté pour la modification du 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 disponible maintenant.

       
       Fig 4.11 : Groupe de plans de permutation de base de données

4. Ajouter une étape de vérification préalable définie par l'utilisateur à un plan RS de permutation. La vérification préalable définie par l'utilisateur sera exécutée avec les étapes de vérification préalable intégrées.

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

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

   2. Entrez un nom d'étape simple mais descriptif. Dans cet exemple, nous utiliserons DB Switchover precheck from IAD to PHX.
   3. Sélectionnez la région d'instance qui contient l'instance sur laquelle cette étape sera exécutée. Dans cet exemple, le script sera exécuté sur l'hôte de saut dans la région 2, sélectionnez Phoenix.
   4. Sélectionnez Exécuter le 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 vérification préalable personnalisée pour la modification du rôle de base de données

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

      
      Fig 4.14 : Étape de vérification préalable personnalisée ajoutée pour la modification du rôle de base de données

      La personnalisation du plan de permutation est terminée.

      
      Fig 4.15 : Plan de permutation finale

5. De même, personnalisez les plans de basculement, de démarrage du forage, utilisez les plans Instance cible et Scripts appropriés à l'aide des détails tabulaires disponibles dans les préalables : Utilisation et personnalisation des scripts du programme de traitement de base de données.

6. Les plans Basculement et Démarrer le forage apparaîtront comme ci-dessous une fois que le groupe de plans défini par l'utilisateur et l'étape de vérification préalable personnalisée seront ajoutés.

   
   Fig 4.16 : Plan de basculement final

   
   Fig 4.17 : Plan de forage du début final

Tâche 5 : Exécuter des vérifications préalables pour les plans RS dans la région 2

Avec la permutation et le basculement, les plans RS de démarrage de forage ont été créés avec succès dans la région de secours 2. Ces plans permettent à la reprise après sinistre de pile complète OCI de faire la transition des charges de travail de la région 1 vers la région 2 ou d'effectuer un forage de reprise après sinistre. La tâche suivante consiste à exécuter les vérifications préalables pour les plans de reprise après sinistre afin d'assurer la préparation et de valider le processus de transition.

Tâche 5.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.

1. Assurez-vous que le contexte de région est réglé à Région de secours 2.
2. Assurez-vous que le groupe de protection RS approprié dans la région 2 est sélectionné. Il doit s'agir du rôle de secours.
3. Cliquez sur le menu déroulant Actions.
4. Cliquez sur Exécuter les vérifications préalables.
5. Sélectionnez le plan Basculement de base de données de IAD vers PHX.
6. Entrez le nom de l'exécution du plan, sinon il sera généré automatiquement.

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

   
   Fig 5.1 : Affichage de l'exécution des vérifications préalables du plan de permutation

8. Vérifiez le statut Réussite dans l'onglet Exécutions de plan.

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

Tâche 5.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.

1. Assurez-vous que le contexte de région est réglé à Région de secours 2.
2. Assurez-vous que le groupe de protection RS approprié dans la région 2 est sélectionné. Il doit s'agir du rôle de secours.
3. Cliquez sur le menu déroulant Actions.
4. Cliquez sur Exécuter les vérifications préalables.
5. Sélectionnez le plan de basculement de base de données d'IAD vers PHX.
6. Entrez le nom de l'exécution du plan, sinon il sera généré automatiquement.

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

   
   Fig 5.3 : Affichage de l'exécution des vérifications préalables du plan de basculement

8. Vérifiez le statut Réussite dans l'onglet Exécutions de plan.

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

Tâche 5.3 : Commencer les vérifications préalables pour le plan de forage Démarrer

Exécutez les vérifications préalables pour démarrer le plan RS de forage.

1. Assurez-vous que le contexte de région est réglé à Région de secours 2.
2. Assurez-vous que le groupe de protection RS approprié dans la région 2 est sélectionné. Il doit s'agir du rôle de secours.
3. Cliquez sur le menu déroulant Actions.
4. Cliquez sur Exécuter les vérifications préalables.
5. Sélectionnez le plan Démarrer le forage dans PHX.
6. Entrez le nom de l'exécution du plan, sinon il sera généré automatiquement.

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

   
   Fig 5.5 : Affichage de l'exécution des vérifications préalables du plan de forage de début

8. Vérifiez le statut Réussite dans l'onglet Exécutions de plan.

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

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

Exécuter le plan RS 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 réglé à Région de secours 2.
2. Assurez-vous que le groupe de protection RS approprié dans la région 2 est sélectionné. Il doit s'agir du rôle de secours.
3. Cliquez sur le menu déroulant Actions.

4. Cliquez sur Exécuter le plan.

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

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

9. Cliquez sur Exécuter le plan.

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

10. Naviguez jusqu'à 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 de travail complète soit entièrement passée 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 de Data Guard après la permutation

    Résultat attendu :

    • adghol_site1 doit apparaître en tant que base de données principale.
    • adghol_site0 doit apparaître en tant que base de données de secours physique.
    • Configuration Status doit apparaître Réussite.

13. Le rôle dans le groupe de protection RS sera échangé, la région 2 s'affichera comme Principal et la région 1 s'affichera comme De secours.

    
    Fig 6.6 : Modification du rôle de protection RS après la permutation

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

Avec l'exécution réussie du plan RS de permutation de la région 1 à la région 2, la région 2 a désormais assumé le rôle de principale, tandis que la région 1 est passée au rôle de secours.

Suivez la même approche décrite dans la tâche 4 pour créer et personnaliser les plans de permutation, de basculement et de forage RS au sein du groupe de protection RS pour la région 1, qui sert désormais de région pair de secours.

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

Fig 7.1 : Plans RS créés dans la région 1

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

Fig 7.3 : Plan de basculement dans la région 1

Fig 7.4 : Démarrer le plan de forage dans la région 1

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

De même, vous pouvez exécuter le plan de démarrage pour simuler un événement de récupération après sinistre, puis créer et exécuter le plan d'arrêt du forage pour rétablir l'état initial du système.

• Lors du plan Démarrer le forage, la base de données est convertie d'une base de secours physique en une base de secours instantanée. Cela permet aux applications d'accéder temporairement à la base de données de secours et d'interagir avec elle à des fins de test.

• Pendant le plan Arrêter le forage, la base de données est reconvertie de Base de secours instantanée à Base de secours physique, en s'assurant qu'elle est resynchronisée avec la base de données principale.

Étapes suivantes

Pour plus d'informations, consultez la documentation sur la récupération après sinistre de pile complète OCI, le service Oracle Base Database Service, Oracle Data Guard dans la section Liens connexes.

Liens connexes

• Documentation sur le service de récupération après sinistre de pile complète pour Oracle Cloud Infrastructure (OCI)

• Comment fonctionne la récupération après sinistre de pile complète

• Page du produit de récupération après sinistre de pile complète OCI

• Scripts de modification de rôle Oracle DB

• Services Oracle Database Cloud pour OCI

• Oracle Database Data Guard

• Courtier Data Guard d'Oracle Database

• Oracle Live Labs : Automatiser la récupération après sinistre sur OCI à l'aide de la récupération après sinistre de pile complète

• Joindre le canal de marge #full-stack-dr

Remerciements

• Auteur - Suraj Ramesh (Gestionnaire principal de produit pour la reprise après sinistre de pile complète pour OCI)
• Contributifs - Santhosh Shankaramanchi (membre du personnel technique chargé de la reprise après sinistre de pile complète pour OCI)

Ressources d'apprentissage supplémentaires

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

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

---

Titre et informations sur les droits d'auteur

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

G45724-03

Copyright ©2025,

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