Automatización de los cambios de roles de base de datos para Oracle Data Guard configurado manualmente en los servicios de base de datos de OCI mediante OCI Full Stack DR y scripts personalizados

Introducción

Oracle Cloud Infrastructure Full Stack Disaster Recovery (OCI Full Stack DR) organiza la transición de recursos informáticos, bases de datos y aplicaciones entre las regiones de Oracle Cloud Infrastructure (OCI) de todo el mundo con un solo clic. Los clientes pueden automatizar los pasos necesarios para recuperar uno o más sistemas de negocio sin rediseñar ni volver a diseñar la infraestructura, las bases de datos o las aplicaciones existentes y sin necesidad de servidores especializados de gestión o conversión.

OCI Full Stack DR ofrece soporte totalmente integrado para varios servicios de Oracle Database en OCI. Estas bases de datos se pueden agregar como miembros de un grupo de protección de recuperación ante desastres de pila completa de OCI, lo que permite operaciones coordinadas de recuperación ante desastres.

Para los servicios gestionados de bases de datos Oracle en OCI, se recomienda configurar Oracle Data Guard mediante la consola de OCI, la interfaz de línea de comandos de Oracle Cloud Infrastructure (CLI de OCI) o los SDK de OCI. Al hacerlo, se garantiza que OCI Full Stack DR pueda detectar automáticamente la configuración de Data Guard y generar grupos de planes integrados para las transiciones de roles como parte de su plan de DR.

Sin embargo, hay escenarios en los que la configuración manual de Oracle Data Guard (fuera de las interfaces nativas de OCI) es necesaria debido a requisitos técnicos u operativos específicos, como:

• Restricciones específicas de la aplicación.
• Configuraciones en espera en cascada.
• Uso de versiones de bases de datos antiguas debido a la compatibilidad de aplicaciones.

En estos casos, aunque el plano de control de los servicios de OCI Database puede no reconocer la configuración de Oracle Data Guard, OCI Full Stack DR sigue ofreciendo flexibilidad. Puede manejar transiciones de roles mediante la creación de scripts personalizados y su integración en grupos de planes definidos por el usuario dentro de sus planes de DR.

Tenga en cuenta que esta solución no es compatible con los servicios de Oracle Database Cloud en los que las configuraciones de Data Guard se gestionan a través de la consola de OCI, los SDK o las API.

En este tutorial, mostraremos un enfoque estandarizado para gestionar las transiciones de roles de Oracle Data Guard mediante scripts de manejador de bases de datos personalizados para servicios de base de datos de OCI en los que Oracle Data Guard se ha configurado manualmente.

Nota: Esta solución de script personalizado se aplica a los siguientes servicios de OCI Database:

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

Descripción de la arquitectura

En este tutorial, utilizaremos Oracle Base Database Service con dos sistemas de base de datos desplegados en dos regiones de OCI, donde Oracle Data Guard se ha configurado manualmente.

Figura A: configuración personalizada de Data Guard mediante Oracle Base Database Service

Definiciones y Asunciones a lo largo del Tutorial

• Regiones:

  • Región 1 (Ashburn): Ashburn servirá, inicialmente, como región principal.

  • Región 2 (Phoenix): Phoenix funcionará inicialmente como región en espera.

• Compartimentos: puede organizar este despliegue y OCI Full Stack DR en cualquier esquema de compartimentos que funcione dentro de sus estándares para la gobernanza de TI. Hemos decidido organizar todos los recursos de OCI para este tutorial en un único compartimento.

Objetivos

En este tutorial se tratarán las siguientes tareas:

• Tarea 1: verificar la configuración de Oracle Data Guard y actualizar las etiquetas.
• Tarea 2: crear y asociar grupos de protección de DR.
• Tarea 3: agregar miembros a los grupos de protección de DR.
• Tarea 4: crear y personalizar los planes de DR en la región 2.
• Tarea 5: ejecutar comprobaciones previas para los planes de DR en la región 2.
• Tarea 6: ejecutar el plan de switchover en la región 2.
• Tarea 7: crear y personalizar los planes de DR en la región 2.

Requisitos

Utilizaremos los siguientes recursos para comenzar con el tutorial.

Recursos	Región 1: Ashburn	Región 2: Phoenix
Compartimiento	Aplicación	Aplicación
Sistema de base de datos	adghol-12345	adghol-12345
Nombre de base de datos	adghol	adghol
Nombre único de la base de datos	adghol-site0	adghol-site1
Rol de base de datos	primario	standby
VM de Compute	ID de script	script-phx
Cubo	IAD	PHX

Nota: Complete todos los requisitos previos necesarios antes de continuar. Estos pasos sientan las bases para una configuración de recuperación ante desastres completa de OCI sin problemas y exitosa.

1. Acceso de administrador o políticas de Oracle Cloud Infrastructure Identity and Access Management (OCI IAM) necesarias.

   Asegúrese de tener privilegios de administrador o configure las políticas y los grupos dinámicos de OCI IAM necesarios para utilizar OCI Full Stack DR. En esta solución, el script del manejador de bases de datos inicia internamente una instancia de contenedor de OCI, por lo que debe agregar políticas según corresponda.

   Nota: Sustituya todas las incidencias de <compartment_ocid> y <compartment_name> por el OCID y el nombre reales del compartimento de OCI.

   1. Crear un grupo dinámico: cree un grupo dinámico con el nombre de ejemplo (FullStackDR_Database_DG) y agregue las siguientes reglas de coincidencia:

       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. Crear una política de OCI IAM: cree una política con el nombre de ejemplo (FullStackDR_Database_Group_Policies) y agregue las siguientes sentencias allow:

       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>
      

   Para obtener más información, consulte Políticas de recuperación ante desastres de OCI – Documentos oficiales y Configuración de políticas de IAM (blog de Oracle).

