¿Qué es HADR?
«HADR» significa High Availability Disaster Recovery o Alta Disponibilidad y Recuperación de Desastres.
HADR es una característica de DB2 que replica datos en tiempo real desde una base de datos primaria hacia una o más bases de datos secundarias, también conocidas como standby. La base de datos primaria se encuentra abierta para lectura y escritura. Mientras que las bases de datos secundarias o standby pueden estar únicamente en modo lectura y se dividen en Standby Principal y Standby Auxiliar.
- Standby Principal: Es la base de datos en la que se va a aplicar el modo de sincronización que se haya configurado en el servidor primario. Sólo una base de datos puede ser Standby Principal a la vez, pero se puede rotar con otras bases de datos standby existentes en el cluster.
- Standby Auxiliar: Se le llama así a cualquier otra base de datos standby que no es Standby Principal. Se recomienda su configuración para Recuperación de Desastres (Disaster Recovery – DR). El modo de sincronización empleado para estas bases de datos es SUPERASYNC, el cual explicaré más adelante.
Dicho esto, alta disponibilidad se basa en duplicar el hardware y software de tal manera que, si algo le pasa a nuestro servidor principal, tendremos otro que puede asumir el paper de servidor primario, evitando así suspender el servicio a nuestros usuarios.
Alta disponibilidad también es muy útil en escenarios donde deseamos dar mantenimiento a nuestros servidores o a la base de datos sin afectar la disponibilidad de los sistemas. Por ejemplo, para aplicar parches al Sistema Operativo o actualizar la versión de la base de datos, el mantenimiento puede comenzar por los servidores secundarios. Posteriormente, movemos la base de datos principal hacia uno de los servidores auxiliaries, el cual se convertirá en el nuevo primario. Y por últmo, aplicamos parches al servidor que solía ser el primario.
¿Qué ofrece?
La recuperación ante desastres de alta disponibilidad (HADR) proporciona una solución de alta disponibilidad para fallas parciales y completas del sitio. HADR protege contra la pérdida de datos al replicar los cambios de datos desde una base de datos de origen, denominada base de datos principal, a las bases de datos de destino, denominadas bases de datos en espera. HADR admite hasta tres servidores remotos en espera.
Una falla parcial del sitio puede deberse a una falla de hardware, red o software (sistema de base de datos Db2® o sistema operativo). Sin HADR, una falla parcial del sitio requiere reiniciar el servidor del sistema de administración de bases de datos (DBMS) que contiene la base de datos. El tiempo que lleva reiniciar la base de datos y el servidor donde se encuentra es impredecible.
Pueden pasar varios minutos antes de que la base de datos vuelva a un estado coherente y esté disponible. Con HADR, una base de datos en espera puede hacerse cargo en segundos. Además, puede redirigir los clientes que usaron la base de datos principal original a la nueva base de datos principal mediante el redireccionamiento automático del cliente o la lógica de reintento en la aplicación.
Una falla completa del sitio puede ocurrir cuando un desastre, como un incendio, hace que todo el sitio quede destruido. Sin embargo, debido a que HADR usa TCP/IP para la comunicación entre las bases de datos principal y en espera, pueden ubicarse en diferentes ubicaciones. Por ejemplo, la base de datos principal podría estar en su oficina central en una ciudad y una base de datos en espera podría estar en su oficina de ventas en otra ciudad.
Si se produce un desastre en el sitio principal, la disponibilidad de los datos se mantiene haciendo que la base de datos en espera remota se convierta en la base de datos principal con la funcionalidad completa de Db2.
Después de que se produzca una operación de toma de control, puede recuperar la base de datos principal original y devolverla a su estado de base de datos principal; este procedimiento se conoce como conmutación por recuperación. Puede iniciar una conmutación por recuperación si puede hacer que la base de datos principal anterior sea coherente con la base de datos principal nueva.
Después de reintegrar la antigua base de datos principal en la configuración de HADR como base de datos en espera, puede cambiar las funciones de las bases de datos. Esta operación permitiría que la base de datos principal original vuelva a ser la base de datos principal.
¿Cómo mantener los servidores en sincronía?
Los servidores se mantienen en sincronía mediante el envío de logs del servidor primario al secundario.
Cabe señalar que los logs transferidos desde el servidor primario provienen del buffer de logs (Log Buffer), no de los archivos de logs.
El servidor primario contiene un buffer de envío de HADRasí como un buffer de logs y archivos de logs, mientras que el servidor secundario contiene un buffer de recepción de HADRasí como también un buffer de logs y archivos de logs.
Los logs serán enviados al servidor standby dependiendo el modo de sincronización que se elija. Es importante entender los modos de sincronización para tomar la decisión correcta antes de configurar HADR en nuestras bases de datos. Veamos que ocurre en cada uno de ellos.
- Modo SYNC (Síncrono)
En caso de un COMMIT, éste se considera exitoso únicamente cuando los logs se han escrito en disco en la base de datos primaria y secundaria.
Esto es lo que sucede a detalle. Cuando ocurre un COMMIT en la base de datos primaria, el buffer de envío de HADR en el servidor primario, manda las páginas de logs a través de la red hacia el buffer de recepción de HADR en el servidor secundario. El servidor secundario recibe los logs y los envía al buffer de logs. Finalmente los escribe en disco de la base de datos standby. Entonces, el servidor secundario envía una confirmación al servidor primario diciendo que la transacción fue escrita en disco. Posteriormente, la transacción es escrita en el buffer de logs del servidor primario, y finalmente en disco. Es aquí cuando el COMMIT se considera exitoso.
Como podemos observar, este escenario protege los datos al máximo. Sin embargo, podría impactar el desempeño de la base de datos debido a que estamos escribiendo dos veces a disco, y dependemos de la rapidez con la que responda la red.
Este modo de sincronización es recomendado para bases de datos que se encuentran en una distancia cercana, así como también para una red rápida. Lo cual quiere decir que es una buena opción para Alta Disponibilidad (HA – High Availability)
Modo NEARSYNC (Casi síncrono)
En este modo, los logs son escritos en disco en el servidor primario y de forma paralela se envían al servidor secundario. Cuando el buffer de recepción de HADR en el servidor secundario recibe los logs, éste envía una confirmación al servidor primario, antes de escribirlos en disco.
Noten que la base de datos no espera a que los logs sean escritos en el servidor secundario por lo que mejora el desempeño. Sin embargo, aún existe la dependencia de la red, por lo que se recomienda que las bases de datos se encuentren en una distancia corta. De igual forma, es recomendado para Alta Disponibilidad (HA). No para Recuperación de desastres (DR) debido a la dependencia en distancia geográfica.
Podría existir pérdida de datos en el caso de que perdamos los dos servidores, primario y secundario, al mismo tiempo. Que no podamos recuperar el servidor primario y que los logs existieran únicamente en la memoria del servidor secundario al momento de perder el servidor. Este escenario podría pasar muy remotamente por lo que muchos prefieren tomar el riesgo para incrementar desempeño.
Modo ASYNC (Asíncrono)
Los logs son escritos en disco en el servidor primario y de forma paralela se envían al servidor secundario. El servidor primario no espera a que el servidor secundario confirme si recibió los datos.
Se elimina la dependencia de la localidad geográfica e incrementa el desempeño. Sin embargo, en el caso de que se pierda el servidor primario existe un mayor riesgo de pérdida de logs que se encuentran en tránsito hacia el servidor secundario. Debido al riesgo, este modo de sincronización es más apropiado para recuperación de desastres (DR) donde solo se necesita la base de datos auxiliar en caso de perder nuestro centro de datos principal.
Modo SUPERASYNC (Super asíncrono)
Cuando ocurre un COMMIT, los logs se escriben a disco en la base de datos primaria y con eso se considera un COMMIT exitoso. No hay verificación de que los datos se enviaron a la base de datos auxiliar, por lo que desempeño no se ve impactado, pero el riesgo de pérdida de datos es alto.
Este modo es recomendado para recuperación de desastres (DR) cuando en tu configuración de HADR tienes un tercer o cuarto servidor.
