Failover y Recuperación de Sitios

Se necesita una conmutación por error de sitio si la infraestructura ha sufrido un evento no planificado que hace que el sitio principal no esté disponible y sea completamente inaccesible durante un período de tiempo que afectará negativamente al negocio. En este escenario, la base de datos en espera asume el rol principal.

Un sitio principal puede dejar de estar disponible por una variedad de razones, incluidas, entre otras, las siguientes:

Problemas que pueden provocar que las instancias de la base de datos primaria no se inicien, como un medio con fallos o corrupto en gran medida, o una actualización de firmware o sistema operativo con fallos
Fallo de la infraestructura, como una interrupción completa de la alimentación o del sistema de refrigeración en la infraestructura de la región de OCI
Fallos de red completos
Desastres naturales como terremotos, incendios e inundaciones

Si bien los eventos no planificados son raros, pueden ocurrir y ocurren.

Realización de un failover de sitio

Como un verdadero failover provoca interrupciones y puede provocar una pequeña pérdida de datos, pruebe el failover del sitio en un entorno TEST.

En el siguiente ejemplo se utilizan nombres de nuestro entorno de prueba para la base de datos primaria en Ashburn (CDBHCM_iad1dx) y la base de datos en espera en Phoenix (CDBHCM_phx5s).

Forzar una parada de todas las instancias de base de datos de Oracle Real Application Clusters (Oracle RAC) en la base de datos principal.

Note:
No realice esta prueba en un entorno de producción.
```
$ srvctl stop database -db CDBHCM_iad1dx -stopoption
        abort
```
A partir de este momento, se supone que nuestra primaria (simulada) no está completamente disponible. Haremos de nuestra región secundaria nuestro nuevo sitio primario.
Los siguientes pasos utilizan nuestra implementación de prueba y todos los pasos se realizan en el sitio secundario (nuevo principal).

En el sitio secundario, conéctese a cualquiera de Oracle Exadata Database Service on Dedicated Infrastructure domUs, conviértase en el usuario del sistema operativo oracle y llame a la interfaz de línea de comandos de Data Guard Broker.

Nodo: Oracle Exadata Database Service on Dedicated Infrastructure domU
Usuario: oracle

$ dgmgrl sys/sys password
DGMGRL> show configuration lag

Configuration - fsc

  Protection Mode: MaxPerformance
  Members:
  CDBHCM_iad1dx  - Primary database
    Error: ORA-12514: TNS:listener does not currently know of service requested in connect descriptor
  CDBHCM_phx5s - Physical standby database 
                    Transport Lag:      0 seconds (computed 18 seconds ago)
                    Apply Lag:          0 seconds (computed 18 seconds ago)

Fast-Start Failover:  Disabled

Configuration Status:
ERROR   (status updated 0 seconds ago)

Observe el error.

Realice un failover mediante la interfaz de línea de comandos de Oracle Data Guard Broker.
- Nodo: Oracle Exadata Database Service on Dedicated Infrastructure domU en el sitio secundario
- Usuario: oracle
```
DGMGRL> failover to CDBHCM_phx5s
```
Si las capas medias primarias (incluido el sistema de archivos compartido) siguen intactas, realice manualmente un rsync "forzado" desde el sitio principal fallido hasta el sitio de DR.

Es posible que las capas web y de aplicación sigan funcionando, pero los procesos del programador de procesos y aplicaciones comenzarán a fallar al intentar conectarse a la base de datos con fallos. Esto hará que el script rsync deje de realizar rsync.
- Nodo: una capa media, sitio principal con fallos
- Usuario: psadm2
1. Realice un rsync forzado. Hay disponible una secuencia de comandos rsync_psft.sh de ejemplo en el directorio de secuencias de comandos.
  Si el script rsync está desactivado, el parámetro -f solicitará que continúe con un rsync forzado. Un rsync forzado no consultará la base de datos para determinar el rol del sitio y, a continuación, realizará el rsync solicitado.
  
  Note:
  Esto solo se debe hacer cuando se fuerza un refrescamiento final durante un failover del sitio. Se registra el uso de la opción FORCE.
```
$ rsync_psft.sh path to file system/parameter file -f
```
  Por ejemplo,
```
$ rsync_psft.sh $SCRIPT_DIR/fs1 -f
```
2. Supervise el log de proceso rsync para verificar que el proceso se completa correctamente.
Si se ha completado el fallo del sitio y no se puede ejecutar un proceso rsync final, desactive rsync en la nueva base de datos primaria ejecutando el script disable_psft_rsync.sh.
- Nodo: una capa media, nuevo sitio principal
- Usuario: psadm2
```
disable_psft_rsync.sh
```
Si ha configurado el soporte de Active Data Guard al configurar los servidores de base de datos principal y en espera, asegúrese de que el servicio de Active Data Guard para PeopleSoft (PSQUERY) se ha iniciado en la nueva base de datos principal.
- Nodo: Oracle Exadata Database Service on Dedicated Infrastructure domU en el sitio secundario
- Usuario: oracle
```
$ srvctl status service -db CDBHCM_phx5s -s PSQUERY
Service PSQUERY is running on instance(s) CDBHCM1,CDBHCM2
```
Este servicio se debe ejecutar en todas las instancias de Oracle Real Application Clusters (Oracle RAC).

