IDUG Content Committee

 View Only

Conceptos Básicos de HADR

By Nidia Pichardo posted Oct 09, 2018 01:06 PM

  

Este artículo nos permitirá comprender los modos de sincronización existentes de HADR entre una base de datos primaria y secundaria. La segunda parte de éste documento describirá los parámetros que debemos modificar para configurar HADR. Así que comencemos por algunos conceptos básicos.

¿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 éstas bases de datos es SUPERASYNC, el cual explicaré mas adelante.

Dicho ésto, 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. 

 

¿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, tal como se muestra en la siguiente imágen.

pichardo-hadr-1.png 

 

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 fué 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, éste 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 éste 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, éste 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.

 

En resumen:

Alta Disponibilidad (HA): Dos servidores, en el mismo centro de datos, usualmente NEARSYNC con poca o ninguna pérdida de datos.

Recuperación de Desastres (DR): Dos servidores, centros de datos ubicados en diferentes puntos geográficos, usualmente SUPERASYNC con posible pérdida de datos según sea el propósito de la base de datos.

 


#espanol
0 comments
2 views

Permalink