Gestionar despliegues de peer

Utilice despliegues de peer para implantar su plan de recuperación ante desastres de OCI GoldenGate.

Nota: Este artículo solo se aplica a los despliegues de replicación de datos.

Acerca de los despliegues de peer

Un despliegue de peer es un recurso que se crea como base de datos en espera para el despliegue principal en caso de que se produzca un desastre o una interrupción del servicio. Incluye todos los mismos metadatos de despliegue principales, como archivos de pista y de parámetros, volúmenes en bloque y réplicas del servicio de almacenamiento de archivos. Un despliegue de peer puede ser local o remoto. Un igual local reside en la misma región que el despliegue primario, pero en un dominio de disponibilidad (AD) o dominio de errores (FD) diferente. Un par remoto reside en una región diferente.

Un despliegue primario solo puede tener un peer de despliegue local o entre regiones. Los despliegues de peer permiten cambiar del despliegue principal al despliegue en espera cuando sea necesario. Cuando realiza un switchover a un despliegue de peer, el despliegue de peer al que cambia se convierte en el principal.

Nota: Los despliegues de peer se facturan al mismo ratio que los despliegues principales. Obtén más información sobre la gestión y facturación de OCPU.

Al parar un despliegue primario, no se detiene el despliegue en espera, que se sigue facturando. Debe suprimir los despliegues en espera para evitar que se facturen.

Además, tenga en cuenta que no puede cambiar el tamaño del despliegue en espera, ya que debe seguir siendo el mismo tamaño que el primario.

Limitaciones

• Al crear despliegues de peer, la lista de regiones muestra las regiones remotas disponibles en las que puede crear una base de datos en espera entre regiones. Cuando se agrega una base de datos en reserva, la lista de regiones disponibles solo muestra una región remota si su arrendamiento está suscrito a la región remota (debe estar suscrito a la región remota emparejada).

• Para la recuperación ante desastres entre regiones, debe volver a configurar las rutas de distribución después de la operación de switchover y modificar el host de destino. Esto se puede hacer de dos formas:

  • (Para GoldenGate versión 23.10+ compilaciones) En la consola de despliegue de OCI GoldenGate, seleccione Servicio de distribución. Consulte la información de ruta de la ruta de distribución o la ruta de acceso iniciada por el destino y, a continuación, edite el URI de destino.

  • Utilice una llamada de API de REST para realizar la actualización:

    curl -u <username>:<password> -X PATCH https://<deployment-host>:443/services/v2/sources/<distribution-path-name> -d '{
       "target": {
       "uri": "wss://<new-target-deployment-host>:443/services/v2/targets?trail=<trail-name>"
       }
    }' \| jq .

  Nota: Si IAM se utiliza para la autenticación, también debe crear una nueva conexión de GoldenGate y asignarla al despliegue de origen.

• Los certificados del almacén de confianza de despliegue no se copian en el par en espera entre regiones y dos despliegues no pueden tener el mismo FQDN. Después de crear la base de datos en espera, debe actualizar la base de datos en espera con certs/clave SSL y actualizar el FQDN para el nuevo despliegue en línea con el nombre de dominio soportado en los certs. Puede que los certificados anteriores autofirmados generados para una región determinada no sean válidos para la región en espera, por lo que puede que tenga que volver a generarlos y cargarlos en el despliegue en espera.

Agregar un despliegue de peer

Antes de empezar

• Asegúrese de que ha agregado las políticas mínimas necesarias, específicamente políticas que permiten que los despliegues de GoldenGate utilicen la replicación de OCI Secrets y utilicen/gestionen recursos de OCI Secrets.

• Los secretos no se replican hasta que se activa la replicación entre regiones en el nivel de secretos. Asegúrese de seleccionar la misma región que el par en espera del despliegue. Obtenga información sobre la configuración de replicación de secretos entre regiones. Asegúrese de revisar "Permisos necesarios para que los principales de recursos permitan la replicación de secretos entre regiones" en la sección Política de IAM necesaria.

  • Si las conexiones asignadas no utilizan secretos, encontrará el siguiente error:

    Standby peer cannot be created as following connections does not use secret id <OCID>

  • Debe editar la conexión para utilizar secretos o sustituirla por uno que utilice secretos.

• Configure Active Data Guard o Data Guard en el nivel de base de datos antes de crear la conexión en OCI GoldenGate para asegurarse de que la cadena de conexión contiene tanto la información principal como la en espera. Si se configura después de crear la conexión, asegúrese de refrescar la conexión desde el menú Acciones de la página de detalles de la conexión.

Agregar un despliegue de peer a un despliegue principal:

1. En la página Detalles del despliegue principal, seleccione Recuperación ante desastres.

2. En la página Recuperación ante desastres, seleccione Agregar peer.

3. En el panel Add peer deployment:

   1. Seleccione la región en que desea crear el despliegue de peer.

      Nota: La lista de regiones solo muestra las regiones remotas disponibles en las que puede crear una base de datos en espera entre regiones.

   2. Para seleccionar automáticamente la mejor ubicación de dominio de disponibilidad:

      • Seleccione esta opción para que el servicio seleccione el dominio de disponibilidad y el dominio de errores en su nombre.

      • Anule la selección de esta opción para seleccionar el dominio de disponibilidad y el dominio de errores usted mismo.

4. Haga clic en Agregar.

