Documentación de Oracle Cloud Infrastructure

Comprobaciones previas realizadas por recuperación ante desastres de pila completa

La recuperación ante desastres de pila completa realiza comprobaciones previas de recursos como grupos de protección de DR, planes de DR y ejecuciones de planes de DR.

Comprobaciones previas para la instancia informática

La DR de pila completa primero realiza las siguientes comprobaciones previas de almacenamiento para cada máquina virtual presente en el DRPG principal. La DR de pila completa verifica que:
  • La replicación de grupo de volúmenes se configura o la copia de seguridad se configura con una política de copia de seguridad y la copia entre regiones está activada.
  • Existe una réplica de grupo de volúmenes o al menos una copia de seguridad de grupo de volúmenes en la región en espera. También pueden existir varias copias de seguridad, ya que Full Stack DR utiliza la última copia de seguridad del grupo de volúmenes.
  • Todos los volúmenes de inicio y en bloque de las máquinas virtuales de los miembros de un DRPG se agregan al grupo de volúmenes.
  • El grupo de volúmenes contiene solo los volúmenes de inicio y en bloque asociados a la VM de los miembros en un DRPG.
  • Si el usuario está intentando agregar instancias informáticas en movimiento a un grupo de protección de DR en espera, lo cual no está permitido.

Comprobaciones previas del sistema de archivos:

Full Stack DR realiza primero las siguientes comprobaciones previas para el sistema de archivos:
  • Switchover/Failover/Iniciar cambio de nivel:
    • Valida que el sistema de archivos de origen tenga el estado Activo y que se deba exportar el sistema de archivos
    • Valida que el sistema de archivos de origen no debe tener una clave de cifrado personalizada
    • Valida que toda la exportación presente en el sistema de archivos de origen está asignada al destino de montaje de destino como parte de la propiedad de miembro del sistema de archivos y debe ser única (evite la duplicación)
    • Valida que hay al menos una configuración de política de replicación activa en el sistema de archivos de origen
    • Valida que la propiedad de miembro del sistema de archivos dominio de disponibilidad de destino esté en la región peer
    • Valida que todos los destinos de montaje de destino configurados para las exportaciones del sistema de archivos de origen estén en la región peer y estén en el mismo dominio de disponibilidad que la propiedad de miembro dominio de disponibilidad de destino.
    • Valida que el sistema de archivos de destino tenga el estado Activo y que sea un sistema de archivos no exportado
    • Valida que al menos una instantánea de replicación debe estar presente en el sistema de archivos de destino
    • Valida que los destinos de montaje de destino tengan activado el protocolo TCP/UDP correcto. Consulte Configuración de reglas de seguridad de VCN para File Storage.
    • Valida el OCID en la política de instantánea de destino de propiedad de miembro del sistema de archivos.
    • Valida que la política de instantánea de destino en la propiedad de miembro del sistema de archivos exista y tenga un estado de ciclo de vida Activo.
    • Valida que el almacén de destino y la clave de cifrado de destino en la propiedad de miembro del sistema de archivos exista y tenga un estado de ciclo de vida Activo.
    • Valida que la clave de cifrado de destino en la propiedad de miembro del sistema de archivos sea una clave de cifrado AES simétrica (estándar de cifrado avanzado) y tenga un estado de ciclo de vida Activado.
  • Parar detalle
    • Valida que el sistema de archivos exportado clonado esté presente para la limpieza
    • Valida que las exportaciones están presentes en el sistema de archivos exportado clonado para su limpieza

Comprobaciones previas para el sistema de archivos de montaje/desmontaje en una instancia de Compute:

