Note:

Este tutorial requiere acceso a Oracle Cloud. Para registrarse para obtener una cuenta gratuita, consulte Introducción a la cuenta gratuita de Oracle Cloud Infrastructure.
Utiliza valores de ejemplo para credenciales, arrendamiento y compartimentos de Oracle Cloud Infrastructure. Al finalizar la práctica, sustituya estos valores por otros específicos de su entorno en la nube.

Automatice la recuperación ante desastres en frío para Oracle HeatWave MySQL mediante OCI Full Stack Disaster Recovery

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 regiones de 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 o rediseñar la infraestructura, las bases de datos o las aplicaciones existentes y sin necesidad de servidores de conversión o gestión especializados.

Oracle HeatWave MySQL es un servicio de base de datos totalmente gestionado desplegado en Oracle Cloud Infrastructure (OCI) que admite operadores y desarrolladores que buscan desplegar rápidamente aplicaciones seguras nativas en la nube. Oracle HeatWave MySQL es la única oferta MySQL que incluye la capacidad de utilizar HeatWave, un acelerador de consultas en memoria integrado y de alto rendimiento. HeatWave permite a los clientes ejecutar análisis sofisticados directamente en su base de datos MySQL operativa, lo que elimina el requisito de una migración de datos e integración con una base de datos de análisis separada, compleja, laboriosa y costosa. HeatWave acelera enormemente el rendimiento de MySQL para análisis y cargas de trabajo mixtas. HeatWave está totalmente optimizado para OCI y Oracle HeatWave MySQL está 100 % creado, gestionado y respaldado por los equipos de ingeniería de OCI y MySQL.

En este tutorial, aprenderá a automatizar una recuperación ante desastres en frío para Oracle HeatWave MySQL en OCI. Describe los procedimientos para utilizar el servicio OCI Full Stack DR para gestionar los procesos de switchover y failover.

Nota: Este tipo de estrategia de recuperación ante desastres (DR) se basa en un mecanismo de copia de seguridad y restauración, lo que la hace más adecuada para aplicaciones no críticas en las que los requisitos de negocio para los objetivos de tiempo de recuperación (RTO) y los objetivos de punto de recuperación (RPO) no son demasiado exigentes.

Descripción de Arquitectura

La arquitectura presentada en este tutorial muestra una aplicación WordPress que se ejecuta en máquinas virtuales (VM) de OCI perfectamente integrada con Oracle HeatWave MySQL. Además, la configuración aprovecha el servicio OCI File Storage como recurso compartido del sistema de archivos de red (NFS) para almacenar contenido WordPress. Este almacenamiento compartido se monta en cada máquina virtual, lo que garantiza un acceso inmediato y sincronizado a todo el contenido nuevo en todo el entorno.

Un equilibrador de carga de OCI se despliega en una subred pública para gestionar de forma eficaz las conexiones de usuarios externos y distribuir el tráfico entrante entre las máquinas virtuales WordPress.

Descripción de la arquitectura de recuperación de fallos

La estrategia de DR para las máquinas virtuales de la aplicación WordPress implica un enfoque completo, que incluye la replicación completa de cada volumen de inicio de máquina virtual con replicación de grupo de volúmenes y el uso de la replicación de File Storage para garantizar la sincronización del contenido WordPress.

Un equilibrador de carga se aprovisiona previamente en la región remota, lo que garantiza que está listo para manejar el tráfico sin problemas cuando se realiza la transición de las máquinas virtuales WordPress a la región remota durante un escenario de switchover o failover.

Para Oracle HeatWave MySQL, las copias de seguridad se copian regularmente en la región remota para garantizar la protección de datos y la preparación para la recuperación ante desastres. Este proceso se puede iniciar desde una máquina virtual de aplicación mediante un script personalizado, que se puede programar mediante crontab para una ejecución automatizada y coherente.

En el siguiente diagrama se ilustra el flujo de trabajo para copiar la última copia de seguridad de MySQL disponible de la región principal a la región remota.

fsdr_mds_copy_restore_bkp-Logical_Workflow_Copy_Backup_to_Remote.png

La siguiente configuración de crontab se ha configurado en el usuario opc de la aplicación WordPress VM1 para ejecutar el script mds_copy_bkp.py cada 4 horas. Esto garantiza la sincronización automática de copias de seguridad en la región en espera, lo que contribuye a mejorar la recuperación ante desastres:

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

Este trabajo ejecuta el script en el minuto 15 pasado cada 4a hora.

Todos los scripts están disponibles en GitHub y se detallan detalladamente en las siguientes secciones.

Nota: Asegúrese de programar este script (o uno similar) según los requisitos de negocio para copiar regularmente la copia de seguridad MySQL en la región remota. Sin este paso, el proceso de restauración puede fallar debido a que la copia de seguridad no está disponible en la región secundaria.

¿Cómo funciona la recuperación?

Después de ejecutar un switchover planificado, los roles se revertirán: la carga de trabajo principal se ejecutará en la región 2, mientras que la base de datos en espera funcionará en la región 1. La arquitectura aparecerá de la siguiente manera:

fsdr_mds_copy_restore_bkp-Physical_Switchover_Architecture.png

En la configuración actual, aprovechamos el servicio DNS privado de OCI para gestionar un registro DNS que dirige el tráfico al punto final activo de Oracle HeatWave MySQL. Durante el proceso de recuperación, este registro de DNS se actualiza mediante un script personalizado para reflejar el nuevo Oracle HeatWave MySQL, lo que garantiza una conmutación por error perfecta y la continuidad del servicio.

En el siguiente diagrama se ilustra el flujo de trabajo para restaurar la copia de seguridad MySQL más reciente en la región en espera.

fsdr_mds_copy_restore_bkp-Logical_Workflow_Restore_Backup_to_Remote.png

La solución de recuperación para este despliegue requiere OCI Full Stack DR para ejecutar una serie de scripts de Python personalizados durante una operación de recuperación, como un failover o switchover. Los scripts a los que se hace referencia en este tutorial los proporciona el equipo de especialistas en arquitectura en la nube de EMEA y están disponibles aquí: full-stack-disaster-recovery, que se adapta específicamente a esta solución de recuperación ante desastres.

En este tutorial se explica cómo descargar los scripts y cómo utilizarlos en una tarea posterior.

Nota: Los siguientes scripts se proporcionan como orientación genérica. Puede utilizar sus propios scripts o personalizar los scripts según la política corporativa y los requisitos de seguridad.

Definiciones y suposiciones a lo largo del tutorial