2. Aprovisionamiento de instancias de OCI Compute en ambas regiones: cree una instancia de OCI Compute en cada región para que sirva como Jumphost para alojar y ejecutar los pasos detallados de scripts.For. Consulte Creación de instancia de OCI. Para simplificarlo, haremos referencia a esta instancia de OCI Compute como Jumphost en tutorial.If en las que ya tiene instancias de OCI Compute existentes que pueden funcionar como Jumphost. Puede omitir este paso. Asegúrese de que Jumphost tiene Oracle Cloud Agent en ejecución y de que el plugin de comandos de ejecución está activado. Para obtener más información, consulte Oracle Cloud Agent.

3. Acceso a comandos de ejecución en instancias informáticas de OCI: asegúrese de configurar los requisitos de comandos de ejecución en el elemento jumphost, ya que estamos utilizando grupos de planes definidos por el usuario para ejecutar scripts durante las operaciones de DR. Para obtener más información, consulte Ejecución de comandos en una instancia.

4. Instale la CLI de OCI en el elemento jumphost en ambas regiones: según el sistema operativo del elemento jumphost, instale la CLI de OCI en ambas regiones y asegúrese de que puede llamar a los comandos de la CLI de OCI. En el script, utilizaremos el principal de instancia. Para obtener más información, consulte Instalación de la CLI de OCI.

5. Set Up VCNs in both Regions with Remote VCN Peering: Create VCNs in both the primary and standby regions and setup remote VCN peering. Esto es necesario para configurar Oracle Data Guard entre regiones. Para obtener más información, consulte Configuración de red de base de datos base de datos OCI.

6. Configuración manual de Oracle Data Guard: configure manualmente la configuración de Oracle Data Guard en función de los requisitos con Oracle Data Guard Broker. Para obtener más información, consulte Oracle Data Guard Broker y Oracle Clusterware.

7. Descargue los scripts del manejador de bases de datos en el elemento Jumphost: los scripts se deben descargar y mantener en el elemento jumphost en ambas regiones.

   1. Descargue los scripts del manejador de base de datos de Oracle Data Guard del siguiente repositorio: scripts del manejador de base de datos de Data Guard.

   2. Copie los archivos de comandos en el directorio /home/opc/ (o cualquier otra ruta preferida) en el elemento jumphost en ambas regiones.

   3. Asegúrese de que los archivos de script tengan permisos ejecutables.

   4. full_stack_dr_non_std_db_handler.py es el script de Python responsable de manejar los scripts bash asociados al rol de Oracle Data Guard transitions.The que se proporcionan como plantillas y se pueden modificar para que se ajusten a sus requisitos específicos. No modifique el script de cambio de rol de Python en sí.

8. Crear OCI Vault y secretos: debe crear un OCI Vault y almacenar las credenciales de base de datos como secretos en ambas regiones.

   1. Cree un OCI Vault en cada región mediante la consola o la CLI de OCI.
   2. Cree un secreto en el almacén para almacenar la contraseña de usuario SYS para la base de datos.

   Para obtener más información, consulte OCI Vaults.

9. Comprobaciones de conectividad desde Jumphost: asegúrese de que el servicio OCI Database, el servicio OCI Vault y el servicio de instancia de contenedor OCI estén accesibles desde la instancia informática. Esto es necesario porque los scripts de DR de pila completa de OCI realizan una introspección para recuperar los detalles de la base de datos de las regiones principal y en espera.

   1. La conectividad debe funcionar desde el puente. Ejecute los siguientes comandos desde el 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
      

      Nota: Sustituya <primary_region> y <standby_region> por identificadores de región de OCI reales.
      Por ejemplo:

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

      Para obtener una lista completa, consulte Identificadores de región de OCI.

      Salida esperada: cada comando debe devolver un mensaje similar a Connected to ....

      Si falla alguna conexión, compruebe las listas de seguridad, las tablas de rutas y la configuración del gateway de servicio de la VCN/subredes del elemento jumphost.

10. Crear cubos de Object Storage: cree cubos de OCI Object Storage en las regiones principal y en espera para almacenar los logs generados por OCI Full Stack DR durante las operaciones de recuperación, como se explica aquí: Preparación de la ubicación de log para los logs de operaciones.