Full Stack DR realiza primero las siguientes comprobaciones previas para el sistema de archivos de montaje/desmontaje en la instancia informática:
  • Validaciones para la propiedad de miembro de detalle de montaje/desmontaje:
    • Detalles de montaje:
      • Valida que el destino de montaje de los detalles de montaje coincida con la región en espera.
      • Valida que la combinación de punto de montaje y exportación sea única (evite el montaje múltiple en el mismo punto de montaje).
    • Detalles de desmontaje:
      • Valida que el destino de montaje de los detalles de desmontaje coincida con la región principal.
      • Valida que la ruta de exportación esté presente en el destino de montaje de los detalles de desmontaje.
    • Valida que la instancia informática móvil/no móvil y el destino de montaje de los detalles de montaje tengan activado el protocolo TCP/UDP correcto. Consulte Configuración de reglas de seguridad de VCN para File Storage.
    • Valida la instancia informática móvil/no móvil; el grupo de protección de DR principal debe tener el sistema de archivos montable o el destino de montaje de destino debe tener la ruta de exportación correcta para el montaje.
    • Nota

      Para un failover, se realiza la siguiente comprobación en el paso Sistema de archivos: montaje en instancia informática con la instancia informática recién iniciada debido a la falta de disponibilidad de la región principal

    • Valida que la instancia informática tenga activado el plugin Compute Instance Run Command.
    • Valida que la instancia informática tenga acceso raíz:
    • Solo para el sistema operativo Linux, valida que la instancia informática tenga instalado nfs-client. Para obtener información sobre cómo instalar nfs-client en recursos informáticos, consulte Mounting File Systems From UNIX-Style Instances.
    • Solo para el sistema operativo Linux, valide que /etc/fstab en el sistema operativo linux debe tener detalles de montaje presentes con la dirección IP de destino de montaje correcta/nombre de dominio completo y punto de montaje.
    • Para ambos sistemas operativos, valide que el punto de montaje esté presente en la instancia informática

Comprobaciones previas para grupos de volúmenes (almacenamiento de bloques)

La DR de pila completa primero realiza las siguientes comprobaciones previas para todos los grupos de volúmenes agregados al DRPG principal. La DR de pila completa verifica que:
  • El grupo de volúmenes tiene el estado Available.
  • El grupo de volúmenes tiene copias de seguridad o replicación configuradas en la región en espera. Si ambos están configurados, la recuperación ante desastres de pila completa utiliza réplicas e ignora las copias de seguridad.
  • Para la DR entre regiones, las réplicas de regiones de destino (en espera) no se encuentran en el mismo dominio de disponibilidad (AD).
  • La réplica de la región en espera tiene el estado Available o, si se utilizan copias de seguridad, existe al menos una copia de seguridad y es Available.
  • La lista de volúmenes del grupo de volúmenes de origen coincide con la lista de volúmenes de la réplica o la copia de seguridad de la región en espera.
  • La política de copia de seguridad de destino es una política de copia de seguridad válida.
  • El almacén y la clave de cifrado proporcionados en Clave de destino común son válidos.
  • El almacén proporcionado en Clave de destino común tiene un estado de ciclo de vida Activo.
  • La clave de cifrado proporcionada en Clave de destino común tiene un estado de ciclo de vida Activada
  • El volumen de origen, el almacén de destino y la clave de cifrado proporcionados en Asignaciones de clave de cifrado de volumen de origen a destino son válidos.
  • Se proporciona Clave de destino común o Clave de cifrado de volumen de origen a destino Asignaciones, no se pueden proporcionar ambas propiedades de miembro.

Comprobaciones previas de volumen en bloque para instancias informáticas no movibles

La recuperación ante desastres de pila completa primero realiza las siguientes comprobaciones previas para el volumen en bloque para instancias informáticas no móviles:

Si la instancia informática se agrega como miembro a un DRPG con el rol Principal, realice las siguientes validaciones para cada ID de volumen en bloque proporcionado en la nueva lista de propiedades de miembro:
  • El ID de volumen en bloque debe ser un OCID válido de un volumen en bloque.
  • El volumen en bloque no debe tener duplicados en las propiedades de miembro de la misma instancia informática.
  • El volumen en bloque ya debe estar asociado a la instancia informática.
  • El volumen en bloque debe formar parte de algún miembro del grupo de volúmenes del DRPG.
  • Si se proporciona un ID de instancia de referencia de asociación de volumen en los detalles de asociación, esa instancia debe ser miembro del grupo de protección de DR en espera y el ID de volumen en bloque se debe agregar en sus propiedades de miembro.
  • Si no se proporciona el ID de instancia de referencia de asociación de volumen en los detalles de asociación, solo una instancia informática del DRPG en espera debe tener una propiedad de miembro definida con este ID de volumen en bloque.
  • Los puntos de montaje que se definen deben ser únicos.