Regiones:
- La región 1 es Dubai: Dubai servirá inicialmente como la región principal. Sin embargo, este rol pasará a la base de datos en espera durante el proceso de switchover, que se realizará en las tareas posteriores como parte del plan de recuperación ante desastres.
- La región 2 es Abu Dhabi: Abu Dhabi funcionará inicialmente como la región en espera. Este rol pasará posteriormente a principal después del proceso de switchover, que se llevará a cabo en las tareas posteriores como parte del procedimiento de recuperación ante desastres.
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 optado por organizar todos los recursos de OCI para este tutorial en un solo compartimento.

WordPress Máquinas virtuales de aplicaciones y OCI File Storage

La arquitectura utilizada en este tutorial está diseñada en torno a OCI File Storage para garantizar que todas las máquinas virtuales de aplicaciones tengan acceso compartido al mismo contenido WordPress.

Para obtener más información sobre cómo montar correctamente el sistema de archivos en las instancias de Linux, consulte Configuring a File System to Automatically Mount (Linux Instances).

A continuación, se muestra un ejemplo de la configuración de archivos /etc/fstab para montar el sistema de archivos en la máquina virtual de la aplicación WordPress.

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

Sustituya xxx.xxx.xxx.xxx por la dirección IP del destino de montaje ubicado en la región 1 para garantizar una conectividad adecuada.

Objetivos

En este tutorial, se tratarán las siguientes tareas:

Tarea 1: Preparación del entorno para la recuperación ante desastres
Tarea 2: Creación de grupos de protección de DR (DRPG) en ambas regiones
Tarea 3: Adición de miembros al grupo de protección de DR
Tarea 4: Creación de planes de DR básicos en la región 2
Tarea 5: Personalización del plan de switchover en la región 2
Tarea 6: Personalización del plan de failover en la región 2
Tarea 7: Ejecución de comprobaciones previas de los planes de DR en la región 2
Tarea 8: Ejecución del plan de switchover en la región 2
Tarea 9: Creación y personalización de planes de DR en la región 1

Tarea 1: Preparación del entorno para la recuperación ante desastres

Tarea 1.1: Creación de grupos de volúmenes y activación de la replicación

Cree un grupo de volúmenes para las máquinas virtuales de aplicación WordPress en la región 1 y asegúrese de que se replique en la región 2. Asegúrese de que el volumen de inicio de cada máquina virtual de aplicación (WordPress) sea miembro del grupo de volúmenes y de que el grupo de volúmenes se replique en la región 2.

En la siguiente imagen se muestra la visualización del grupo de volúmenes creado, que incluye los volúmenes de inicio de las dos máquinas virtuales de aplicación WordPress, con la replicación activada correctamente en la región 2. Para obtener más información, consulte Creación de un grupo de volúmenes.

Tarea 1.2: Activación de la replicación de File Storage para el contenido WordPress

En la región 2, cree un sistema de archivos específicamente designado para la replicación. Este sistema de archivos se utilizará para replicar sin problemas datos de la región 1 a la región 2.
En la región 2, cree un destino de montaje que se utilizará durante el proceso de recuperación de la región 1 a la región 2.
Utilice el sistema de archivos creado en el paso 1 para activar y configurar la replicación desde OCI File Storage de origen en la región 1.

En la siguiente imagen se muestran los detalles de replicación de File Storage en la región 2.

Para obtener más información, consulte Replicación del sistema de archivos.

Tarea 1.3: Preparación de máquinas virtuales de aplicaciones para ejecutar la automatización personalizada

Instalar y configurar la interfaz de línea de comandos de Oracle Cloud Infrastructure (CLI de OCI). Para este tutorial, se utiliza Oracle Linux 8 para la máquina virtual de la aplicación WordPress. Para obtener más información, consulte Installing the CLI.
Despliegue el script del repositorio GitHub (mds_colddr_scripts) en la carpeta /home/opc.
Instale los pandas y tabule los módulos utilizados por el script proporcionado.
```
pip install pandas
pip install tabulate
```
Actualice el archivo config.csv con los detalles necesarios para Oracle HeatWave MySQL en la región 1.
- Sustituya MYSQL_DB_SYSTEM_OCID por el OCID de Oracle HeatWave MySQL. Puede mantener o personalizar la etiqueta MySQL para que se ajuste a sus requisitos específicos.
- Sustituya COMPARTMENT_OCID por el OCID del compartimento en el que se encuentra el sistema MySQL.
- Sustituya PRIMARY_SUBNET_OCID y STANDBY_SUBNET_OCID por los OCID de subred en ambas regiones.
- Sustituya PRIMARY_DNS_VIEW_OCID y STANDBY_DNS_VIEW_OCID por los OCID de las vistas de DNS privadas asociadas a la zona de DNS privada que gestiona el registro de punto final de Oracle HeatWave MySQL.
Nota: Asegúrese de que todos los valores se actualicen con precisión.

Como parte del tutorial, utilizaremos esta misma VM para ejecutar scripts definidos por el usuario. Asegúrese de que la máquina virtual que actúa como nodo de control de DR se haya configurado para ejecutar comandos. Para obtener más información, consulte Llamada a scripts personalizados mediante el comando run con Oracle Cloud Infrastructure Full Stack Disaster Recovery.

Tarea 1.4: Creación de políticas de OCI IAM para OCI Full Stack DR

Configure las políticas de OCI IAM necesarias para OCI Full Stack DR, como se describe en los siguientes documentos.

Tarea 1.5: Creación de políticas de OCI IAM para otros servicios gestionados por OCI Full Stack DR

OCI Full Stack DR debe tener la capacidad de controlar y gestionar otros servicios clave de OCI, como recursos informáticos, redes, almacenamiento y otros servicios varios. Para configurar las políticas de OCI IAM necesarias para otros servicios, consulte Políticas de otros servicios gestionados por Full Stack Disaster Recovery y Políticas de OCI IAM.

Tarea 2: Creación de grupos de protección de DR (DRPG) en ambas regiones

Cree grupos de protección de DR en las regiones 1 y 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

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 región de OCI está definido en Región 1 (Dubái).
2. Haga clic en Migración y recuperación ante desastres.
3. Haga clic en Grupos de protección de DR.
Figura 2.1: navegación a grupos de protección de DR
Cree un grupo de protección de DR (DRPG) 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 desee crear el DRPG.
2. Haga clic en Create DR protection group para abrir el cuadro de diálogo.
3. Utilice un nombre significativo para el DRPG.
4. Seleccione el cubo 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

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 región de OCI esté definido en Region 2 (Abu Dhabi).
2. Haga clic en Migración y recuperación ante desastres.
3. Haga clic en Grupos de protección de DR.
Figura 2.3: navegación a grupos de protección de DR
Cree un grupo básico de protección de DR (DRPG) 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 desee crear el DRPG.
2. Haga clic en Create DR protection group para abrir el cuadro de diálogo.
3. Utilice un nombre significativo para el DRPG.
4. Seleccione el cubo 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: Asociación de 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 principal y en espera como parte de cualquier operación de DR/ejecución del plan de DR; no es necesario gestionar los roles manualmente en ningún momento.

