Ciclo de Vida

Se realizan diferentes operaciones en el sistema durante su ciclo de vida. Los más relevantes son conmutar y probar o abrir el secundario para validaciones, aplicación de parches, etc.

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 se convierte en secundario y el sistema secundario en principal. La realización de un switchover provocará tiempo de inactividad en el sitio principal.

El switchover se realiza siguiendo los procedimientos estándar (consulte Switchover en Recuperación ante desastres de Oracle WebLogic Server for Oracle Cloud Infrastructure y SOA Suite en la recuperación ante desastres de Oracle Cloud Infrastructure Marketplace.).

  1. Propague los cambios de configuración pendientes por los pasos proporcionados en "Setup Ongoing Configuration Replication".
  2. Pare los servidores en la ubicación primaria.
  3. Switchover de nombres DNS.
  4. Switchover de la base de datos.
  5. Inicie los servidores en el sitio secundario.

La principal diferencia es que solo se utiliza la consola de Oracle Cloud Infrastructure (OCI) para realizar el switchover de la instancia de Oracle Autonomous Database.

Nota:

Para las clonaciones de refrescamiento remoto, si se realiza un switchover permanente (si el secundario se convierte en principal más allá de una prueba o verificación no permanente), debe crear una clonación de refrescamiento de peer en la región principal original para tener un sistema secundario para pruebas y validaciones en la nueva base de datos en espera (originalmente principal). La clonación de refrescamiento en la secundaria no se podrá volver a conectar, ya que su origen ahora será una base de datos en espera (las clonaciones de refrescamiento no se pueden crear, mantener ni conectar desde Oracle Autonomous Database Serverless en espera). No es posible refrescarla de nuevo y, si es necesario, puede eliminar la base de datos para reducir los costos. Para crear la nueva clonación de refrescamiento en la primaria original (ahora en espera), siga el mismo procedimiento que con la primera.

Realice los siguientes pasos para la operación de switchover:

  1. Desactive cualquier replicación programada mientras se realiza el switchover, ya que puede fallar e interferir con la propia operación de switchover.
  2. Detenga los servidores en el sitio principal.
    Utilice la consola o los scripts de Oracle WebLogic Administration Server para parar las instancias de Oracle WebLogic Server en la dirección principal.

    Nota:

    El servidor de administración del sitio principal puede permanecer activo durante el switchover. Sin embargo, se recomienda detenerla cuando la ubicación tiene un rol en espera porque se espera que la configuración del dominio de la ubicación en espera sea sustituida por la configuración principal durante el ciclo de vida. Si el servidor de administración está activo mientras esto ocurre, se ejecutará con una configuración obsoleta.
  3. Realice el switchover del nombre de DNS de front-end.

    Realice la transferencia de DNS necesaria en el servidor DNS que aloja los nombres utilizados por el sistema o modifique la resolución de host de archivo en los clientes para que apunte el nombre virtual de front-end del sistema a la IP pública utilizada por 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 para actualizar el DNS de front-end.

    Nota:

    El valor de TTL de la entrada DNS afectará al RTO del switchover: si el TTL es alto (por ejemplo, 20 minutos), el cambio de DNS tardará ese tiempo en ser efectivo en los clientes. El uso de valores TTL inferiores hará que esto sea más rápido; sin embargo, esto puede causar una sobrecarga porque los clientes golpearán el DNS con más frecuencia en lugar de utilizar nombres almacenados en caché. Un buen enfoque es definir la TTL en un valor bajo temporalmente (por ejemplo, 1 minuto), 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.
  4. Conéctese a la consola de Oracle Cloud Infrastructure (OCI) para la región SECUNDARIA y, a continuación, navegue hasta Autonomous Database.
  5. Seleccione el compartimento que aloja la base de datos de Oracle WebLogic y haga clic en el nombre de la base de datos.
  6. Seleccione Switchover en el menú desplegable Más acciones y, a continuación, confirme que se introduce el nombre de la base de datos en espera.
  7. Espere a que se complete la operación.

    El estado aparece en el menú Solicitudes de trabajo, en Recursos, a la izquierda.

  8. Inicie el servidor de administración secundario (o reinicie si ya se ha iniciado, por lo que los cambios de configuración que se han replicado mientras estaba en espera surten efecto).
  9. Inicie servidores gestionados secundarios (mediante la consola o los scripts de Oracle WebLogic Server).

Ejecución de un failover

Una operación de failover se realiza cuando el sitio principal deja de estar disponible y, por lo general, es una operación no planificada. Puede realizar la transición de roles de una base de datos en espera a una base de datos primaria cuando falle la base de datos primaria original y no haya posibilidad de recuperar la base de datos primaria en un tiempo.

Puede haber o no pérdida de datos, en función de si las bases de datos en espera principal y de destino eran consistentes en el momento del fallo de la base de datos primaria. Un procedimiento de failover es similar a un procedimiento de switchover, pero en su lugar realiza una operación de failover en la base de datos.

Normalmente, una operación de failover se ejecuta cuando una interrupción afecta a la región principal. Por lo tanto, puede haber algunas tareas que no puede realizar en la principal. Por ejemplo, puede que no pueda parar los procesos de Oracle WebLogic Server en la base de datos primaria porque no se puede acceder a los hosts.

  1. Si es posible, detenga los servidores WebLogic en el sitio principal.
  2. Switchover de nombres DNS.
  3. Failover de la base de datos.

    Note:

    Al utilizar Oracle Autonomous Database Serverless, el enlace de failover solo se muestra si la base de datos principal no está disponible y hay una base de datos en espera disponible. Con la API, puede iniciar un failover manual en cualquier momento
  4. Inicie los servidores en el sitio secundario.
  5. Una vez finalizada una operación de failover y que se pueda volver a acceder al sitio principal anterior, debe realizar las siguientes tareas manuales para preparar el sistema para un switchback futuro.
    1. Pare los procesos de Oracle WebLogic Server en el sitio con fallos.
      Si no los ha parado durante el failover, los procesos se pueden bloquear. Asegúrese de que se detienen.
    2. Para Oracle Autonomous Database Serverless, no es necesario volver a instanciar manualmente la principal con fallos.
      Después de un failover manual de Oracle Autonomous Data Guard, la base de datos en espera se vuelve a conectar automáticamente o, si es necesario, se vuelve a aprovisionar automáticamente (transparentemente) cuando la región vuelve a estar en línea.
      Consulte Notas sobre el failover manual con una base de datos en espera para obtener más información.
    3. En Oracle Autonomous Database on Dedicated Exadata Infrastructure, vuelva a instanciar la base de datos de contenedores con fallos a un rol en espera activado en la página Detalles.
      Después de un failover, el rol de la base de datos de contenedores en espera se convierte en principal y el rol de la base de datos de contenedores principal se convierte en base de datos en espera desactivada con el estado no disponible.
    4. Verifique la ejecución correcta de la réplica de configuración (de la nueva principal a la nueva en espera).