Gestionar despliegues de peer

Acerca de los despliegues de peer

Un despliegue de peer es un recurso que 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 igual 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.

Note:

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 versiones de GoldenGate versión 23.10+) 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 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 .
```
Note:
Si IAM se utiliza para la autenticación, también debe crear una nueva conexión 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, en concreto:

Cree un grupo dinámico que permita a los despliegues de GoldenGate acceder a los recursos de su arrendamiento:

name: <dynamic-group-name>
Matching rule: ALL {resource.type = 'goldengatedeployment', resource.compartment.id = '<location>'}

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.
- Si las conexiones asignadas no utilizan secretos, se producirá 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.

Agregue políticas que permitan que los despliegues de GoldenGate utilicen la replicación de OCI Secrets y utilicen/gestionen recursos de OCI Secrets:

Allow dynamic-group '<IAM Domain>'/'<dynamic-group-name>' to use secret-replication in tenancy
Allow dynamic-group '<IAM Domain>'/'<dynamic-group-name>' to manage secrets in tenancy
Allow dynamic-group '<IAM Domain>'/'<dynamic-group-name>' to use vaults in tenancy
Allow dynamic-group '<IAM Domain>'/'<dynamic-group-name>' to use keys in tenancy
Allow dynamic-group '<IAM Domain>'/'<dynamic-group-name>' to use tag-namespaces in tenancy

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 primaria 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.

Para agregar un despliegue de peer a un despliegue principal:

En la página Detalles del despliegue principal, seleccione Recuperación ante desastres.
En la página Recuperación ante desastres, haga clic en Agregar peer.
En el panel Add peer deployment:
1. Seleccione la región en que desea crear el despliegue de peer.
  
  Note:
  La lista de regiones solo muestra las regiones remotas disponibles en las que puede crear una base de datos en espera entre regiones.
2. En Seleccione 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.
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.

Cambiar 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 primario a un despliegue de peer es un proceso manual. Asegúrese de suscribirse a los eventos GoldenGate de OCI necesarios para mantenerse informado 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:

En la página Detalles del despliegue, seleccione Recuperación ante desastres.
En la lista de despliegue de peer de la página Recuperación de fallos, en el menú Acciones del peer al que desea cambiar, seleccione Switchover.
En la ventana de diálogo Switchover, confirme que desea cambiar a este par y, a continuación, haga clic en Cambiar.
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.

Note:

Si descubre que la base de datos en espera está detrás de la base de datos principal, consulte Extracción de configuración en el cluster principal 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.

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:

En la página Detalles del despliegue principal, seleccione Recuperación ante desastres.
En la lista de despliegue de peer, en el menú Acciones del peer que desea suprimir, seleccione Suprimir.
En la ventana de diálogo Suprimir peer, confirme que desea suprimir este peer y, a continuación, haga clic en Suprimir.

El estado del despliegue de peer cambia a Suprimiendo.