Switchover y Failover con DataGuard Broker en Oracle 19c
Introduccion
En una nota previa revisamos cómo realizar un Switchover en Oracle DataGuard 19c usando comandos de Oracle. Esta vez vamos a realizar el Switchover y pasar por los procesos de Failover y Reinstate usando el DataGuard Broker.
Prerrequisitos
Estamos usando un ambiente DataGuard con una instancia Primaria y una Standby Física en Oracle 19c multitenant con una base de datos pluggable. Para más información sobre cómo crear un ambiente DataGuard favor de revisar Crear una Standby Física de Oracle DataGuard.
También necesitamos que este ambiente DataGuard esté configurado para DataGuard Broker. Para mas información en como se hace esto favor de revisar Configurar el DataGuard Broker en Oracle 19c.
Switchover
Se hace un Switchover al intercambiar los roles de las instancias participantes en un ambiente DataGuard como se describe en la documentación:
Durante un switchover, la base de datos primaria transiciona a un role de standby, y la base de datos standby transiciona al rol primario.
Un switchover garantiza que no haya pérdida de datos y se hace típicamente para mantenimientos planeados en el sistema primario.
Acceder al DataGuard Broker
Envía el comando dgmgrl en la instancia Primaria para acceder al DataGuard Broker, entonces contéctate a la base de datos con el usuario SYSDG:
[oracle@patodgprmy ~]$ dgmgrl
DGMGRL for Linux: Release 19.0.0.0.0 - Production on Thu Jul 29 20:41:37 2020
Version 19.3.0.0.0
Copyright (c) 1982, 2019, Oracle and/or its affiliates. All rights reserved.
Welcome to DGMGRL, type "help" for information.
DGMGRL> connect sysdg
Password:
Connected to "prmydb"
Connected as SYSDG.
Alternativamente se puede usar el usuario
SYSsi no se ha configurado un usuario para el DataGuard en el archivo orapwd.
Validar que las Bases de Datos estén Preparadas para el Switchover
Primero tenemos que validar que ambas bases de datos estén preparadas para el proceso de Switchover, enviando el comando validate database:
DGMGRL> validate database prmydb
Database Role: Primary database
Ready for Switchover: Yes
Managed by Clusterware:
prmydb: NO
Validating static connect identifier for the primary database prmydb...
The static connect identifier allows for a connection to database "prmydb".
DGMGRL> validate database stbydb
Database Role: Physical standby database
Primary Database: prmydb
Ready for Switchover: Yes
Ready for Failover: Yes (Primary Running)
Managed by Clusterware:
prmydb: NO
stbydb: NO
Validating static connect identifier for the primary database prmydb...
The static connect identifier allows for a connection to database "prmydb".
Como ambas bases de datos se muestran como Ready for Switchover: Yes entonces podemos proceder.
Realizar el Switchover
Enviamos el comando switchover to indicando la base de datos que queremos que sea la nueva Primaria:
DGMGRL> switchover to stbydb
Performing switchover NOW, please wait...
Operation requires a connection to database "stbydb"
Connecting ...
Connected to "stbydb"
Connected as SYSDG.
New primary database "stbydb" is opening...
Operation requires start up of instance "prmydb" on database "prmydb"
Starting instance "prmydb"...
Connected to an idle instance.
ORACLE instance started.
Connected to "prmydb"
Database mounted.
Connected to "prmydb"
Switchover succeeded, new primary is "stbydb"
Entonces revisamos los nuevos roles enviando el comando show configuration:
DGMGRL> show configuration
Configuration - dgpato
Protection Mode: MaxPerformance
Members:
stbydb - Primary database
prmydb - Physical standby database
Fast-Start Failover: Disabled
Configuration Status:
SUCCESS (status updated 43 seconds ago)
DGMGRL>
Como podemos ver la instancia stbydb es ahora la base de datos Primaria y la instancia prmydb es ahora la Standby Física,
los roles se han intercambiado por lo tanto el Switchover fue exitoso.
Failover
En un ambiente DataGuard cuando la instancia Primaria falla necesitas pasar por los procesos de Failover y Reinstate con el fin de restaurar el servicio de la base de datos, como se describe en la documentación;
Se mueve una base de datos Standby al rol de Primaria en respuesta a una falla en la base de datos Primaria.
Si el Flashback está habilitado en la base de datos Primaria se puede restablecer como una Standby para la nueva bases de datos Primaria una vez que se haya corregido la causa de la falla.
Para este ejercicio hemos detenido la instancia Primaria y su listener.
Acceder al DataGuard Broker
Envía el comando dgmgrl en la instancia Standby para acceder al DataGuard Broker, entonces contéctate a la base de datos con el usuario SYSDG:
[oracle@patodgstby ~]$ dgmgrl
DGMGRL for Linux: Release 19.0.0.0.0 - Production on Thu Jul 29 21:36:11 2020
Version 19.3.0.0.0
Copyright (c) 1982, 2019, Oracle and/or its affiliates. All rights reserved.
Welcome to DGMGRL, type "help" for information.
DGMGRL> connect sysdg
Password:
Connected to "stbydb"
Connected as SYSDG.
Validar que la Standby está Preparada para el Failover
Primero tenemos que validar que la base de datos Standby está preparada para el proceso de Failover, enviando el comando validate database:
DGMGRL> validate database stbydb
Database Role: Physical standby database
Primary Database: prmydb
Warning: primary database was not reachable
Ready for Switchover: No
Ready for Failover: Yes (Primary Not Running)
Flashback Database Status:
prmydb: Unknown
stbydb: On
Managed by Clusterware:
prmydb: Unknown
stbydb: NO
Validating static connect identifier for the primary database prmydb...
Unable to connect to database using (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=10.20.0.10)(PORT=1521))(CONNECT_DATA=(SERVICE_NAME=prmydb_DGMGRL)(INSTANCE_NAME=prmydb)(SERVER=DEDICATED)(STATIC_SERVICE=TRUE)))
ORA-12541: TNS:no listener
Failed.
Warning: Ensure primary database's StaticConnectIdentifier property
is configured properly so that the primary database can be restarted
by DGMGRL after switchover
Temporary Tablespace File Information:
prmydb TEMP Files: Unknown
stbydb TEMP Files: 3
Data file Online Move in Progress:
prmydb: Unknown
stbydb: No
Transport-Related Information:
Transport On: No
Gap Status: Unknown
Transport Lag: 0 seconds (computed 351 seconds ago)
Transport Status: Success
Log Files Cleared:
prmydb Standby Redo Log Files: Unknown
stbydb Online Redo Log Files: Unknown
stbydb Standby Redo Log Files: Unknown
DGMGRL>
De la salida podemos ver que no hay información disponible de la Primaria ya que ha fallado.
Como la base de datos Standby está marcada como Ready for Failover: Yes (Primary Not Running) entonces podemos proceder.
Realizar el Failover
Enviamos el comando failover to indicando la base de datos que queremos que sea la nueva Primaria:
DGMGRL> failover to stbydb
Performing failover NOW, please wait...
Failover succeeded, new primary is "stbydb"
DGMGRL>
Entonces podemos revisar si el Failover funcionó enviando el comando show configuration:
DGMGRL> show configuration
Configuration - dgpato
Protection Mode: MaxPerformance
Members:
stbydb - Primary database
prmydb - Physical standby database (disabled)
ORA-16661: the standby database needs to be reinstated
Fast-Start Failover: Disabled
Configuration Status:
SUCCESS (status updated 11 seconds ago)
El Failover fue exitoso ya que podemos ver que la instancia stbydb es ahora la base de datos Primaria.
La instancia prmydb (que aún está en estatus fallido) queda marcada como una potencial Standby Física que necesita ser reestablecida.
Reinstate
Cuando la falla en la instancia Primaria original haya sido arreglada, necesitamos restablecer esta base de datos para que pueda regresar a funcionar como parte de esta configuración de DataGuard.
Primero tenemos que iniciar con startup mount la instancia arreglada:
[oracle@patodgprmy trace]$ sqlplus / as sysdba
SQL*Plus: Release 19.0.0.0.0 - Production on Thu Jul 29 21:42:30 2020
Version 19.3.0.0.0
Copyright (c) 1982, 2019, Oracle. All rights reserved.
Connected to an idle instance.
SQL> startup mount
ORACLE instance started.
Total System Global Area 1610609888 bytes
Fixed Size 9135328 bytes
Variable Size 1023410176 bytes
Database Buffers 570425344 bytes
Redo Buffers 7639040 bytes
Database mounted.
SQL>
Luego en la instancia Primaria actual (Standby original) accedemos al DataGuard Broker y nos conectamos a la base de datos con el usuario SYSDG:
[oracle@patodgstby trace]$ dgmgrl
DGMGRL for Linux: Release 19.0.0.0.0 - Production on Thu Jul 29 21:43:16 2020
Version 19.3.0.0.0
Copyright (c) 1982, 2019, Oracle and/or its affiliates. All rights reserved.
Welcome to DGMGRL, type "help" for information.
DGMGRL> connect sysdg
Password:
Connected to "STBYDB"
Connected as SYSDG.
Entonces podemos enviar el comando reinstate database indicando la base de datos que estuvo en estatus fallido:
DGMGRL> reinstate database prmydb
Reinstating database "prmydb", please wait...
Reinstatement of database "prmydb" succeeded
DGMGRL>
Finalmente podemos revisar si el Reinstate funcionó enviando el comando show configuration:
DGMGRL> show configuration
Configuration - dgpato
Protection Mode: MaxPerformance
Members:
stbydb - Primary database
prmydb - Physical standby database
Fast-Start Failover: Disabled
Configuration Status:
SUCCESS (status updated 45 seconds ago)
Como podemos ver la instancia stbydb es aún la base de datos Primaria pero ahora la instancia prmydb es la Standby Física,
entonces el proceso de Reinstate fue exitoso.
Switchback
Como paso final despues de un Failover/Reinstate hay que regresar a los roles originales en este ambiente DataGuard.
Entonces necesitamos hacer los mismos pasos que revisamos en la sección previa para el Switchover, pero esta vez apuntando hacia la base de datos prmydb:
Validar que las Bases de Datos estén Preparadas para el Switchover
DGMGRL> validate database stbydb
Database Role: Primary database
Ready for Switchover: Yes
Managed by Clusterware:
stbydb: NO
Validating static connect identifier for the primary database stbydb...
The static connect identifier allows for a connection to database "stbydb".
DGMGRL> validate database prmydb
Database Role: Physical standby database
Primary Database: stbydb
Ready for Switchover: Yes
Ready for Failover: Yes (Primary Running)
Managed by Clusterware:
stbydb: NO
prmydb: NO
Validating static connect identifier for the primary database stbydb...
The static connect identifier allows for a connection to database "stbydb".
Realizar el Switchover
DGMGRL> switchover to prmydb
Performing switchover NOW, please wait...
Operation requires a connection to database "prmydb"
Connecting ...
Connected to "prmydb"
Connected as SYSDG.
New primary database "prmydb" is opening...
Operation requires start up of instance "stbydb" on database "stbydb"
Starting instance "stbydb"...
Connected to an idle instance.
ORACLE instance started.
Connected to "stbydb"
Database mounted.
Connected to "stbydb"
Switchover succeeded, new primary is "prmydb"
Entonces revisamos los nuevos roles enviando el comando show configuration:
DGMGRL> show configuration
Configuration - dgpato
Protection Mode: MaxPerformance
Members:
prmydb - Primary database
stbydb - Physical standby database
Fast-Start Failover: Disabled
Configuration Status:
SUCCESS (status updated 49 seconds ago)
Como podemos ver la instancia prmydb es ahora la base de datos Primaria y la instancia stbydb es ahora la Standby Física,
entonces los roles han sido regresados a los originales exitosamente.
Conclusión
Hemos realizado exitosamente un Switchover y un Failover en nuestro ambiente DataGuard en Oracle 19c multitenant. Podemos ver que el DataGuard Broker facilita el proceso y validación del intercambio de roles cuando te enfrentas a un escenario de mantenimiento o falla en un ambiente DataGuard.