Si la instancia informática se agrega como miembro a un DRPG con el rol En espera, realice las siguientes validaciones para cada ID de volumen en bloque proporcionado en la nueva lista de propiedades de miembro:
  • El ID de volumen en bloque debe ser un OCID válido de un volumen en bloque.
  • El volumen en bloque no debe tener duplicados en las propiedades de miembro de la misma instancia informática.
  • El volumen en bloque debe ser de la región del DRPG principal.
  • El volumen en bloque debe formar parte de algún miembro del grupo de volúmenes del DRPG principal.
  • El dominio de disponibilidad de destino/destino del grupo de volúmenes (donde se activará la copia de seguridad o la réplica) debe coincidir con el dominio de disponibilidad de esta instancia informática en espera.
  • Si se proporciona un ID de instancia de referencia de asociación de volumen en los detalles de asociación, esa instancia de peer debe ser miembro del DRPG principal y el volumen en bloque debe estar asociado a él.
  • Si no se proporciona el ID de instancia de referencia de asociación de volumen en los detalles de asociación, solo una instancia informática del DRPG principal debe tener el volumen en bloque asociado.
  • Los puntos de montaje que defina deben ser únicos.
  • No se deben configurar dos volúmenes en bloque para asociarse mediante la misma ruta de dispositivo.
  • Si la asociación utiliza rutas de dispositivo, las rutas de dispositivo no deben estar en uso.
  • Si un volumen en bloque está configurado para asociarse a más de una instancia informática, la asociación debe tener acceso para compartir.

Comprobaciones previas para Object Storage con Switchover y Failover

Full Stack DR realiza las siguientes comprobaciones previas para el almacenamiento de objetos:

  • switchover:

    • Cubo de almacenamiento de objetos - Comprobación previa de supresión de replicación (principal)

      • Valida que el cubo de origen esté presente.

      • Valida que la política de replicación esté presente.

      • Valida que la política de replicación debe estar en la región peer.

    • Cubo de Object Storage: comprobación previa de configuración de replicación inversa (en espera)

      • Valida que el cubo de destino está presente

      • Valida que el cubo de origen esté presente

  • Failover:

    • Cubo de almacenamiento de objetos - Comprobación previa de supresión de replicación (principal)

      • Valida que el cubo de origen tenga el estado Activo.

      • Valida que la política de replicación esté presente.

      • Valida que la política de replicación debe estar en la región peer.

      • Valida que el cubo de destino tenga el estado Activo.

    • Cubo de almacenamiento de objetos - Comprobación previa de configuración de replicación inversa (en espera) (Continuar tras error)

      • Valida que el cubo de destino esté presente.
      • Valida que el cubo de origen esté presente.

Comprobaciones previas de la base de datos (Oracle Base Database Service, Oracle Exadata Database Service on Dedicated Infrastructure, Oracle Exadata Database Service on Exascale Infrastructure, Oracle Exadata Database Service on Cloud@Customer)

Full Stack DR realiza las siguientes comprobaciones previas si un miembro de la base de datos (Oracle BaseDatabase Service, Oracle Exadata Database Service on Dedicated Infrastructure, Oracle Exadata Database Service on Exascale Infrastructure, Oracle Exadata Database Service on Cloud@Customer) forma parte del DRPG. Full Stack DR verifica que:
  • Las propiedades de miembro de base de datos no están vacías ni son nulas y la ubicación del almacén secreto de contraseñas forma parte de las propiedades de miembro de base de datos.
  • Puede acceder al almacén secreto en el que la contraseña de la base de datos está almacenada y la base de datos peer está en estado Available.
  • La base de datos y la base de datos peer tienen Data Guard activado y son pares de Data Guard entre sí.
  • La base de datos y la base de datos peer tienen los roles de Data Guard correctos.
  • La base de datos y la base de datos peer forman parte de los dos grupos de protección de DR asociados que forman parte de la configuración. La base de datos primaria forma parte del grupo de protección de DR principal y la base de datos en espera forma parte del grupo de protección de DR en espera.