Vaya a la página Detalles de grupo de protección de DR.
1. Asegúrese de que el contexto de región de OCI esté definido en Región 1 (Dubái).
2. Haga clic en Asociar para comenzar el proceso.
Fig: inicio de asociación de DRPG
Introduzca los parámetros como se muestra en la siguiente imagen.
1. Rol: seleccione el rol Principal. OCI Full Stack DR asignará el rol en espera a la región 2 automáticamente.
2. Región peer: seleccione la región 2 (Abu Dhabi), donde se creó el otro DRPG.
3. Grupo de protección de DR de peer: seleccione el DRPG de peer que se creó.
4. Haga clic en Agregar.
Fig: parámetros necesarios para asociar los DRPG

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

El DRPG principal actual es Dubai (región 1).
El DRPG peer en espera actual es Abu Dhabi (región 2).

Figura: visualización de la relación entre pares desde la perspectiva de DRPG individual

Se puede encontrar la misma información 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 principal actual es Dubai (región 1).
El DRPG peer en espera actual es Abu Dhabi (región 2).

Figura: visualización de la relación entre pares desde la perspectiva del DRPG global

Tarea 3: Adición de miembros al grupo de protección de DR

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

Las dos instancias informáticas que alojan la aplicación WordPress se agregarán como máquinas virtuales en movimiento. Además, asegúrese de que la sección Sistemas de archivos de Opciones avanzadas esté configurada correctamente.
Grupo de volúmenes que contiene el volumen de inicio de los nodos de cálculo de la aplicación WordPress.
Almacenamiento de archivos de OCI que contiene el contenido WordPress.
Equilibrador de carga principal.

Tarea 3.1: Adición de miembros a DRPG en la región 1

Seleccione el DRPG 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 es la región 1 (Dubái).
2. Seleccione el DRPG en la región 1.
3. Seleccione Miembros.
4. Haga clic en Agregar Miembro para iniciar el proceso.
Figura: cómo empezar a agregar miembros al grupo de protección de DR en la región 1
Agregue una instancia informática para las máquinas virtuales de la aplicación WordPress.
1. Confirme la advertencia sobre los planes de DR.
2. Introduzca Compute como Resource type de miembro.
3. Seleccione la instancia informática que aloja la aplicación WordPress.
4. Seleccione Moving instance.
5. Haga clic en Agregar asignación de VNIC para seleccionar qué VCN y subred asignar a las VNIC de la región 2 durante una recuperación.
6. Haga clic en Mostrar opciones avanzadas.
7. En Configuración, seleccione Retener dominio de errores.
8. En Sistemas de archivos, complete la sección de asignación de exportación según la configuración, como se muestra en las siguientes imágenes.
Figura: parámetros necesarios para agregar la máquina virtual de aplicación WordPress

Figura: parámetros necesarios para asignar la VNIC en la región 2

Figura: opciones avanzadas, Retener dominio de errores

Figura: Opciones avanzadas, Asignación de sistemas de archivos

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

Nota: Repita los subpasos anteriores para todas las instancias informáticas de las máquinas virtuales de la aplicación WordPress.

Figura: dos instancias informáticas agregadas al DRPG en la región 1
Agregue el grupo de volúmenes en bloque que contiene el volumen de inicio de las máquinas virtuales de aplicación WordPress.
1. Confirme la advertencia sobre los planes de DR.
2. Seleccione Grupo de volúmenes como Tipo de recurso miembro.
3. Asegúrese de que se ha seleccionado el compartimento correcto que contiene el grupo de volúmenes y seleccione el grupo de volúmenes.
Fig: parámetros necesarios para agregar el grupo de volúmenes para WordPress Compute

Figura: grupo de volúmenes para WordPress Compute agregado al DRPG en la región 1
Agregue el almacenamiento de archivos de OCI que contiene el contenido WordPress.
1. Confirme la advertencia sobre los planes de DR.
2. Seleccione Sistema de archivos como Tipo de recurso miembro.
3. Asegúrese de que se ha seleccionado el compartimento correcto que contiene el sistema de archivos y seleccione el sistema de archivos.
4. Seleccione Dominio de disponibilidad de destino que se utilizará en la región 2.
5. Seleccione Ruta de exportación de origen para este sistema de archivos. Esta ruta de exportación se crea en la región de destino 2 después de restaurar el sistema de archivos.
6. Seleccione Destination mount target en la región 2 que se utiliza para crear una exportación para el sistema de archivos restaurado.
Fig: Parámetros necesarios para agregar el sistema de archivos para el contenido WordPress

Fig: sistema de archivos para contenido WordPress agregado al DRPG en la región 1
Agregue OCI Load Balancer.

En este ejemplo, agregaremos el equilibrador de carga como miembro del DRPG en la región 1.
1. Confirme la advertencia sobre los planes de DR.
2. Seleccione Equilibrador de carga como Tipo de recurso miembro.
3. Asegúrese de que se han seleccionado los compartimentos correctos para el equilibrador de carga y seleccione el equilibrador de carga que desea agregar.
4. Seleccione Equilibrador de carga de destino para utilizarlo en la región 2.
5. Seleccione Juego de backends de origen, que es el juego de backends utilizado por las máquinas virtuales de la aplicación WordPress. Un equilibrador de carga de OCI se puede compartir entre varias aplicaciones y puede tener varios juegos de backends configurados. Durante un switchover de DR, solo se moverá su configuración a la región en espera a los juegos de backends especificados aquí.
6. Seleccione Juego de Backend de Destino, que es el juego de backends vacío creado en la región 2.
Figura: parámetros necesarios para agregar el equilibrador de carga

Figura: equilibrador de carga agregado al DRPG en la región 1

Tarea 3.2: Adición de miembros a DRPG en la región 2

Seleccione el DRPG en la región 2, como se muestra en la siguiente imagen.
1. Asegúrese de que el contexto de la región de OCI es la región 1 (Abu Dhabi).
2. Seleccione el DRPG en la región 2.
3. Seleccione Miembros.
4. Haga clic en Agregar Miembro para iniciar el proceso.
Figura: cómo empezar a agregar miembros al grupo de protección de DR en la región 2
Agregue OCI Load Balancer.