Note:
Este servicio se debe iniciar antes de iniciar el gestor de procesos. De lo contrario, el programador de procesos fallará al iniciar.
Verifique que los servicios de base de datos basados en roles estén activos en la nueva base de datos primaria.
- Sitio: sitio 2
- Nodo: todo Oracle Exadata Database Service on Dedicated Infrastructure domUs
- Usuario: oracle
Por ejemplo, emita el siguiente comando en cada domU que aloje una instancia de base de datos Oracle RAC PeopleSoft:
```
$ srvctl status service -db CDBHCM_phx5s -s HR92U033_BATCH
Service HR92U033_BATCH is running on instance(s) CDBHCM1,CDBHCM2
$ srvctl status service -db CDBHCM_phx5s -s HR92U033_ONLINE
Service HR92U033_ONLINE is running on instance(s) CDBHCM1,CDBHCM2
```
Este servicio debe ejecutarse en todas las instancias de Oracle RAC.

Inicie el servidor de aplicaciones y los dominios del programador de procesos.

Sitio: sitio 2
Nodo: instancias informáticas del servidor del programador de procesos y aplicaciones
Usuario: psadm2

Conéctese a las instancias informáticas que alojan los servidores de aplicaciones y el programador de procesos PeopleSoft y conviértase en psadm2.
Utilice el script startPSFTAPP.sh del directorio Wrapper en GitHub.
```
$ startPSFTAPP.sh
```

Supervise el inicio.

Puede utilizar la consulta de los dominios del programador de procesos y la aplicación PeopleSoft.

col service_name format a20
select a.inst_id,a.instance_name,b.service_name, count(*)
from gv$instance a, gv$session b
where a.inst_id = b.inst_id
and service_name not like 'SYS%'
group by a.inst_id,a.instance_name,b.service_name
order by 1

SQL> /

   INST_ID INSTANCE_NAME    SERVICE_NAME          COUNT(*)
---------- ---------------- ------------------- ----------
         1 CDBHCM1          CDBHCM_phx5s                 2
SQL> /

   INST_ID INSTANCE_NAME    SERVICE_NAME          COUNT(*)
---------- ---------------- ------------------- ----------
         1 CDBHCM1          CDBHCM_phx5s                2
         1 CDBHCM1          HR92U033_BATCH               8
         1 CDBHCM1          HR92U033_ONLINE             52
         2 CDBHCM2          HR92U033_BATCH               7
         2 CDBHCM2          HR92U033_ONLINE             50

Si no ha tenido un fallo completo del sitio, como se describe en el paso 5, vaya al paso siguiente. Si ha producido un fallo completo en el sitio, debe volver a ejecutar el script disable_psft_rsync.sh, ya que el script startPSTAPP.sh activará rsync.
Note:

En un evento de fallo real en el que el sitio principal se pierde o se vuelve inaccesible, deberá realizar una evaluación del alcance y el impacto. Aquí hay algunos elementos a considerar:
- Posible pérdida de datos de base de datos
- Faltan artefactos del sistema de archivos (informes, logs, archivos entrantes y salientes, etc.)
En función de la interrupción, es posible que pueda recuperar o no todas las transacciones confirmadas en la principal original. Si es posible, pida a los usuarios que verifiquen las últimas transacciones en las que estaban trabajando.

Es probable que falten artefactos del sistema de archivos, desde la salida que se escribe o se transmite cuando cesa el acceso a la primaria original. Utilice el registro de informes en la base de datos para identificar los artefactos del sistema de archivos creados cerca de la hora de la interrupción y, a continuación, determine qué se debe hacer, caso por caso, para los archivos faltantes o incompletos.
Iniciar servicios web.
- Sitio: sitio 2
- Nodo: todas las instancias informáticas del servidor web de arquitectura de Internet (PIA) PeopleSoft
- Usuario: psadm2
Si Coherence*Web está configurado, primero iniciará el cluster de caché en todas las instancias informáticas que alojan los servidores web de PIA y, a continuación, iniciará los servidores web de PIA. En este ejemplo, se utiliza un script para iniciar ambos en el orden correcto.
1. Inicie sesión en los servidores web de PIA y conviértase en psadm2.
2. Con el script de startPSFTAPP.sh, inicie los servidores web.
```
$ startPSFTWEB.sh
```
Compruebe el equilibrador de carga.
- Sitio: región de sitio 2
- Nodo: consola de OCI
- Usuario: administrador del arrendamiento
1. Conéctese a la consola de OCI y cambie la región a la nueva principal.
2. Seleccione Red y, a continuación, Equilibrador de carga en el menú principal.
3. Seleccione el compartimento adecuado.
4. Haga clic en Juego de backends y, a continuación, en Backends.
  Cada backend debe mostrar Aceptar. Puede tardar unos minutos después de que se haya iniciado cada servidor web de PIA.