Comprobaciones previas de Oracle Autonomous Database Serverless

Full Stack DR realiza las siguientes comprobaciones previas si un miembro de Autonomous Database Serverless forma parte del DRPG. Full Stack DR verifica que:
  • Las propiedades de miembro de la base de datos autónoma no están vacías ni son nulas.
  • La base de datos autónoma principal no tiene una lista de bases de datos en espera vacía.
  • La base de datos autónoma en espera no está en la misma región que la región de la base de datos principal y no es un peer local.
  • La base de datos autónoma y la base de datos autónoma peer forman parte de los dos grupos de protección de DR asociados que forman parte de la configuración.
  • Remote Data Guard está configurado.
  • La base de datos peer remota pertenece al DRPG remoto.
  • El estado del ciclo de vida de la base de datos primaria es AVAILABLE.

    Para las comprobaciones previas del switchover, Full Stack DR realiza las siguientes validaciones adicionales en la base de datos en espera: verifica que la base de datos en espera del peer remoto tenga el estado correcto (STANDBY).

  • Si el almacén y la clave de cifrado proporcionados en Clave de cifrado de destino son válidos.
  • El ID de almacén en Clave de cifrado de destino tiene el estado de ciclo de vida Activo.
  • El ID de cifrado de Clave de cifrado de destino tiene el estado de ciclo de vida Activado.

Comprobaciones previas de Oracle Autonomous Container Database

Full Stack DR realiza las siguientes comprobaciones previas si un miembro de la base de datos de contenedores autónoma forma parte del DRPG. Full Stack DR verifica que:
  • Las propiedades del miembro de la base de datos de contenedores autónoma no están vacías ni son nulas.
  • La base de datos de contenedores autónoma principal no tiene una lista de bases de datos en espera vacía.
  • La base de datos autónoma y la base de datos autónoma peer forman parte de los dos grupos de protección de DR asociados que forman parte de la configuración.
  • Remote Data Guard está configurado.
  • La base de datos peer remota pertenece al DRPG remoto.
  • Los estados del ciclo de vida de la base de datos de contenedores autónoma principal y en espera son AVAILABLE.

    Para las comprobaciones previas del switchover, Full Stack DR realiza las siguientes validaciones adicionales en la base de datos en espera: verifica que la base de datos en espera del peer remoto tenga el estado correcto (STANDBY).

Comprobaciones previas de Kubernetes Engine (OKE)

Full Stack DR realiza las siguientes comprobaciones previas para Kubernetes Engine (OKE).

Cluster Primario
  1. Comprueba la conexión al cluster primario.
  2. Comprueba si la copia de seguridad tiene más de un día de antigüedad.
  3. Descarga e imprime el log de copia de seguridad.
  4. Valida que el estado del ciclo de vida del cluster de OKE principal sea Activo.
  5. Valida que el espacio de nombres y el cubo de las propiedades del miembro principal existan y sean válidos.
  6. Valida que el programa de copia de seguridad en las propiedades del miembro principal tenga el formato RFC 5545.
    • Valida la parte de regla no soportada.
    • Valida el rango de cada parte de regla.
  7. Valida la asignación del equilibrador de carga en las propiedades del miembro principal para las siguientes restricciones.
    • SourceLoadBalancerId y DestinationLoadBalancerId tienen OCID de LOADBALANCER.
    • La asignación del equilibrador de carga debe ser única.
      • A-B, C-B -> No permitido
      • A-B, A-D -> No permitido
        Nota

        Por ejemplo, si tiene un juego de dos equilibradores de carga en la región principal (como load_balancer_A and load_balancer_C). Tiene otro juego de dos equilibradores de carga en la región en espera (como load_balancer_B and load_balancer_D). Por lo tanto, al agregar un cluster de OKE como miembro, debe agregar la propiedad de asignaciones del equilibrador de carga. En esta asignación, solo se permite la siguiente asignación: 
        load_balancer_A <--> load_balancer_B & load_balancer_C <--> load_balancer_D 
