Verificar la configuración

Cuando se complete la configuración de DR, valide inmediatamente que la configuración sea correcta mediante un switchover completo o la apertura del sitio secundario para la validación. Abrir el sitio secundario para la validación no afectará el sistema que se ejecuta en el principal.

Abrir secundario para validación

Puede validar la ubicación en espera sin realizar un switchover completo convirtiendo la base de datos en espera en una base de datos de instantánea en espera. Esto permite que los servidores WebLogic Server secundarios se inicien en el sitio en espera y verifiquen el sistema secundario. Cualquier cambio realizado en la base de datos de ubicación en espera mientras está en modo de instantánea en espera se desechará una vez que se vuelva a convertir en física en espera. Los datos principales no se ven afectados por las validaciones de sitios secundarios.

Nota:

Esta operación se debe realizar con precaución: si hay mensajes de JMS pendientes en la base de datos cuando se convierte en instantánea, los servidores de la ubicación en espera los procesarán cuando se inicien. Compruebe que no hay acciones pendientes en la base de datos primaria al convertir a la base de datos de instantánea en espera.

Como usuario oracle, utilice el broker de Oracle Data Guard en el host de la base de datos principal y convierta el secundario en una base de datos de instantánea en espera.
```
[oracle@dbhost1~]$ dgmgrl sys/your_sys_password@primary_db_unqname
DGMGRL> convert database secondary_db_unqname to snapshot standby
```
Utilice el comando show configuration para verificar que la conversión se ha realizado correctamente.
Si aún no están activos, inicie los sistemas Oracle HTTP Server en el sitio secundario.
Inicie el servidor de administración en la ubicación secundaria.
Inicie los servidores gestionados secundarios en el sitio secundario.
Utilice la consola o los scripts WebLogic para iniciar los servidores gestionados secundarios.
Valide el sitio secundario.

Como no se trata de un switchover y la ubicación principal aún está activa, el nombre de front-end virtual se resolverá en la dirección IP del equilibrador de carga de la ubicación principal, por lo que, por defecto, cualquier acceso al explorador se redirigirá a la ubicación principal activa.

Para acceder directamente a las aplicaciones del servidor WebLogic del sitio secundario, debe actualizar el archivo /etc/hosts en un cliente controlado (por ejemplo, un equipo portátil), configurar el nombre de front-end virtual para que se resuelva en la dirección IP del equilibrador de carga front-end del sitio secundario y ejecutar cualquier validación desde este cliente.

Nota:
Verifique que el cliente utilizado para las validaciones no acceda al sistema a través de un proxy HTTP, porque el proxy HTTP puede seguir resolviendo el nombre de front-end virtual con la dirección IP del equilibrador de carga del sitio principal, independientemente del nombre que se encuentre en /etc/hosts del cliente.

Es posible que los clientes que no son de Linux requieran un restablecimiento de su caché DNS local antes de que un explorador resuelva la dirección IP mediante la entrada de archivo de host personalizada.

Una vez que se haya validado el sitio secundario, vaya al paso siguiente para revertirlo al rol en espera.

Nota:
Puede llevar tiempo validar el sitio secundario.
Pare los servidores gestionados y los servidores de administración en el sitio secundario.
Utilice la consola secundaria WebLogic para cerrar los servidores gestionados y el servidor de administración del sitio secundario.
Como usuario oracle, utilice Oracle Data Guard Broker en el host de la base de datos primaria y vuelva a convertir el secundario en la base de datos física en espera.
Necesitará la contraseña del sistema y el nombre único de la base de datos primaria.
```
[oracle@dbhost1 ~]$ dgmgrl sys/your_sys_password@primary_db_unqname
    DGMGRL> convert database secondary_db_unqname to physical standby
```
Utilice show configuration para verificar la conversión.
Revierta los archivos /etc/hosts actualizados.
Si ha actualizado cualquier archivo /etc/hosts en un cliente para que apunte al sitio secundario para las validaciones, vuelva a revertir para que el nombre de front-end virtual apunte de nuevo a la dirección IP de front-end principal.

Realización de un switchover

Un switchover es una operación planificada en la que un administrador revierte los roles de los dos sitios. Después de un switchover, el sistema principal pasa a ser secundario y el sistema secundario pasa a ser principal. Si se realiza un switchover, se producirá un tiempo de inactividad en la ubicación principal.

Antes de realizar un switchover en una configuración de DR híbrida de WebLogic Server, propague los cambios de configuración pendientes. Asegúrese de que no haya cambios replicados en el sitio secundario pendientes.

Desactive cualquier replicación programada mientras se realiza el switchover, ya que puede fallar e interferir con la operación de switchover en sí.
Pare los sistemas Oracle HTTP Server en la ubicación principal.
Detenga los servidores en el sitio principal.
Utilice la consola o los scripts del servidor de administración WebLogic para parar los servidores WebLogic en la ubicación principal.

Nota:
El servidor de administración de la ubicación primaria puede permanecer activo durante el switchover. Sin embargo, se recomienda pararlo cuando la ubicación esté en rol en espera porque se espera que la configuración principal sustituya la configuración de dominio de la ubicación en espera durante el ciclo de vida. Si el servidor de administración está activo mientras ocurre esto, se ejecutará con una configuración obsoleta.
Switchover del nombre de DNS de front-end.

Realice la transferencia de DNS necesaria en el servidor DNS que aloja los nombres que utiliza el sistema o modifique la resolución de host de archivo en los clientes para que el nombre virtual de front-end del sistema apunte a la IP pública que utiliza el equilibrador de carga en el sitio secundario.

En los escenarios en los que se utiliza DNS para la resolución de front-end externa (como OCI DNS o DNS comercial), puede utilizar una API para impulsar el cambio. Para ver un ejemplo que transfiera este cambio en un DNS de OCI, vaya a GitHub, por ejemplo, scripts.

Tenga en cuenta que el valor de TTL de la entrada de DNS afectará al RTO del switchover: si el TTL es alto (por ejemplo, 20 min), el cambio de DNS tardará ese tiempo en ser efectivo en los clientes. El uso de valores TTL inferiores hará que sea más rápido; sin embargo, esto puede provocar una sobrecarga porque los clientes golpearán el DNS con más frecuencia en lugar de utilizar nombres en caché. Un buen enfoque es definir el TTL en un valor bajo temporalmente (por ejemplo, 1 min), antes del cambio en el DNS. A continuación, realice el cambio y, una vez finalizado el procedimiento de switchover, vuelva a revertir el TTL a su valor original.
Como usuario oracle, utilice el broker de Oracle Data Guard en el host de la base de datos principal para realizar el switchover de la base de datos.
Necesitará la contraseña del sistema y el nombre único de la base de datos primaria.
```
[oracle@dbhost1~]$ dgmgrl sys/your_sys_password@primary_db_unqname
DGMGRL> switchover to secondary_db_unqname
```
Si aún no están activos, inicie los sistemas Oracle HTTP Server en el sitio secundario (nuevo principal).
Inicie el servidor de administración en el sitio secundario (nuevo principal) o reinicie el servidor si ya se ha iniciado.
Al iniciar el servidor de administración, se activan los cambios de configuración que se replicaron mientras estaba en espera para que se apliquen.
Inicie los servidores gestionados secundarios en el sitio secundario (nuevo principal).
Utilice la consola o los scripts WebLogic para iniciar los servidores gestionados secundarios.