En este ejemplo, agregaremos el equilibrador de carga como miembro del DRPG en la región 2.
1. Confirme la advertencia sobre los planes de DR.
2. Seleccione Equilibrador de carga como Tipo de recurso miembro.
3. Asegúrese de que se ha seleccionado el compartimento correcto para el equilibrador de carga y seleccione el equilibrador de carga que desea agregar.
4. Seleccione el equilibrador de carga de destino que se utilizará en la región 1.
5. Seleccione Juego de backends de origen, que es el juego de backends utilizado por las máquinas virtuales de la aplicación WordPress. Un equilibrador de carga de OCI se puede compartir entre varias aplicaciones y puede tener varios juegos de backends configurados. Durante un switchover de DR, solo se moverá su configuración a la región en espera a los juegos de backends especificados aquí.
6. Seleccione Juego de Backend de Destino. Este juego de backends se crea en la región 2.
Figura: parámetros necesarios para agregar el equilibrador de carga

Figura: equilibrador de carga agregado al DRPG en la región 2

Tarea 4: Creación de planes de DR básicos en la región 2

En esta tarea, crearemos los planes de switchover y failover iniciales asociados al grupo de protección de DR en espera en la región 2 (Abu Dhabi).

El objetivo de estos planes es 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). Como parte de cualquier operación de DR, los roles de los grupos de protección de DR en ambas regiones se revierten automáticamente: el grupo de protección en la región 1 se convierte en el grupo en espera, mientras que el grupo de protección en la región 2 asume el rol principal después de un failover o switchover.

OCI Full Stack DR rellenará previamente estos planes con pasos incorporados derivados de los recursos miembros agregados durante las tareas anteriores. Estos planes se personalizarán posteriormente para gestionar tareas específicas de Oracle HeatWave MySQL durante el proceso de recuperación.

Los planes de switchover siempre se crean dentro del grupo de protección que tiene el rol en espera. Dado que la Región 2 (Abu Dhabi) es actualmente el grupo de protección en espera, comenzaremos a crear los planes allí.

Tarea 4.1: Creación de planes de DR

Cree un plan básico seleccionando el DRPG en la región 2 (Abu Dhabi)
1. Asegúrese de que el contexto de la región de OCI es la región 2 (Abu Dhabi).
2. Seleccione el DRPG en espera en la región 2.
3. Seleccione Planes.
4. Haga clic en Crear plan para iniciar el proceso.
Figura: cómo empezar a crear planes de DR básicos en la región 2
Cree 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: parámetros necesarios para crear un plan de switchover de DR
Cree 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. 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 Failover (no planificado).
Fig: parámetros necesarios para crear un plan de failover de DR

El grupo de protección de DR en espera de la región 2 ahora debe tener los dos planes de DR, como se muestra en la siguiente imagen. Se encargarán de la transición de las cargas de trabajo 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: se muestran los dos planes de DR básicos que deben existir en la región 2 antes de continuar

Tarea 5: Personalización del plan de switchover en la región 2

Los planes de DR básicos creados en la tarea 4 contienen pasos rellenados previamente para las tareas de recuperación integradas en OCI Full Stack DR y no contienen nada para gestionar tareas de recuperación específicas de Oracle HeatWave MySQL. En esta tarea, se explica cómo agregar grupos de planes de DR personalizados y definidos por el usuario y los pasos para gestionar las tareas que se deben realizar durante una operación de switchover:

Cree una copia de seguridad de la base de datos después de cerrar correctamente las máquinas virtuales de la aplicación para garantizar la consistencia de los datos.
Transfiera la última copia de seguridad de base de datos a la región 2 de OCI remota para la redundancia y la recuperación ante desastres.
Restaure la copia de seguridad de base de datos más reciente en la región 2 para preparar el entorno para el switchover.
Actualice el registro DNS de la base de datos privada, lo que permite a las máquinas virtuales de la aplicación conectarse sin problemas a la base de datos en la región 2.
Termine la base de datos MySQL de origen en la región 1.

Tarea 5.1: Seleccionar el plan de switchover

Navegue hasta el plan de switchover creado en la tarea 4.

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

Tarea 5.2: (Opcional) Activar grupos de planes de DR que terminan artefactos

Hay tres grupos de planes que están desactivados por defecto en los planes de switchover, como se muestra en la siguiente imagen. Estos grupos de planes están desactivados para proporcionar tranquilidad durante la prueba, lo que garantiza que no se supriman artefactos y que una copia de seguridad viable permanezca intacta en caso de problemas durante la fase de prueba.

Sin embargo, estos tres grupos de planes están diseñados para terminar (suprimir) artefactos que ya no serán necesarios para futuras operaciones de DR. Sin estos grupos de planes activados, los artefactos no utilizados seguirán acumulándose con el tiempo a medida que realice switchover entre las dos regiones, lo que puede generar confusión sobre qué instancias informáticas, OCI File Storage y grupos de volúmenes deben estar activos.

De manera opcional, la activación de estos grupos de planes ahora ayudará a evitar la necesidad de la limpieza manual de artefactos innecesarios antes de entrar en producción. Este paso proactivo puede simplificar la transición a la producción y mantener un entorno más limpio y manejable.

Figura: grupos de planes desactivados por defecto

Para activar los grupos de planes, seleccione Activar todos los pasos en el menú contextual situado a la derecha del nombre del grupo de planes.

Fig: Activación de Terminación del Sistema de Archivos

Figura: haga clic en Activar para validar.

Figura: cómo activar la finalización de instancias informáticas

Figura: haga clic en Activar para validar.

Figura: cómo activar la finalización de grupo de volúmenes

Figura: haga clic en Activar para validar.

Tarea 5.3: Reordenar grupos de planes de DR

Es necesario montar el sistema de archivos en las nuevas máquinas virtuales movidas a la región 2 antes de actualizar los juegos de backends del equilibrador de carga. Esto garantiza que la aplicación tenga un acceso adecuado a los recursos de almacenamiento necesarios, lo que facilita una transición fluida durante el proceso de switchover.

Figura: captura de pantalla en la que se muestra el orden inicial del plan de switchover y cómo empezar a reordenar

Figura: inicie el reordenamiento

Mueva Sistemas de archivos - Montar en instancias informáticas antes de Equilibradores de carga - Actualizar juegos de backends de destino.
Haga clic en Guardar cambios.

Figura: Orden del Plan de Switchover Final

Tarea 5.4: Creación de un grupo de planes para ejecutar scripts personalizados

Comience agregando grupos de planes de DR personalizados y definidos por el usuario para adaptar el flujo de trabajo de DR a las necesidades específicas del proceso de DR de copia de seguridad/restauración de MySQL.