or load_balancer_C <--> load_balancer_B & load_balancer_A <--> load_balancer_D
        . Sin embargo, no se permiten las siguientes asignaciones, ya que load_balancer_B está definido como equilibrador de carga de destino en ambas asignaciones: 
        load_balancer_A <--> load_balancer_B & load_balancer_C <--> load_balancer_B
  8. Valida la asignación del equilibrador de carga de red en las propiedades del miembro principal para las siguientes restricciones.
    • SourceNetworkLoadBalancerId y DestinationNetworkLoadBalancerId tienen OCID de NETWORKLOADBALANCER.
    • La asignación del equilibrador de carga de red debe ser única.
      • A-B, C-B -> No permitido
      • A-B, A-D -> No permitido
        Nota

        Por ejemplo, si tiene un juego de dos equilibradores de carga de red en la región principal (como network_load_balancer_A and network_load_balancer_C). Tiene otro juego de dos equilibradores de carga de red en la región en espera (como network_load_balancer_B and network_load_balancer_D). Por lo tanto, al agregar un cluster de OKE como miembro, debe agregar la propiedad de asignaciones del equilibrador de carga de red. En esta asignación, solo se permite la siguiente asignación: 
        network_load_balancer_A <--> network_load_balancer_B & network_load_balancer_C <--> network_load_balancer_D 
or network_load_balancer_C <--> network_load_balancer_B & network_load_balancer_A <--> network_load_balancer_D
  9. Valida la asignación de almacén en las propiedades de miembro principal para las siguientes restricciones.
    • SourceVaultId y DestinationVaultId tienen OCID de VAULT.
    • La asignación de almacén debe ser única.
      • A-B, C-B -> No permitido.
      • A-B, A-D -> No permitido.
        Nota

        Por ejemplo, si tiene un juego de dos almacenes en la región principal (como vault_A and vault_C). Tiene otro juego de dos almacenes en la región en espera (como vault_B and vault_D). Por lo tanto, al agregar un cluster de OKE como miembro, debe agregar la propiedad de asignaciones de almacén. En esta asignación, solo se permite la siguiente asignación: 
        vault_A  <--> vault_B & vault_C <--> vault_D 
or vault_C <--> vault_B & vault_A <--> vault_D
  10. Valida que el ID de cluster de peer y la ubicación de copia de seguridad de las propiedades de miembro principal no estén vacíos.
  11. Valida el host Jump en las propiedades de miembros principales para las siguientes restricciones.
    • El grupo de protección de DR debe contener una instancia informática con el mismo OCID que el host de salto.
    • El host de salto debe ser una instancia informática no móvil.
    • El host de salto debe tener el estado de ciclo de vida RUNNING.
  12. Valida el ID de cluster de peer en las propiedades de miembro principal para las siguientes restricciones.
    • Valida que el grupo de protección de DR de peer tenga un cluster con ID de cluster de peer.
    • Valida que el cluster miembro en sí no se agrega como cluster peer.
    • Valida que el cluster de peer proporcionado en las propiedades de miembro no se agregue como cluster de peer para el otro cluster de OKE en el grupo de protección de DR.
  13. Valida los pools de nodos en el cluster de OKE de la región principal para las siguientes restricciones.
    • Valida que el recuento de nodos en todos los pools de nodos sea al menos uno.
    • Valida que haya al menos un nodo activo en todos los pools de nodos.
    • Ejemplo: si hay dos pools de nodos, un nodo no tiene ningún nodo activo, pero otro tiene un nodo activo, esto daría como resultado una excepción.
  14. Valida el ID de equilibrador de carga de origen en las propiedades de miembro principal para las siguientes restricciones.
    • El ciclo de vida debe estar activo.
    • El equilibrador de carga solo puede tener una subred regional.
  15. Valida el ID del equilibrador de carga de red de origen en las propiedades del miembro principal para las siguientes restricciones.
    • El ciclo de vida debe estar activo.
    • El equilibrador de carga de red solo puede tener una subred regional.
  16. Valida que el ID de almacén de origen en las propiedades del miembro principal esté activo.
  17. Valida la configuración del pool de nodos gestionado en las propiedades del miembro principal para las siguientes restricciones.
    • El tipo de miembro debe ser MANAGED.
    • El ciclo de vida debe ser ACTIVO.
    • La suma del recuento de nodos ('máximo' en la configuración de nodos gestionados o el recuento de nodos existente, el que sea mayor) para todos los pools de nodos del cluster no debe superar el límite.
  18. Valida la configuración del pool de nodos virtuales en las propiedades del miembro principal para las siguientes restricciones.
    • El tipo de miembro debe ser VIRTUAL.
    • El ciclo de vida debe ser ACTIVO.
    • La suma del recuento de nodos ('máximo' en la configuración de nodos virtuales o el recuento de nodos existente, el que sea mayor) para todos los pools de nodos del cluster no debe superar el límite.