Volver a instanciar la principal fallida como la nueva en espera

Desea proteger el nuevo entorno de producción con una base de datos en espera. Lo ideal es que pueda volver a instanciar la base de datos primaria con fallos como nueva base de datos en espera. Para ello, vuelva a instanciar tanto la base de datos como los sistemas de archivos.

Volver a instanciar la antigua base de datos primaria como base de datos en espera

Oracle Data Guard evitará que la antigua base de datos primaria se abra cuando vuelva a estar disponible después de un fallo en la ubicación primaria. Cualquier intento de iniciar la base de datos normalmente fallará, con mensajes escritos en su log de alertas que indican que es necesario volver a instanciar. Si el flashback de base de datos estaba activado en esta base de datos antes del fallo, puede volver a instanciar la base de datos primaria antigua como la nueva base de datos en espera.

Realice lo siguiente para volver a instanciar la base de datos primaria antigua como base de datos en espera de la producción actual:

Conéctese a uno de los domUs que alojan la antigua base de datos primaria e inicie la base de datos:
```
$ srvctl start database -db CDBHCM_phx5s
```

Conéctese a la interfaz de línea de comandos de Data Guard Broker en la nueva región principal y muestre la configuración.

Observe el error ORA-16661 en negrita a continuación.

$ dgmgrl sys/sys password
DGMGRL> show configuration
configuration - fsc

  Protection Mode: MaxPerformance
  Members:
  CDBHCM_iad1dx - Primary database
    CDBHCM_phx5s  - Physical standby database (disabled)
      ORA-16661: the standby database needs to be reinstated

Fast-Start Failover:  Disabled

Configuration Status:
SUCCESS   (status updated 12 seconds ago)

Vuelva a instanciar la base de datos en espera.
```
DGMGRL> REINSTATE DATABASE CDBHCM_phx5s;
```
Note:
El proceso de recuperación de la base de datos con fallos y creación de una base de datos en espera válida se inicia y puede tardar un tiempo en completarse.
Utilice la interfaz de línea de comandos de Data Guard Broker para comprobar el estado del entorno.
Por ejemplo,
```
DGMGRL> show configuration lag

Configuration - fsc

  Protection Mode: MaxPerformance
  Members:
  CDBHCM_iad1dx - Primary database
    CDBHCM_phx5s  - Physical standby database 
                    Transport Lag:      0 seconds (computed 1 second ago)
                    Apply Lag:          0 seconds (computed 1 second ago)

Fast-Start Failover:  Disabled

Configuration Status:
SUCCESS   (status updated 35 seconds ago)
```
La base de datos rehabilitada ahora sirve como base de datos en espera, protegiendo la base de datos primaria y disponible para switchover y failover.

Si ha configurado el soporte de Active Data Guard al configurar los servidores de base de datos principal y en espera, el servicio de Active Data Guard para PeopleSoft (PSQUERY) se puede reubicar de la base de datos principal a la base de datos en espera.

Volver a instanciar los niveles medios primarios antiguos como base de datos en espera

Vuelva a instanciar las capas medias primarias antiguas según el evento de failover.

Si los servidores de capa media primaria antiguos permanecen disponibles mientras se produce el evento de failover de la base de datos, debe haber realizado un rsync forzado final de la ubicación primaria con fallos a la base de datos en espera en el momento del fallo y, a continuación, invertido la dirección de los procesos rsync de la misma forma que cuando realiza un switchover.

Es posible que las capas web y de aplicación sigan funcionando, pero los procesos del programador de procesos y aplicaciones comenzarán a fallar al intentar conectarse a la base de datos con fallos. Esto hará que el script rsync deje de realizar rsync.
1. Si las capas medias primarias, incluido el sistema de archivos compartido, siguen intactas, realice manualmente una rsync "forzada" del sitio principal fallido al sitio de DR.
  Si el script rsync está desactivado, el parámetro -f solicitará que continúe con un rsync forzado. Una rsync forzada no consultará la base de datos para determinar el rol del sitio y, a continuación, realizará la rsync solicitada.
  
  Note:
  Esto solo se debe hacer cuando se fuerza un refrescamiento final durante un failover del sitio. Se registrará el uso de la opción FORCE.
  
  Puede utilizar el script de ejemplo en el directorio de scripts rsync_psft.sh, como usuario psadm2:
```
$ rsync_psft.sh path to file system/parameter file -f
```
  Por ejemplo,
```
$ rsync_psft.sh $SCRIPT_DIR/fs1 -f
```
2. Supervise el log de proceso rsync para verificar que el proceso se completa correctamente.
Si el sitio principal antiguo es completamente inaccesible incluso para rsync, realice lo siguiente:
1. Desactive las secuencias de comandos rsync en el nuevo sitio principal con disable_psft_rsync.sh para todos los sistemas de archivos que se replican.
2. Si puede reanudar la actividad en las capas medias originales más adelante, vuelva a activar los scripts rsync y deje que se pongan al día.
Si necesita volver a crear las capas medias, siga los procesos descritos anteriormente.