Estos grupos de planes llamarán a los scripts necesarios desde WordPress VM1 en la región 1 y se deben colocar en el flujo de trabajo de DR antes de iniciar las máquinas virtuales de la aplicación WordPress. Esto garantiza que la base de datos MySQL se restaure por completo y funcione antes de que las máquinas virtuales de la aplicación se pongan en línea.

Se debe agregar el siguiente plan personalizado al plan de switchover rellenado previamente: Crear copia de seguridad de MySQL Database, Copiar copia de seguridad de MySQL Database, Restaurar copia de seguridad de MySQL Database, Actualizar DNS de MySQL Database y Terminar origen de MySQL Database.

Agregue un grupo de planes personalizado para crear la copia de seguridad de la base de datos MySQL.
1. Haga clic en Agregar grupo.
2. Introduzca un nombre de grupo de planes simple pero descriptivo. En este ejemplo, utilizaremos Create MySQL DB Backup.
3. Seleccione una posición en la que se insertará el grupo de planes en el plan de DR. En este ejemplo, seleccione Agregar después para insertar nuestro grupo de planes definido por el usuario después del grupo de planes incorporado Instancias informáticas - Inicio.
4. Haga clic en Agregar paso para abrir el cuadro de diálogo donde especificaremos el script para crear la copia de seguridad de la base de datos MySQL.
Figura: Parámetros para crear el grupo de planes Crear Copia de Seguridad de Base de Datos MySQL

En Agregar paso de grupo de planes, introduzca la siguiente información.
1. Introduzca un nombre de paso simple pero descriptivo. En este ejemplo, utilizaremos Create MySQL DB Backup. Igual que el nombre del grupo de planes.
2. Seleccione una región que contenga la instancia en la que se ejecutará este paso. En este ejemplo, el script se ejecutará en la aplicación WordPress VM1 de la región 1.
3. Seleccione Run local script.
4. Seleccione Instancia de destino, que es la aplicación WordPress VM1 en la región 1.
5. En Parámetros de script, introduzca la ruta completa de la secuencia de comandos con los parámetros. Por ejemplo: /home/opc/mds_copy_restore_bkp/mds_create_bkp.py mds01.
6. En Ejecutar como usuario, introduzca opc.
7. Haga clic en Agregar paso.
Figura: Parámetros para crear Agregar un Paso Crear Copia de Seguridad de Base de Datos MySQL

Haga clic en Agregar.

Figura: Agregar un grupo de planes Crear Copia de Seguridad de Base de Datos MySQL
Agregue un grupo de planes personalizado para copiar la copia de seguridad de la base de datos MySQL.
1. Haga clic en Agregar grupo.
2. Introduzca el nombre del grupo de planes simple pero descriptivo. En este ejemplo, utilizaremos Copy MySQL DB Backup.
3. Seleccione una posición en la que se insertará el grupo de planes en el plan de DR. En este ejemplo, seleccione Agregar después para insertar nuestro grupo de planes definido por el usuario después del grupo de planes incorporado Crear copia de seguridad de base de datos MySQL.
4. Haga clic en Agregar Paso para abrir el cuadro de diálogo donde especificaremos el script para copiar la copia de seguridad de la base de datos MySQL.
Figura: Parámetros para crear el grupo de planes Copiar copia de seguridad de base de datos MySQL

En Agregar paso de grupo de planes, introduzca la siguiente información.
1. Introduzca un nombre de paso simple pero descriptivo. En este ejemplo, utilizaremos Copy MySQL DB Backup. Igual que el nombre del grupo de planes.
2. Seleccione una región que contenga la instancia en la que se ejecutará este paso. En este ejemplo, el script se ejecutará en la aplicación WordPress VM1 de la región 1.
3. Seleccione Run local script.
4. Seleccione la instancia de destino, que es la aplicación WordPress VM1 en la región 1.
5. En Parámetros de script, introduzca la ruta completa de la secuencia de comandos con los parámetros. Por ejemplo: /home/opc/mds_copy_restore_bkp/mds_copy_bkp.py mds01.
6. En Ejecutar como usuario, introduzca opc.
7. Haga clic en Agregar paso.
Figura: Parámetros para Agregar una Copia de Seguridad de Base de Datos MySQL de Copia de Paso

Haga clic en Agregar.

Figura: Agregar un grupo de planes Copiar copia de seguridad de base de datos MySQL
Agregue un grupo de planes personalizados para restaurar la copia de seguridad de la base de datos MySQL.
1. Haga clic en Agregar grupo.
2. Introduzca un nombre de grupo de planes simple pero descriptivo. En este ejemplo, utilizaremos Restore MySQL DB Backup.
3. Seleccione una posición en la que se insertará el grupo de planes en el plan de DR. En este ejemplo, seleccione Agregar después para insertar nuestro grupo de planes definido por el usuario después del grupo de planes incorporado Copiar copia de seguridad de base de datos MySQL.
4. Haga clic en Agregar paso para abrir el cuadro de diálogo donde especificaremos el script para restaurar la copia de seguridad de la base de datos MySQL.
Fig: Parámetros para crear el grupo de planes Restaurar copia de seguridad de base de datos MySQL

En Agregar paso de grupo de planes, introduzca la siguiente información.
1. Introduzca un nombre de paso simple pero descriptivo. En este ejemplo, utilizaremos Restore MySQL DB Backup. Igual que el nombre del grupo de planes.
2. Seleccione una región que contenga la instancia en la que se ejecutará este paso. En este ejemplo, el script se ejecutará en la aplicación WordPress VM1 de la región 1.
3. Seleccione Run local script.
4. Seleccione la instancia de destino, que es la aplicación WordPress VM1 en la región 1.
5. En Parámetros de script, introduzca la ruta completa de la secuencia de comandos con los parámetros. Por ejemplo: /home/opc/mds_copy_restore_bkp/mds_restore_bkp.py mds01 1 --config --switch.
6. En Ejecutar como usuario, introduzca opc.
7. Haga clic en Agregar paso.
Fig: Parámetros para Agregar una Restauración de Paso MySQL Copia de Seguridad de Base de Datos

Haga clic en Agregar.

Figura: Agregar un grupo de planes Restaurar copia de seguridad de base de datos MySQL
Agregue un grupo de planes personalizados para actualizar el DNS de la base de datos MySQL.
1. Haga clic en Agregar grupo.
2. Introduzca el nombre del grupo de planes simple pero descriptivo. En este ejemplo, utilizaremos Update MySQL DB DNS.
3. Seleccione una posición en la que se insertará el grupo de planes en el plan de DR. En este ejemplo, seleccione Agregar después para insertar nuestro grupo de planes definido por el usuario después del grupo de planes incorporado Restaurar copia de seguridad de base de datos MySQL.
4. Haga clic en Agregar paso para abrir el cuadro de diálogo donde especificaremos el script para actualizar el DNS de la base de datos MySQL.
Fig: parámetros para crear el grupo de planes Actualizar MySQL DNS de base de datos