Cluster en espera

  1. Comprueba si los espacios de nombres forman parte de la copia de seguridad.
  2. Comprueba si todos los volúmenes en bloque a los que se hace referencia en los volúmenes persistentes forman parte del grupo de protección de DR.
  3. Comprueba si todos los sistemas de archivos/destinos de montaje a los que se hace referencia en volúmenes persistentes forman parte del grupo de protección de DR.
  4. Comprueba si todos los equilibradores de carga a los que se hace referencia en la clase de entrada forman parte del grupo de protección de DR.
  5. Comprueba si todos los almacenes a los que se hace referencia en secretproviderclasses forman parte del grupo de protección de DR.
  6. Comprueba si las definiciones de recursos personalizados son compatibles con la versión de cluster en espera.
  7. Valida que el estado del ciclo de vida del cluster de OKE en espera sea Activo.
  8. Valida que el ID de cluster de peer y la ubicación de copia de seguridad de las propiedades de miembro en espera no deben estar vacíos.
  9. Valida el host Jump en las propiedades de miembros en espera para las siguientes restricciones.
    • El grupo de protección de DR debe contener una instancia informática con el mismo OCID que el host de salto.
    • El host de salto debe ser una instancia informática no móvil.
    • El host de salto debe tener el estado de ciclo de vida RUNNING.
  10. Valida el ID de cluster de peer en las propiedades de miembros en espera para las siguientes restricciones.
    • Valida que el grupo de protección de DR de peer tenga un cluster con ID de cluster de peer.
    • Valida que el cluster miembro en sí no se agrega como cluster peer.
    • Valida que el cluster de peer proporcionado en las propiedades de miembro no se agregue como cluster de peer para otro cluster de OKE en el grupo de protección de DR.
  11. Valida el ID del equilibrador de carga de destino en las propiedades del miembro principal para las siguientes restricciones.
    • El ciclo de vida debe estar activo.
    • El equilibrador de carga solo puede tener una subred regional.
  12. Valida el ID de equilibrador de carga de red de destino en las propiedades de miembro principal para las siguientes restricciones.
    • El ciclo de vida debe estar activo.
    • El equilibrador de carga de red solo puede tener una subred regional.
    • Valida que el ID de almacén de destino en las propiedades del miembro principal esté activo.
  13. Valida la configuración del pool de nodos gestionado en las propiedades de miembros en espera para las siguientes restricciones.
    • El tipo de miembro debe ser MANAGED.
    • El ciclo de vida debe estar activo.
    • La suma del recuento de nodos ('máximo' en la configuración de nodos gestionados o el recuento de nodos existente, el que sea mayor) para todos los pools de nodos del cluster no debe superar el límite.
  14. Valida la configuración del pool de nodos virtuales en las propiedades del miembro en espera para las siguientes restricciones.
    • El tipo de miembro debe ser VIRTUAL.
    • El ciclo de vida debe estar activo.
    • La suma del recuento de nodos ('máximo' en la configuración de nodos virtuales o el recuento de nodos existente, el que sea mayor) para todos los pools de nodos del cluster no debe superar el límite.
  15. Valida los pools de nodos en el cluster de OKE de la región en espera para las siguientes restricciones.
    • Valida que el recuento de nodos en todos los pools de nodos sea al menos uno.
    • Valida que haya al menos un nodo activo en todos los pools de nodos.
  16. Valida que el pool de nodos del cluster de destino debe tener al menos un nodo en cada AD donde se restaurará FSS/Block.
  17. Valida las reglas securityList y NSG definidas en el grupo de seguridad de subred/red de los pools de nodos y los pools de nodos virtuales proporcionados en el cluster garantizando que se definan las siguientes reglas.
    • Reglas de entrada con estado
      • los puertos TCP 111, 2048, 2049 y 2050, y
      • Puertos UDP 111 y 2048
    • Reglas de salida con estado
      • Puertos de origen TCP 111, 2048, 2049 y 2050, y
      • Puerto de origen UDP 111.
        Nota

        La validación solo se aplica si el cluster de OKE tiene PV o PVC para el sistema de archivos. Full Stack DR verifica solo los siguientes escenarios:
        • Escenario A: el destino de montaje y la instancia están en distintas subredes (recomendado).
        • Escenario B: el destino de montaje y la instancia están en la misma subred.
          Full Stack DR no verifica los siguientes escenarios:
          • Escenario C: El destino de montaje y la instancia utilizan cifrado en tránsito TLS.
          • Escenario D: el destino de montaje utiliza LDAP para la autorización.

