Una partícularidad (entre muchas) de las bases de datos Oracle RDS AWS al momento de crearlas es que se puede crear una base de datos de contingencia, simplemente con hacer un click… a continuación, algunos detalles de lo que comento.
Al momento de generar una base de datos Oracle RDS en AWS, se puede dar la opción de generarle una base de datos Standby Multizona (Multi AZ), es muy sencillo y solamente se debe seleccionar está pequeña cajita de control
Formato antiguo de RDS AWS
Formato nuevo de RDS AWS
Un gráfico sencillo de la solución
Algunas características de esta base Standby Multizona de AWS
- Failover Automático en caso de que la instancia primaria falle
- Replicación en Multi AZ provee alta disponibilidad y un soporte para las instancias de base de datos ante un Failover Automático
- Se demora algo así como 2 minutos en cambiar el servicio de un nodo a otro, pudiendo ser más de acuerdo a la cantidad de transacciones de la base de datos..
- Esta base de datos Standby no puede ser accedida ni leída cuando esté como Standby, si se requiere algo así, se le debe generar a la primaria una base llamada Read-Replica
- Una vez producido el Failover sobre nuestra Standby , debemos reconectar nuestros aplicativos, no hay traspaso de sesiones de forma natural.
A nivel de Oracle RDS Primaria, ¿qué podemos comentar?
Viendo la configuración de la base primaria con respecto a su Standby, nos podemos dar cuenta que no es a través de Dataguard, tampoco es a través de archivelogs, dado que la base de datos primaria está como FORCE LOGGING en NO, ¿entonces cómo es la replica? ¿cómo está configurada la Standby? debe ser una copia de Storage puesto que se traspasan todas las transacciones, de hecho así se ve reflejado en pruebas realizadas.
Hicimos una inserción de datos en modo NOLOGGING en nuestra primaria, por ende las instrucciones no se ven reflejadas en los archives y por ende no se deberían replicar en alguna Standby existente si esta fuese generada mediante los archives.
insert /*+ NOLOGGING */ into carga values (1);
Hacemos la consulta en nuestra primaria y aparecen todos los registros de la tabla, junto con el Hostname que contiene nuestra base de datos RDS
Si realizamos un reboot de nuestra instancia mediante consola, aparece el mensaje si procedemos con un Failover hacía nuestra «Standby»
Después de un par de minutos, vuelve nuestra conectividad (se pierde) y si volvemos a consultar las tablas que fueron insertadas con INSERT NOLOGGING, todos los registros se encuentran allí y nuestro HOST ha cambiado producto del Failover que realizamos.
Una vez efectuado el Failover , nuestra nueva instancia da servicio como Primaria y nuestra anterior base de datos primaria ahora es nuestra nueva Standby, o sea, podemos hacer nuevamente el proceso de Failover para devolvernos a la original base de datos primaria.
Me parece que cumple su objetivo, da Alta Disponibilidad y realizar un Failover de forma automática, sin perder transaccciones, no sé si el RPO sea del 100% no lo he encontrado en la documentación, pero el precio, características y servicio de la «Standby replica» de nuestro RDS cumple con el objetivo para el cual fue ideado.
¿el precio de todo lo implementado? Simplemente 57 dólares mensuales….
Espero les sirva y oriente 🙂