En Agregar paso de grupo de planes, introduzca la siguiente información.
1. Introduzca un nombre de paso simple pero descriptivo. En este ejemplo, utilizaremos Update MySQL DB DNS. Igual que el nombre del grupo de planes.
2. Seleccione una región que contenga la instancia en la que se ejecutará este paso. En este ejemplo, el script se ejecutará en la aplicación WordPress VM1 de la región 1.
3. Seleccione Run local script.
4. Seleccione la instancia de destino, que es la aplicación WordPress VM1 en la región 1.
5. En Parámetros de script, introduzca la ruta completa de la secuencia de comandos con los parámetros. Por ejemplo: /home/opc/mds_copy_restore_bkp/mds_update_dns.py mds01 demo.local mds01.demo.local --remote.
6. En Ejecutar como usuario, introduzca opc.
7. Haga clic en Agregar paso.
Figura: parámetros para agregar una actualización paso a paso MySQL DB DNS

Haga clic en Agregar.

Fig: Agregar un grupo de planes Actualizar MySQL DNS de base de datos
Agregue un grupo de planes personalizado para terminar la base de datos origen MySQL.
1. Haga clic en Agregar grupo.
2. Introduzca un nombre de grupo de planes simple pero descriptivo. En este ejemplo, utilizaremos Terminate MySQL DB Source.
3. Seleccione una posición en la que se insertará el grupo de planes en el plan de DR. En este ejemplo, seleccione Agregar después para insertar nuestro grupo de planes definido por el usuario después del grupo de planes incorporado Sistemas de archivos - Eliminar del grupo de protección de DR.
4. Haga clic en Agregar paso para abrir el cuadro de diálogo donde especificaremos el script para terminar el origen de base de datos MySQL.
Figura: parámetros para crear el grupo de planes Terminar la base de datos de origen MySQL

En Agregar paso de grupo de planes, introduzca la siguiente información.
1. Introduzca un nombre de paso simple pero descriptivo. En este ejemplo, utilizaremos Terminate MySQL Source DB. Igual que el nombre del grupo de planes.
2. Seleccione una región que contenga la instancia en la que se ejecutará este paso. En este ejemplo, el script se ejecutará en la aplicación WordPress VM1 de la región 1.
3. Seleccione Run local script.
4. Seleccione la instancia de destino, que es la aplicación WordPress VM1 en la región 1.
5. En Parámetros de script, introduzca la ruta completa de la secuencia de comandos con los parámetros. Por ejemplo: /home/opc/mds_copy_restore_bkp/mds_terminate_db.py mds01.
6. En Ejecutar como usuario, introduzca opc.
7. Haga clic en Agregar paso.
Figura: parámetros para agregar una base de datos de origen MySQL de finalización de paso

Haga clic en Agregar.

Fig: Adición de un grupo de planes Terminación de la base de datos de origen MySQL
(Opcional) Agregue un grupo de planes personalizados para parar la aplicación WordPress.
1. Haga clic en Agregar grupo.
2. Introduzca un nombre de grupo de planes simple pero descriptivo. En este ejemplo, utilizaremos Application - Stop.
3. Seleccione una posición en la que se insertará el grupo de planes en el plan de DR. En este ejemplo, seleccione Agregar después para insertar nuestro grupo de planes definido por el usuario al final después del grupo de planes incorporado Equilibradores de carga - Actualizar juegos de backends de origen.
4. Haga clic en Agregar Paso para abrir el cuadro de diálogo donde especificaremos el script para parar la aplicación.
Figura: Parámetros para crear el grupo de planes Aplicación: Parar

En Agregar paso de grupo de planes, introduzca la siguiente información.
1. Introduzca un nombre de paso simple pero descriptivo. En este ejemplo, utilizaremos Application - Stop - VM1.
2. Seleccione una región que contenga la instancia en la que se ejecutará este paso. En este ejemplo, el script se ejecutará en la aplicación WordPress VM1 de la región 1.
3. Seleccione Run local script.
4. Seleccione la instancia de destino, que es la aplicación WordPress VM1 en la región 1.
5. En Parámetros de script, introduzca la ruta completa de la secuencia de comandos con los parámetros. Por ejemplo: /home/opc/fsdrscripts/wdp_stop.sh.
6. En Ejecutar como usuario, introduzca opc.
7. Haga clic en Agregar paso.
Figura: Parámetros para crear una aplicación de paso - Parar - VM1

Haga clic en Agregar paso para agregar un segundo paso para parar la aplicación en VM2.

Figura: Adición de una Aplicación de Paso: Parar: VM2

En Agregar paso de grupo de planes, introduzca la siguiente información.
1. Introduzca un nombre de paso simple pero descriptivo. En este ejemplo, utilizaremos Application - Stop - VM2.
2. Seleccione una región que contenga la instancia en la que se ejecutará este paso. En este ejemplo, el script se ejecutará en la aplicación WordPress VM2 de la región 1.
3. Seleccione Run local script.
4. Seleccione la instancia de destino, que es la aplicación WordPress VM2 en la región 1.
5. En Parámetros de script, introduzca la ruta completa de la secuencia de comandos con los parámetros. Por ejemplo: /home/opc/fsdrscripts/wdp_stop.sh.
6. En Ejecutar como usuario, introduzca opc.
7. Haga clic en Agregar paso.
Figura: Parámetros para crear una aplicación de paso - Parar - VM2

Haga clic en Agregar.

Figura: Agregar un grupo de planes Aplicación: Parar
(Opcional) Agregue un grupo de planes personalizados para iniciar la aplicación WordPress.
1. Haga clic en Agregar grupo.
2. Introduzca un nombre de grupo de planes simple pero descriptivo. En este ejemplo, utilizaremos Application - Start.
3. Seleccione una posición en la que se insertará el grupo de planes en el plan de DR. En este caso, seleccione Agregar después para insertar nuestro grupo de planes definido por el usuario al final, después del grupo de planes incorporado Sistemas de archivos - Montaje en instancias informáticas.
4. Haga clic en Agregar Paso para abrir el cuadro de diálogo donde especificaremos el script para iniciar la aplicación.
Figura: Parámetros para crear el grupo de planes Aplicación: Iniciar