Comprobaciones previas para el sistema de base de datos MySQL HeatWave

Full Stack DR realiza las siguientes comprobaciones previas para el sistema de base de datos MySQL:

  • Switchover:
    • Valida que los estados del ciclo de vida de los sistemas de base de datos de MySQL HeatWave principales y en espera tengan el estado Activo.
    • Valida que el sistema de base de datos de destino esté presente en el grupo de protección de DR peer como miembro, que también tiene la propiedad del sistema de base de datos de destino que coincide con el OCID del sistema de base de datos MySQL principal.
    • Valida que el sistema de base de datos MySQL principal esté en modo de lectura/escritura.
    • Valida que el sistema de base de datos MySQL de destino esté en modo de solo lectura.
    • Valida que el secreto de almacén del sistema de base de datos MySQL principal proporcionado para el usuario de administración y replicación tenga el estado Disponible.
    • Valida que el secreto de almacén del sistema de base de datos MySQL en espera proporcionado para el usuario de administración y replicación tenga el estado Disponible.
    • Valida que haya un canal activo entre el sistema de base de datos MySQL primario y el sistema de base de datos MySQL de destino.
      Nota

      En caso de fallo, Full Stack DR muestra una advertencia.
    • Valida la conectividad entre la instancia de contenedor y los nodos de base de datos MySQL.
    • Valida que la ejecución de GTID esté presente para los sistemas de base de datos principal y de destino.
  • Failover:
    • Valida que el estado del ciclo de vida del sistema de base de datos MySQL en espera tenga el estado Activo.
    • Valida que el sistema de base de datos de destino esté presente en el grupo de protección de DR peer como miembro, que también tiene la propiedad del sistema de base de datos de destino que coincide con el OCID del sistema de base de datos MySQL principal.
    • Valida que el sistema de base de datos MySQL de destino está en modo de lectura.
    • Valida que el secreto de almacén del sistema de base de datos MySQL en espera proporcionado para el usuario de administración y replicación tenga el estado Disponible.
    • Valida que haya un canal activo entre el sistema de base de datos MySQL primario y los sistemas de base de datos MySQL de destino.
    • Valida la conectividad entre la instancia de contenedor y ambos nodos de base de datos MySQL.
    • Valida que la ejecución de GTID esté presente para los sistemas de base de datos principal y de destino.
  • Iniciar detalle:
    • Valida que el estado del ciclo de vida del sistema de base de datos MySQL tanto para el sistema de base de datos principal como en espera tenga el estado Activo.
    • Valida que el sistema de base de datos de destino esté presente en el grupo de protección de DR peer como miembro, que también tiene la propiedad del sistema de base de datos de destino que coincide con el OCID del sistema de base de datos MySQL principal.
    • Valida que el sistema de base de datos MySQL primario esté en modo de lectura/escritura.
    • Valida que el sistema de base de datos MySQL de destino está en modo de lectura.
    • Valida que la copia de seguridad esté presente en el sistema de base de datos MySQL de destino que se va a restaurar.
    • Valida que haya un canal activo entre el sistema de base de datos MySQL primario y los sistemas de base de datos MySQL de destino.
  • Detener detalle:

    Valida que la base de datos MySQL restaurada está presente en la región peer para que se limpie.

Tema principal: Referencia