El despliegue de peer aparece en la lista de la página de recuperación ante desastres, donde puede supervisar su estado hasta que se active.

Nota: Las conexiones asignadas con puntos finales dedicados se crean como puntos finales compartidos en la región en espera para que utilicen por defecto la subred y el punto final privado del despliegue. Si es necesario, puede editar las conexiones de la región en espera para utilizar puntos finales dedicados especificando manualmente la subred.

Switchover a un despliegue de peer

Aprenda a realizar un switchover de un despliegue de peer principal a un despliegue de peer en espera.

El switchover de un despliegue de peer principal a un despliegue de peer en espera es un proceso manual. El switchover asume que el par principal aún está disponible y realiza una última sincronización antes de iniciar el par en espera para garantizar que todos los metadatos y datos de la principal estén presentes en el par en espera. Asegúrese de suscribirse a los eventos de OCI GoldenGate necesarios para que se le informe de las actividades de despliegue relevantes.

Puede realizar el switchover desde la página de detalles del despliegue primario o desde la página de detalles del despliegue en espera entre regiones. Para cambiar a un despliegue de peer:

1. En la página Detalles del despliegue, seleccione Recuperación ante desastres.

2. En la lista de despliegue de peer de la página de recuperación ante desastres, en el menú Acciones del peer al que desea cambiar, seleccione Switchover.

3. En la ventana del cuadro de diálogo Switchover, confirme que desea cambiar a este par y, a continuación, seleccione Switch (Cambiar).

4. El estado del despliegue cambia a Actualizando mientras el switchover está en curso.

Cuando se completa el switchover, el par es ahora el principal y el principal se convierte en el par.

Nota: Si detecta que la base de datos en espera está detrás de la base de datos principal, consulte Extracción de la configuración en el cluster primario en la Tarea 10: Configuración de procesos de Oracle GoldenGate para conocer los parámetros para manejar las operaciones de switchover de la base de datos.

Failover en un despliegue de peer

Aprenda a realizar un failover de un despliegue de peer principal a uno en espera.

El failover utiliza el último punto de sincronización correcto para iniciar el par en espera y no intenta conectarse a la principal. Es posible que los procesos creados después de la última sincronización no estén presentes en el par en espera.

Puede realizar el switchover desde la página de detalles del despliegue primario o desde la página de detalles del despliegue en espera entre regiones. Para cambiar a un despliegue de peer:

1. En la página Detalles del despliegue, seleccione Recuperación ante desastres.

2. En la lista de despliegue de peer de la página de recuperación ante desastres, en el menú Acciones del peer al que desea cambiar, seleccione Failover.

3. En la ventana del cuadro de diálogo Failover, confirme que desea cambiar a este par y, a continuación, seleccione Failover.

4. El estado del despliegue cambia a Actualizando mientras el failover está en curso.

Cuando finaliza la conmutación por error, el par es ahora el principal y el principal se convierte en el par.

Nota: Si detecta que la base de datos en espera está detrás de la base de datos principal, consulte Extracción de la configuración en el cluster primario en la Tarea 10: Configuración de procesos de Oracle GoldenGate para conocer los parámetros para manejar las operaciones de switchover de la base de datos.

Ver detalles de despliegue de peer

Vea los detalles del despliegue de peer en el separador Disaster Recovery de la página de detalles de un despliegue primario.

La información de despliegue de peer que se muestra en esta página incluye:

• Rol (principal o en espera)
• Estado
• Región
• Dominio de disponibilidad
• Dominio de errores
• Estado de comprobación previa y fecha de la última ejecución
• Detalles de cambio de rol

En función de si el despliegue de peer es local o remoto, puede realizar las siguientes acciones desde el menú Actions (Acciones):

• Switchover
• Failover
• Iniciar comprobación previa (remota)
• Ver Resultados de Comprobación Previa (remota)
• Suprimir
• Copiar OCID

Ejecutar una comprobación previa de despliegue de peer

Debe ejecutar comprobaciones previas al despliegue de peer regularmente para garantizar el failover correcto o el switchover manual. La comprobación previa de despliegue de peer garantiza que los recursos que utilizan secretos de contraseña se replican en pares remotos antes de la operación de switchover. La comprobación previa incluye comprobaciones para:

• Existen secretos de contraseña
• Los secretos se replican en la región en espera
• El secreto de contraseña existe en la región en espera, pero no coincide con la región principal después de las actualizaciones recientes
• Todas las conexiones asignadas son válidas y existen varios hosts
• Existen conexiones asignadas, pero se deben actualizar debido a los cambios recientes

Si la comprobación previa falla por cualquier motivo, asegúrese de realizar las acciones necesarias y, a continuación, vuelva a ejecutar la comprobación previa.

Suprimir un despliegue de peer

Suprima un despliegue de peer cuando ya no sea necesario para detener los cargos adicionales recurrentes para los recursos no utilizados.

Para suprimir un despliegue de peer:

1. En la página Detalles del despliegue principal, seleccione Recuperación ante desastres.

2. En la lista de despliegue de peer, en el menú Acciones del peer que desea suprimir, seleccione Suprimir.

3. En la ventana del cuadro de diálogo Suprimir peer, confirme que desea suprimir este peer y, a continuación, seleccione Suprimir.

El estado del despliegue de peer cambia a Suprimiendo.