En Agregar paso de grupo de planes, introduzca la siguiente información.
1. Introduzca un nombre de paso simple pero descriptivo. En este ejemplo, utilizaremos Application - Start - VM1.
2. Seleccione una región que contenga la instancia en la que se ejecutará este paso. En este caso, el script se ejecutará en la aplicación WordPress VM1 de la región 1.
3. Seleccione Run local script.
4. Seleccione la instancia de destino, que es la aplicación WordPress VM1 en la región 1.
5. En Parámetros de script, introduzca la ruta completa de la secuencia de comandos con los parámetros. Por ejemplo: /home/opc/fsdrscripts/wdp_start.sh.
6. En Ejecutar como usuario, introduzca opc.
7. Haga clic en Agregar paso.
Figura: Parámetros para crear una aplicación de paso - Inicio - VM1

Haga clic en Agregar paso para agregar un segundo paso para iniciar la aplicación en VM2.

Figura: Adición de una Aplicación de Paso: Inicio: VM2

En Agregar paso de grupo de planes, introduzca la siguiente información.
1. Introduzca un nombre de paso simple pero descriptivo. En este ejemplo, utilizaremos Application - Start - VM2.
2. Seleccione una región que contenga la instancia en la que se ejecutará este paso. En este caso, el script se ejecutará en la aplicación WordPress VM2 de la región 1.
3. Seleccione Run local script.
4. Seleccione la instancia de destino, que es la aplicación WordPress VM2 en la región 1.
5. En Parámetros de script, introduzca la ruta completa de la secuencia de comandos con los parámetros. Por ejemplo: /home/opc/fsdrscripts/wdp_start.sh.
6. En Ejecutar como usuario, introduzca opc.
7. Haga clic en Agregar paso.
Figura: Parámetros para crear una aplicación de paso - Inicio - VM2

Haga clic en Agregar.

Figura: Adición de un Grupo de Planes Aplicación - Inicio

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

Tarea 6: Personalización del plan de failover en la región 2

En esta tarea, agregue grupos de planes de DR personalizados y definidos por el usuario y pasos para gestionar las tareas que se deben realizar durante una conmutación por error.

Restaure la copia de seguridad de base de datos más reciente en la región 2 para preparar el entorno para el switchover.
Actualice el registro DNS de la base de datos privada, lo que permite a las máquinas virtuales de la aplicación conectarse sin problemas a la base de datos en la región 2.

Tarea 6.1: Seleccionar el plan de failover

Navegue hasta el plan de failover creado en la tarea 4.

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

Tarea 6.2: Creación de un grupo de planes para ejecutar scripts personalizados en la región 2

Estos grupos de planes llamarán a los scripts necesarios desde la máquina virtual de la aplicación WordPress y deben colocarse en el flujo de trabajo de DR antes de reiniciar las máquinas virtuales de la aplicación WordPress. Esto garantiza que la base de datos MySQL se restaure por completo y funcione antes de que las máquinas virtuales de la aplicación se pongan en línea.

Se debe agregar el siguiente plan personalizado al plan de failover rellenado previamente: Restaurar copia de seguridad de MySQL Database y Actualizar DNS de MySQL Database.

Agregue un grupo de planes personalizados para restaurar la copia de seguridad de la base de datos MySQL.
1. Haga clic en Agregar grupo para comenzar.
2. Introduzca un nombre de grupo de planes simple pero descriptivo. En este ejemplo, utilizaremos Restore MySQL DB Backup.
3. Seleccione una posición en la que se insertará el grupo de planes en el plan de DR. En este ejemplo, seleccione Agregar después para insertar nuestro grupo de planes definido por el usuario después del grupo de planes incorporado Instancias informáticas - Inicio.
4. Haga clic en Agregar paso para abrir el cuadro de diálogo donde especificaremos el script para restaurar la copia de seguridad de la base de datos MySQL.
Fig: Parámetros para crear el grupo de planes Restaurar copia de seguridad de base de datos MySQL

En Agregar paso de grupo de planes, introduzca la siguiente información.
1. Introduzca un nombre de paso simple pero descriptivo. En este ejemplo, utilizaremos Restore MySQL DB Backup. Igual que el nombre del grupo de planes.
2. Seleccione una región que contenga la instancia en la que se ejecutará este paso. En este ejemplo, el script se ejecutará en la aplicación WordPress VM1 de la región 1.
3. Seleccione Run local script.
4. Seleccione la instancia de destino, que es la aplicación WordPress VM1 en la región 1.
5. En Parámetros de script, introduzca la ruta completa de la secuencia de comandos con los parámetros. Por ejemplo: /home/opc/mds_copy_restore_bkp/mds_restore_bkp.py mds01 1 --config.
6. En Ejecutar como usuario, introduzca opc.
7. Haga clic en Agregar paso.
Fig: Parámetros para Agregar una Restauración de Paso MySQL Copia de Seguridad de Base de Datos

Haga clic en Agregar.

Figura: Agregar un grupo de planes Restaurar copia de seguridad de base de datos MySQL
Agregue un grupo de planes personalizados para actualizar el DNS de la base de datos MySQL.
1. Haga clic en Agregar grupo para comenzar.
2. Introduzca un nombre de grupo de planes simple pero descriptivo. En este ejemplo, utilizaremos Update MySQL DB DNS.
3. Seleccione una posición en la que se insertará el grupo de planes en el plan de DR. En este ejemplo, seleccione Agregar después para insertar nuestro grupo de planes definido por el usuario después del grupo de planes incorporado Restaurar copia de seguridad de base de datos MySQL.
4. Haga clic en Agregar paso para abrir el cuadro de diálogo donde especificaremos el script para actualizar el DNS de la base de datos MySQL.
Fig: parámetros para crear el grupo de planes Actualizar MySQL DNS de base de datos

En Agregar paso de grupo de planes, introduzca la siguiente información.
1. Introduzca un nombre de paso simple pero descriptivo. En este ejemplo, utilizaremos Update MySQL DB DNS. Igual que el nombre del grupo de planes.
2. Seleccione una región que contenga la instancia en la que se ejecutará este paso. En este ejemplo, el script se ejecutará en la aplicación WordPress VM1 de la región 1.
3. Seleccione Run local script.
4. Seleccione la instancia de destino, que es la aplicación WordPress VM1 en la región 1.
5. En Parámetros de script, introduzca la ruta completa de la secuencia de comandos con los parámetros. Por ejemplo: /home/opc/mds_copy_restore_bkp/mds_update_dns.py mds01 demo.local mds01.demo.local.
6. En Ejecutar como usuario, introduzca opc.
7. Haga clic en Agregar paso.
Fig: Parámetros para crear Agregar una Actualización de Paso MySQL DB DNS