11. Uso y personalización de scripts del manejador de bases de datos: puede descargar los scripts del manejador de bases de datos del repositorio GitHub mencionado. A continuación se muestra el uso del script del manejador de bases de datos y los parámetros necesarios.

    
    Figura B: uso del script del manejador de base de datos

    Las opciones --db_operation admitidas son:

    • SWITCHOVER
    • SWITCHOVER_PRECHECK
    • FAILOVER
    • 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 espera que se transfieran todos los parámetros necesarios al ejecutar el script del manejador de bases de datos. Para una mejor usabilidad y repetibilidad, se recomienda crear un script bash de envoltorio que:

    • Proporciona los parámetros necesarios.
    • Activa el registro para la auditoría y la resolución de problemas.

    Ejemplo de ejemplo: script de switchover de base de datos (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"
    

    Nota: Almacene este script de envoltorio en la misma ubicación que los scripts del manejador de base de datos y asegúrese de que sea ejecutable. Los OCID se anonimizan en el script.

    chmod +x db-switchover-wrapper.sh
    

    Asignación de script de plan de DR donde la base de datos que se ejecuta en la región 1 (Ashburn) es principal y la región 2 (Phoenix) es en espera

    Tipo de plan de DR	Instancia de Destino	Nombre de script	Comentario
    Switchover	script-phx	db-prechk-switchover-iad-phx.sh	Switchover de Base de Datos Previo de IAD a PHX
    Switchover	script-phx	db-switchover-iad-phx.sh	Switchover de Base de Datos de IAD a PHX
    Failover	script-phx	db-prechk-failover-iad-phx.sh	Comprobación previa de failover de base de datos de IAD a PHX
    Failover	script-phx	db-failover-iad-phx.sh	Failover de Base de Datos de IAD a PHX
    Start drill	script-phx	db-prechk-startdrill-phx.sh	Comprobación previa de inicio de detalle de DR en PHX
    Start drill	script-phx	db-startdrill-phx.sh	Iniciar detalle de DR en PHX
    Stop drill	script-phx	db-prechk-stopdrill-phx.sh	Detener detalle de DR en PHX
    Stop drill	script-phx	db-stopdrill-phx.sh	Detener detalle de DR en PHX

    Asignación de script de plan de DR donde la base de datos que se ejecuta en la región 2 (Phoenix) es principal y la región 2 (Ashburn) es en espera

    Tipo de plan de DR	Instancia de Destino	Nombre de script	Comentario
    Switchover	script-iad	db-prechk-switchover-phx-iad.sh	Switchover de Base de Datos Previo de PHX a IAD
    Switchover	script-iad	db-switchover-phx-iad.sh	Switchover de Base de Datos de PHX a IAD
    Failover	script-iad	db-prechk-failover-phx-iad.sh	Comprobación previa de failover de base de datos de PHX a IAD
    Failover	script-iad	db-failover-phx-iad.sh	Failover de Base de Datos de PHX a IAD
    Start drill	script-iad	db-prechk-startdrill-iad.sh	Comprobación previa de inicio de detalle de DR en IAD
    Start drill	script-iad	db-startdrill-iad.sh	Iniciar detalle de DR en IAD
    Stop drill	script-iad	db-prechk-stopdrill-iad.sh	Detención previa de detalle de DR en IAD
    Stop drill	script-iad	db-stopdrill-iad.sh	Detener detalle de DR en IAD

Nota: Para una mayor claridad y facilidad de uso, hemos creado varios scripts de envoltorio bash adaptados a regiones y tipos de planes de DR específicos. Estos scripts utilizan un script de Python compartido para transiciones de roles de base de datos, que puede personalizar para que se adapte a sus propios requisitos y entorno.

Tarea 1: Verificación de la Configuración de Oracle Data Guard y Actualización de la Etiqueta

En esta tarea, verificaremos la configuración manual de Oracle Data Guard mediante Oracle Base Database Service. Crearemos una *etiqueta** en la base de datos para indicar una configuración de Oracle Data Guard no estándar. Esto permite a OCI Full Stack DR crear un plan de recuperación ante desastres sin depender de ningún grupo de planes incorporado.

1. Conéctese a la consola de OCI, vaya a Oracle Database y haga clic en Oracle Base Database Service.

2. Asegúrese de que el contexto de la región de OCI esté definido en Region 1 (Ashburn).

3. Seleccione el sistema de base de datos; en nuestro ejemplo, es adghol0-12345.

   
   Figura 1.1: sistema de base de datos en la región 1

4. Vaya al separador Bases de datos y seleccione la base de datos adghol.

   
   Figura 1.2: base de datos en la región 1

5. Verifique que el estado de Data Guard está no activado, lo que confirma que Oracle Data Guard no está configurado mediante la consola de OCI.

   
   Figura 1.3: estado del plano de control de Data Guard en la región 1

6. Vaya al separador Etiquetas y cree las etiquetas de formato libre. Debe sustituir el valor de Peer DB OCID según la configuración. En este ejemplo, debe agregar el OCID de la base de datos de la región Phoenix.

   Clave de etiqueta	Valor
   FsdrNonStandardDataGuardPeerDatabaseId	Peer DB OCID
   FsdrNonStandardDataGuardFlag	True

   
   Figura 1.4: etiquetas de base de datos en la región 1

7. Vaya a Sistemas de base de datos y seleccione Nodos.

   
   Figura 1.5: nodo de base de datos en la región 1

   Nota: Esta es una configuración no RAC, por lo que verá un único nodo de base de datos. Si se tratara de una configuración de Oracle Real Application Clusters, vería dos nodos.

8. Conéctese al nodo de base de datos y cambie al usuario oracle. Utilice Oracle Data Guard Broker para verificar los roles.

   dgmgrl
   show configuration
   

   
   Figura 1.6: estado de Data Guard en la región 1

   Salida Esperada:

   • adghol_site0 debe aparecer como la base de datos principal.
   • adghol_site1 debe aparecer como la base de datos física en espera.
   • Configuration Status debe aparecer en Correcto.

   Si hay errores y los roles de base de datos no son los esperados, debe corregir los errores mediante la documentación de Oracle Data Guard.

9. Conéctese a la consola de OCI, vaya a Oracle Database y haga clic en Oracle Base Database Service.

10. Asegúrese de que el contexto de la región de OCI esté definido en Region 2 (Phoenix).

11. Seleccione el sistema de base de datos; en nuestro ejemplo, es adghol1-12345

    
    Figura 1.7: sistema de base de datos en la región 2

12. Vaya al separador Bases de datos y seleccione la base de datos adghol.

    
    Figura 1.8: base de datos en la región 2

13. Verifique que el estado de Data Guard está no activado, lo que confirma que Oracle Data Guard no está configurado mediante la consola de OCI.

    
    Figura 1.9: estado del plano de control de Data Guard en la región 2

14. Vaya al separador Etiquetas y cree las etiquetas de formato libre. Debe sustituir el valor de Peer DB OCID según la configuración. En este ejemplo, debe agregar el OCID de la base de datos de la región de Ashburn.

    Clave de etiqueta	Valor
    FsdrNonStandardDataGuardPeerDatabaseId	Peer DB OCID
    FsdrNonStandardDataGuardFlag	True

    
    Figura 1.10: etiquetas de base de datos en la región 2

15. Repita los pasos 7 y 8, pero esta vez conéctese al nodo de base de datos en la región 2 (región en espera).

    • Asegúrese de que está conectado como usuario oracle en el nodo de base de datos Región 2.
    • Verifique los roles de Oracle Data Guard mediante dgmgrl como en el paso 8.

Tarea 2: Creación y asociación de grupos de protección de DR

Cree grupos de protección de DR en la región 1 y la región 2 si los grupos de protección para esta pila de aplicaciones aún no existen.

Tarea 2.1: Creación de un grupo de protección en la región 1

1. Vaya a la consola de OCI y vaya a Grupos de protección de DR, como se muestra en la figura 2.1.

   1. Asegúrese de que el contexto de la región de OCI está definido en Región 1 (Ashburn).
   2. Haga clic en Migración y recuperación ante desastres.
   3. Haga clic en DR Protection Groups (Grupos de protección de DR).

   
   Figura 2.1: desplazamiento a los grupos de protección de DR

2. Cree un grupo de protección de DR básico en la región 1, como se muestra en la figura 2.2. El par, el rol y los miembros se asignarán en pasos posteriores.

   1. Seleccione el compartimento en el que desea que se cree el grupo de protección de DR.
   2. Haga clic en Crear Grupo de Protección de DR.
   3. Utilice un nombre significativo para el grupo de protección de DR.
   4. Seleccione Bloque de OCI Object Storage para los logs de DR de pila completa de OCI.
   5. Haga clic en Crear.

   
   Figura 2.2: parámetros necesarios para crear un grupo de protección de DR en la región 1

Tarea 2.2: Creación de un grupo de protección en la región 2

1. Vaya a la consola de OCI y vaya a Grupos de protección de DR, como se muestra en la figura 2.3.

   1. Asegúrese de que el contexto de la región de OCI está definido en la región 2 (Phoenix).
   2. Haga clic en Migración y recuperación ante desastres.
   3. Haga clic en DR Protection Groups (Grupos de protección de DR).

   
   Figura 2.3: desplazamiento a los grupos de protección de DR

2. Cree un grupo de protección de DR básico en la región 2, como se muestra en la figura 2.4. El par, el rol y los miembros se asignarán en pasos posteriores.

   1. Seleccione el compartimento en el que desea que se cree el grupo de protección de DR.
   2. Haga clic en Crear Grupo de Protección de DR.
   3. Utilice un nombre significativo para el DRPG.
   4. Seleccione Bloque de OCI Object Storage para los logs de DR de pila completa de OCI.
   5. Haga clic en Crear.

   
   Figura 2.4: parámetros necesarios para crear un grupo de protección de DR en la región 2

Tarea 2.3: Asociar grupos de protección en la región 1 y la región 2

Asocie los DRPG de cada región como iguales entre sí y asigne los roles de peer de principal y en espera. OCI Full Stack DR cambia automáticamente los roles de la base de datos principal y la base de datos en espera como parte de cualquier operación de DR/ejecución de plan de DR; no es necesario gestionar los roles manualmente en ningún momento.

1. Vaya a la página DR protection group details.

   1. Asegúrese de que el contexto de la región de OCI esté definido en Región 1 (Ashburn).
   2. Haga clic en el menú desplegable Acciones y en Asociar para iniciar el proceso.

   
   Fig. 2.5: inicio de asociación de DRPG

2. Introduzca la siguiente información.

   1. Rol: seleccione el rol Principal. OCI Full Stack DR asignará automáticamente el rol en espera a la región 2.
   2. Región peer: seleccione la región 2 (Phoenix), donde se creó el otro grupo de protección de DR.
   3. Grupo de protección de DR de igual: seleccione el grupo de protección de DR de igual que se creó.
   4. Haga clic en Asociar.

   
   Figura 2.6: parámetros necesarios para asociar los DRPG

OCI Full Stack DR mostrará algo similar a lo que se muestra en la siguiente imagen, una vez que se haya completado la asociación.

• El DRPG del igual principal actual es Ashburn (región 1).
• El DRPG del par en espera actual es Phoenix (región 2).

Figura 2.7: visualización de la relación de par desde la perspectiva de DRPG individual

La misma información se puede encontrar siempre que el contexto/vista sea desde una perspectiva global que muestre todos los grupos de protección de DR, como se muestra en la siguiente imagen.

• El DRPG del igual principal actual es Ashburn (región 1).
• El DRPG del par en espera actual es Phoenix (región 2).

Figura 2.8: visualización de la relación de par desde la perspectiva global de DRPG

Tarea 3: Adición de miembros a los grupos de protección de DR

En esta tarea, agregaremos los siguientes recursos de OCI al grupo de protección de DR principal en la región 1.

1. La instancia de OCI Compute que aloja el script del manejador de base de datos se agregará como una VM que no se mueve.
2. El sistema de base de datos principal.

Tarea 3.1: Agregar miembros al grupo de protección de DR en la región 1

1. Seleccione el grupo de protección de DR en la región 1 como se muestra en la siguiente imagen.

   1. Asegúrese de que el contexto de la región de OCI sea Región 1 (Ashburn).
   2. Seleccione el grupo de protección de DR en la región 1.
   3. Navegue hasta el separador Miembros.
   4. Haga clic en Gestionar miembros.

   
   Figura 3.1: cómo empezar a agregar miembros al grupo de protección de DR en la región 1

2. Agregue una instancia informática para los scripts del manejador de bases de datos.

   1. Seleccione Agregar miembro
   2. Seleccione Instancia en Recursos informáticos como Tipo de recurso miembro.
   3. Seleccione la instancia informática que aloja los scripts del manejador de base de datos.
   4. Seleccione Instancia no móvil.
   5. Haga clic en Agregar.

   
   Figura 3.2: Instancia informática se agrega al DRPG de la región 1

   Verifique la instancia informática agregada.

   
   Figura 3.2: instancia informática agregada al DRPG en la región 1

3. Agregue la base de datos primaria. Haga clic en Agregar Miembro.

   1. Seleccione Agregar miembro
   2. Seleccione Oracle Database -> Base de datos (base de datos base,ExaDB-D,ExaCC,ExaXS) como tipo de recurso miembro.
   3. Seleccione Base de datos base de Oracle como Tipo de base de datos.
   4. Seleccione Sistema de bases de datos.
   5. Seleccione Directorio Raíz de Base de Datos.
   6. Seleccione Base de datos.
   7. Seleccione Secreto de contraseña en base datos
   8. Haga clic en Agregar.

   
   Figura 3.3: parámetros necesarios para agregar la base de datos principal

   Verifique la base de datos primaria agregada y publique ambos miembros.

   
   Figura 3.4: base de datos principal agregada al DRPG en la región 1

   
   Figura 3.5: publicación de miembros en el DRPG en la región 1

   Después de unos minutos, ambos miembros deben estar disponibles bajo los miembros.

   
   Figura 3.6: miembros agregados al DRPG en la región 1

Tarea 3.2: Agregar miembros al grupo de protección de DR en la región 2

1. Seleccione el grupo de protección de DR en la región 2 como se muestra en la siguiente imagen.

   1. Asegúrese de que el contexto de región de OCI sea Región 2 (Phoenix).
   2. Seleccione el grupo de protección de DR en la región 2.
   3. Navegue hasta el separador Miembros.
   4. Haga clic en Gestionar miembros.

   
   Figura 3.7: Cómo empezar a agregar miembros al grupo de protección de DR en la región 2

2. Agregue una instancia informática para los scripts del manejador de bases de datos.

   1. Seleccione Agregar miembro
   2. Seleccione Instancia en Recursos informáticos como Tipo de recurso miembro.
   3. Seleccione la instancia informática que aloja los scripts del manejador de base de datos.
   4. Seleccione Instancia no móvil.
   5. Haga clic en Agregar.

   
   Figura 3.8: Instancia informática se agrega al DRPG de la región 2

   Verifique la instancia informática agregada.

   
   Figura 3.9: instancia informática agregada al DRPG en la región 2

3. Agregue la base de datos en espera. Haga clic en Agregar Miembro.

   1. Seleccione Agregar miembro
   2. Seleccione Oracle Database -> Base de datos (base de datos base,ExaDB-D,ExaCC,ExaXS) como tipo de recurso miembro.
   3. Seleccione Base de datos base de Oracle como Tipo de base de datos.
   4. Seleccione Sistema de bases de datos.
   5. Seleccione Directorio Raíz de Base de Datos.
   6. Seleccione Base de datos.
   7. Seleccione Secreto de contraseña en base datos
   8. Haga clic en Agregar.

   
   Figura 3.10: parámetros necesarios para agregar la base de datos en espera

   Verifique la base de datos en espera agregada y publique ambos miembros.

   
   Fig. 3.11: base de datos en espera agregada al DRPG en la región 2

   
   Figura 3.12: publicación de miembros en el DRPG en la región 2

   Después de unos minutos, ambos miembros deben estar disponibles bajo los miembros.

   
   Figura 3.13: miembros agregados al DRPG en la región 2

Tarea 4: Creación y personalización de los planes de DR en la región 2

En esta tarea, crearemos los planes iniciales de Switchover, Failover e Iniciar detalle asociados al grupo de protección de DR en espera en la región 2 (Phoenix).

Estos planes están diseñados para realizar una transición fluida de la carga de trabajo de la región principal (región 1) a la región en espera (región 2).

• OCI Full Stack DR rellena previamente estos planes con pasos incorporados basados en los recursos miembros agregados anteriormente.
• Sin embargo, en este tutorial, dado que Oracle Data Guard se configura manualmente (fuera del plano de control de base de datos), no habrá grupos de planes incorporados disponibles para las transiciones de roles de base de datos Oracle.
• Por lo tanto:
  • Personalice los planes de DR con grupos de planes definidos por el usuario.
  • Agregue scripts del manejador de base de datos para manejar las transiciones de roles durante cada tipo de plan (switchover, failover, cambio de nivel).

Los planes de DR siempre se crean en el grupo de protección que tiene el rol en espera.

Dado que la región 2 (Phoenix) es actualmente la en espera, crearemos todos los planes de DR iniciales allí.

Tarea 4.1: Crear planes de DR

1. Crear planes de DR seleccionando el DRPG en la región 2 (Phoenix)

   1. Asegúrese de que el contexto de región de OCI sea Región 2 (Phoenix).
   2. Seleccione el DRPG en espera en la región 2.
   3. Vaya al separador Planes.
   4. Haga clic en Crear plan.

   
   Figura 4.1: Cómo empezar a crear planes de DR básicos en la región 2

2. Crear un plan de switchover.

   1. Introduzca un nombre simple pero significativo para el plan de switchover. El nombre debe ser lo más corto posible, pero fácil de entender de un vistazo para ayudar a reducir la confusión y el error humano durante una crisis.
   2. Seleccione Tipo de plan como Switchover (planificado).

   
   Figura 4.2: parámetros necesarios para crear el plan de switchover de DR

3. Crear un plan de failover.

   Siga el mismo proceso para crear un plan de failover básico como se muestra en la siguiente imagen.

   1. Introduzca el nombre del plan de failover simple pero significativo.
   2. Seleccione Tipo de plan como Failover (no planificado).

   
   Figura 4.3: parámetros necesarios para crear un plan de failover de DR

4. Cree un plan de detalle de inicio.

   Siga el mismo proceso para crear un plan de failover básico como se muestra en la siguiente imagen.

   1. Introduzca el nombre del plan de detalle de inicio simple pero significativo.
   2. Seleccione Tipo de plan como Failover (no planificado).

   
   Figura 4.4: parámetros necesarios para crear el plan de detalle de inicio de DR

   El grupo de protección de DR en espera de la región 2 ahora debe tener los tres planes de DR, como se muestra en la siguiente imagen. Estas gestionarán las cargas de trabajo de transición de la región 1 a la región 2. Creará planes similares en la región 1 para realizar la transición de las cargas de trabajo de la región 2 a la región 1 en una tarea posterior.

   
   Figura 4.5: se muestran los tres planes de DR que deben existir en la región 2 antes de continuar.

Nota: OCI Full Stack DR permite crear un plan de detención de cambio de nivel solo después de que el plan de inicio de cambio de nivel se haya ejecutado correctamente y el grupo de protección de DR tenga el estado Inactivo (Profundización en curso).

Tarea 4.2: Personalización de los planes de DR con grupos de planes definidos por el usuario

Los planes de DR creados en la tarea 4.1 no generarán ningún grupo de planes incorporado para las transiciones de roles de base de datos Oracle, ya que la configuración de Oracle Data Guard se realizó manualmente.

En esta tarea, deberá:

• Descubra cómo agregar grupos de planes de DR personalizados y definidos por el usuario.
• Defina los pasos necesarios para gestionar las transiciones de roles de Oracle Data Guard.

Esto garantiza que los planes de DR puedan manejar completamente los escenarios de failover, switchover y cambio de nivel que implican un entorno de Data Guard configurado manualmente.

1. Vaya al plan de switchover creado en la tarea 4.1 y seleccione Grupos de planes.

   
   Figura 4.6: Cómo empezar a personalizar el plan de switchover en la región 2

2. Comience por agregar grupos de planes de DR definidos por el usuario personalizados para adaptar el flujo de trabajo de DR a las necesidades específicas de los cambios de rol de la base de datos Oracle. Estos grupos de planes llamarán a los scripts necesarios desde el inicio script-iad en la región 1.

3. Agregue un grupo de planes definido por el usuario a Conmutación de base de datos.

   1. Haga clic en Agregar grupo.
   2. Introduzca un nombre de grupo de planes simple pero descriptivo. En este ejemplo, utilizaremos DB Switchover.

   3. Haga clic en Agregar paso para abrir el cuadro de diálogo donde especificaremos el script para realizar el cambio de rol de base de datos.

      
      Figura 4.7: parámetros para crear un grupo de planes para realizar un cambio de rol de base de datos

      En Agregar paso de grupo de planes, introduzca la siguiente información.

   4. Introduzca un nombre de paso simple pero descriptivo. En este ejemplo, utilizaremos DB Switchover from IAD to PHX.
   5. Seleccione la región Instancia que contiene la instancia en que se ejecutara este paso. En este ejemplo, el script se ejecutará en el elemento jumphost de la región 2, así que seleccione Phoenix.
   6. Seleccione Ejecutar script local.
   7. Seleccione Instancia de destino, que es el elemento principal script-phx en la región 2.
   8. En Parámetros de script, introduzca la ruta de acceso completa del script con los parámetros. Por ejemplo: /home/opc/db-switchover-iad-phx.sh.
   9. En Ejecutar como usuario, introduzca opc.

   10. Haga clic en Agregar paso.

       
       Figura 4.8: parámetros para agregar un paso para el cambio de rol de base de datos

   11. Verifique el paso agregado.

       
       Figura 4.9: se ha agregado para el cambio de rol de base de datos

   12. Haga clic en Agregar.

       
       Figura 4.10: adición de grupo de cambio de rol de base de datos

       El grupo de planes estará disponible ahora.

       
       Fig. 4.11: grupo de planes de switchover de base de datos

4. Agregar un paso de comprobación previa definido por el usuario a un plan de DR de switchover. La comprobación previa definida por el usuario se ejecutará junto con los pasos de comprobación previa incorporados.

   1. Vaya a Grupos de planes, haga clic en la entrada … de Comprobaciones previas creadas y seleccione Agregar comprobación previa definida por el usuario.

      
      Figura 4.12: adición de comprobación previa personalizada para el switchover de base de datos

   2. Introduzca un nombre de paso simple pero descriptivo. En este ejemplo, utilizaremos DB Switchover precheck from IAD to PHX.
   3. Seleccione la región Instancia que contiene la instancia en que se ejecutara este paso. En este ejemplo, el script se ejecutará en el elemento jumphost de la región 2, así que seleccione Phoenix.
   4. Seleccione Ejecutar script local.
   5. Seleccione Instancia de destino, que es el elemento script-phx de la región.
   6. En Parámetros de script, introduzca la ruta de acceso completa del script con los parámetros. Por ejemplo: /home/opc/db-prechk-switchover-iad-phx.sh.
   7. En Ejecutar como usuario, introduzca opc.

   8. Haga clic en Agregar paso.

      
      Figura 4.13: parámetros para agregar un paso de comprobación previa personalizado para el cambio de rol de base de datos

   9. Verifique el paso agregado.

      
      Figura 4.14: se ha agregado un paso de comprobación previa personalizada para el cambio de rol de base de datos

      La personalización del plan de switchover se ha completado correctamente.

      
      Fig. 4.15: plan de switchover final

5. Del mismo modo, personalice los planes de conmutación por error, iniciar cambio de nivel, utilice la instancia de destino y los scripts correctos mediante los detalles tabulares disponibles en los requisitos previos: uso y personalización de scripts del manejador de base de datos.

6. Los planes de conmutación por error e inicio de detalle aparecerán como se muestra a continuación una vez que se agreguen el grupo de planes definido por el usuario y el paso de comprobación previa personalizado.

   
   Figura 4.16: plan de failover final

   
   Figura 4.17: plan de detalle de inicio final

Tarea 5: Ejecución de comprobaciones previas para los planes de DR en la región 2

Con el switchover, el failover, los planes de DR de inicio de detalle se han creado correctamente en la región 2 en espera. Estos planes permiten que OCI Full Stack DR migre las cargas de trabajo de la región 1 a la región 2 o realice un detalle de DR. La tarea posterior implica ejecutar las comprobaciones previas de los planes de DR para garantizar la preparación y validar el proceso de transición.

Tarea 5.1: Iniciar comprobaciones previas para el plan de switchover

Ejecute comprobaciones previas para el plan de DR de switchover.

1. Asegúrese de que el contexto de región está definido en la región 2 en espera.
2. Asegúrese de que se ha seleccionado el grupo de protección de DR correcto en la región 2; debe ser el rol en espera.
3. Haga clic en el menú desplegable Acciones.
4. Haga clic en Ejecutar comprobaciones previas.
5. Seleccione el plan Conmutación de base de datos de IAD a PHX.
6. Introduzca el nombre de ejecución del plan, si no es así, se generará automáticamente.

7. Haga clic en Ejecutar comprobaciones previas.

   
   Figura 5.1: muestra cómo ejecutar comprobaciones previas del plan de switchover

8. Verifique el estado Correcto desde el separador Ejecuciones de plan.

   
   Figura 5.2: visualización de comprobaciones previas completadas del plan de switchover

Tarea 5.2: Iniciar comprobaciones previas para el plan de failover

Ejecute las comprobaciones previas para el plan de DR de failover.

1. Asegúrese de que el contexto de región está definido en la región 2 en espera.
2. Asegúrese de que se ha seleccionado el grupo de protección de DR correcto en la región 2; debe ser el rol en espera.
3. Haga clic en el menú desplegable Acciones.
4. Haga clic en Ejecutar comprobaciones previas.
5. Seleccione el plan Failover de base de datos de IAD a PHX.
6. Introduzca el nombre de ejecución del plan, si no es así, se generará automáticamente.

7. Haga clic en Ejecutar comprobaciones previas.

   
   Figura 5.3: muestra cómo ejecutar comprobaciones previas del plan de failover

8. Verifique el estado Correcto desde el separador Ejecuciones de plan.

   
   Figura 5.4: visualización de comprobaciones previas completadas del plan de failover

Tarea 5.3: Iniciar comprobaciones previas para el inicio del plan de detalle

Ejecute las comprobaciones previas para el plan de DR de inicio de detalle.

1. Asegúrese de que el contexto de región está definido en la región 2 en espera.
2. Asegúrese de que se ha seleccionado el grupo de protección de DR correcto en la región 2; debe ser el rol en espera.
3. Haga clic en el menú desplegable Acciones.
4. Haga clic en Ejecutar comprobaciones previas.
5. Select the Start drill in PHX plan.
6. Introduzca el nombre de ejecución del plan, si no es así, se generará automáticamente.

7. Haga clic en Ejecutar comprobaciones previas.

   
   Figura 5.5: muestra cómo ejecutar comprobaciones previas del plan de cambio de nivel de inicio

8. Verifique el estado Correcto desde el separador Ejecuciones de plan.

   
   Figura 5.6: visualización de comprobaciones previas completadas del plan de failover

Tarea 6: Ejecución del plan de switchover en la región 2

Ejecute el plan de recuperación ante desastres de switchover para iniciar la transición de roles de la base de datos Oracle de la región 1 (principal) a la región 2 (en espera).

1. Asegúrese de que el contexto de región está definido en la región 2 en espera.
2. Asegúrese de que se ha seleccionado el grupo de protección de DR correcto en la región 2; debe ser el rol en espera.
3. Haga clic en el menú desplegable Acciones.

4. Haga clic en Ejecutar plan.

   
   Figura 6.1: cómo ejecutar el plan de switchover

5. Seleccione el plan Conmutación de base de datos de IAD a PHX.
6. Esta tarea ejecuta el plan de switchover en la región 2.
7. Anule la selección de Activar comprobaciones previas, ya que las comprobaciones previas ya se ejecutaron en la tarea 5. Si desea volver a ejecutarlo, puede activarlo.
8. Introduzca el nombre de ejecución del plan, si no es así, se generará automáticamente.

9. Haga clic en Ejecutar plan.

   
   Figura 6.2: muestra cómo ejecutar el plan de switchover

10. Vaya al separador Ejecuciones de plan y seleccione la ejecución del plan de switchover.

    
    Figura 6.3: visualización del plan de switchover en curso

11. Supervise el plan de switchover hasta que se haya realizado la transición completa de la carga de trabajo de la región 1 a la región 2. La ejecución del plan de switchover se ha completado correctamente en aproximadamente 8 minutos.

    
    Figura 6.4: visualización de una ejecución de plan de switchover finalizada.

12. Puede verificar el estado del rol de base de datos mediante los detalles proporcionados en la tarea 1.8.

    
    Figura 6.5: estado de Data Guard después del switchover

    Salida Esperada:

    • adghol_site1 debe aparecer como la base de datos principal.
    • adghol_site0 debe aparecer como la base de datos física en espera.
    • Configuration Status debe aparecer en Correcto.

13. El rol del grupo de protección de DR se intercambiará, la región 2 se mostrará como principal y la región 1 como en espera.

    
    Figura 6.6: cambio de rol de protección de DR después del switchover

Tarea 7: Creación y personalización de planes de DR en la región 1

Con la ejecución correcta del plan de recuperación ante desastres de switchover de la región 1 a la región 2, la región 2 ahora ha asumido el rol de principal, mientras que la región 1 ha pasado al rol en espera.

Siga el mismo enfoque detallado en la tarea 4 para crear y personalizar los planes de switchover, failover y cambio de nivel de DR dentro del grupo de protección de DR para la región 1, que ahora sirve como región peer en espera.

Una vez que estos planes se hayan creado y actualizado con grupos de planes definidos por el usuario y un paso de comprobación previa personalizado, tendrán el aspecto de las siguientes imágenes.

Fig. 7.1: planes de DR creados en la región 1

Fig. 7.2: plan de switchover en la región 1

Fig. 7.3: plan de failover en la región 1

Fig. 7.4: inicio del plan de detalle en la región 1

Si es necesario, puede ejecutar el plan de switchover para ascender la base de datos en la región 1 de nuevo al rol principal, mientras que la base de datos en la región 2 se convierte en la en espera.

Del mismo modo, puede ejecutar el plan de inicio de cambio de nivel para simular un evento de recuperación ante desastres y, a continuación, crear y ejecutar el plan de detención de cambio de nivel para revertir el sistema a su estado original.

• Durante el plan de inicio de obtención de detalles, la base de datos se convierte de una base de datos física en espera a una base de datos instantánea en espera. Esto permite a las aplicaciones acceder e interactuar temporalmente con la base de datos en espera para realizar pruebas.

• Durante el plan stop Drill, la base de datos se vuelve a convertir de Snapshot Standby a Physical Standby, lo que garantiza que se vuelve a sincronizar con la base de datos principal.

Pasos Siguientes

Para obtener más información, consulte la documentación de OCI Full Stack DR, Oracle Base Database Service y Oracle Data Guard en la sección Enlaces relacionados.

Enlaces relacionados

• Documentación de Oracle Cloud Infrastructure (OCI) Full Stack Disaster Recovery

• Cómo funciona Full Stack Disaster Recovery

• Página de producto de OCI Full Stack Disaster Recovery

• Scripts de cambio de rol de Oracle DB

• Servicios de OCI Oracle Database Cloud

• Oracle Database Data Guard

• Broker de Oracle Database Data Guard

• Oracle Live Labs: Automatiza la recuperación ante desastres en OCI con Full Stack Disaster Recovery

• Unirse al canal inactivo #full-stack-dr

Acuses de recibo

• Autor: Suraj Ramesh (mánager principal de productos de OCI Full Stack DR)
• Contribuyentes: Santhosh Shankaramanchi (miembro consultor del personal técnico de OCI Full Stack DR)

Más recursos de aprendizaje

Explore otros laboratorios en docs.oracle.com/learn o acceda a más contenido de aprendizaje gratuito en el canal YouTube de Oracle Learning. Además, visite education.oracle.com/learning-explorer para convertirse en un explorador de Oracle Learning.

Para obtener documentación sobre el producto, visite Oracle Help Center.

---

Título e Información de Copyright

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

G45723-03

Copyright ©2025,

Oracle y/o sus filiales.