Haga clic en Agregar.

Fig: Agregar un grupo de planes Actualizar MySQL DNS de base de datos
(Opcional) Agregue un grupo de planes personalizados para reiniciar la aplicación WordPress.
1. Haga clic en Agregar grupo.
2. Introduzca un nombre de grupo de planes simple pero descriptivo. En este ejemplo, utilizaremos Application - Restart.
3. Seleccione una posición en la que se insertará el grupo de planes en el plan de DR. En este ejemplo, seleccione Agregar después para insertar nuestro grupo de planes definido por el usuario después del grupo de planes incorporado Sistemas de archivos - Montaje en instancias informáticas.
4. Haga clic en Agregar Paso para abrir el cuadro de diálogo donde especificaremos el script para iniciar la aplicación.
Figura: Parámetros para crear el grupo de planes Aplicación: Reiniciar

En Agregar paso de grupo de planes, introduzca la siguiente información.
1. Introduzca un nombre de paso simple pero descriptivo. En este ejemplo, utilizaremos Application - Restart - VM1.
2. Seleccione una región que contenga la instancia en la que se ejecutará este paso. En este ejemplo, el script se ejecutará en la aplicación WordPress VM1 de la región 1.
3. Seleccione Run local script.
4. Seleccione la instancia de destino, que es la aplicación WordPress VM1 en la región 1.
5. En Parámetros de script, introduzca la ruta completa de la secuencia de comandos con los parámetros. Por ejemplo: /home/opc/fsdrscripts/wdp_restart.sh.
6. En Ejecutar como usuario, introduzca opc.
7. Haga clic en Agregar paso.
Figura: Parámetros para crear una aplicación de paso - Reiniciar - VM1

Haga clic en Agregar paso para agregar un segundo paso para reiniciar la aplicación en VM2.

Figura: Adición de una Aplicación de Paso: Reinicio: VM2

En Agregar paso de grupo de planes, introduzca la siguiente información.
1. Introduzca un nombre de paso simple pero descriptivo. En este ejemplo, utilizaremos Application - Start - VM2.
2. Seleccione una región que contenga la instancia en la que se ejecutará este paso. En este ejemplo, el script se ejecutará en la aplicación WordPress VM2 de la región 1.
3. Seleccione Run local script.
4. Seleccione la instancia de destino, que es la aplicación WordPress VM2 en la región 1.
5. En Parámetros de script, introduzca la ruta completa de la secuencia de comandos con los parámetros. Por ejemplo: /home/opc/fsdrscripts/wdp_restart.sh.
6. En Ejecutar como usuario. Introduzca opc.
7. Haga clic en Agregar paso.
Figura: Parámetros para Crear una Aplicación de Paso: Reiniciar: VM2

Haga clic en Agregar.

Figura: Agregar un grupo de planes Aplicación: Reiniciar

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

Tarea 7: Ejecución de comprobaciones previas en la región 2

Los planes de DR de switchover y failover se han creado correctamente en la región 2 en espera. Estos planes permiten a OCI Full Stack DR realizar la transición de las cargas de trabajo de la región 1 a la región 2. La tarea siguiente implica la ejecución de comprobaciones previas para los planes de switchover y failover para garantizar la preparación y validar el proceso de transición.

Tarea 7.1: Inicio de comprobaciones previas para el plan de switchover

Ejecute comprobaciones previas para el plan de DR de switchover.

Asegúrese de que el contexto de región está definido en la región 2 en espera.
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.
Haga clic en el nombre del plan de switchover.
Haga clic en Run prechecks.

comprobaciones previas-so-auh-begin.png
Figura: Visualización del Modo de Ejecución de Comprobaciones Previas del Plan de switchover

comprobaciones previas-so-auh-complete.png
Figura: Visualización de Comprobaciones Previas Terminadas del Plan de switchover

Tarea 7.2: Inicio de comprobaciones previas para el plan de failover

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

Asegúrese de que el contexto de región está definido en la región 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.
Haga clic en el nombre del plan de failover.
Haga clic en Run prechecks.

comprobaciones previas-fo-auh-begin.png
Figura: Visualización de Cómo Ejecutar Comprobaciones Previas del Plan de Failover

comprobaciones previas-fo-auh-complete.png
Figura: Visualización de Comprobaciones Previas Terminadas del Plan de Failover

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

Ejecute el plan de DR de switchover para iniciar el proceso de transición de la aplicación WordPress a Oracle HeatWave MySQL de la región 1 a la región 2.

Asegúrese de que el contexto de región está definido en la región 2 en espera.
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.
Haga clic en el nombre del plan de switchover.
Haga clic en Ejecutar plan.

Esta tarea ejecuta el plan de switchover en la región 2.

Anule la selección de Activar comprobaciones previas, ya que ya se han ejecutado en la tarea 7.
Haga clic en Execute DR plan para comenzar.

Figura: Visualización de la Ejecución del Plan de switchover

Figura: Visualización del plan de switchover en curso

Supervise el plan de switchover hasta que la carga de trabajo completa haya pasado por completo de la región 1 a la región 2.

La ejecución del plan de switchover se ha completado correctamente en aproximadamente 52 minutos.

Figura: Visualización de una ejecución de plan de switchover finalizada.

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

Con la finalización correcta del switchover por parte de OCI Full Stack DR, la región 2 ahora ha asumido el rol de la región principal, mientras que la región 1 ha realizado la transición para que actúe como región en espera.

Siga el mismo enfoque detallado en la tarea 1 a 8, cree y personalice los planes de switchover y failover dentro del grupo de protección de DR para la región 1, que ahora sirve como región de peer en espera.

Figura: captura de pantalla en la que se muestran los planes creados en la región 1

Figura: captura de pantalla en la que se muestra el plan de switchover en la región 1

Figura: captura de pantalla que muestra el plan de failover en la región 1

Pasos Siguientes

Para obtener más información, consulte la documentación de OCI Full Stack DR y Oracle HeatWave MySQL en la sección Enlaces relacionados.

Agradecimientos

Autor: Antoun Moubarak (especialista de hiperescalador a OCI)
Contribuyente: Suraj Ramesh (gestor de productos para OCI Full Stack DR)

Más recursos de aprendizaje

Explore otros laboratorios en docs.oracle.com/learn o acceda a más contenido de formación gratuita en el canal YouTube de Oracle Learning. Además, visita education.oracle.com/learning-explorer para convertirte en un Oracle Learning Explorer.

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

Título e Información de Copyright

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

G24409-01

January 2025

Oracle y/o sus filiales.