Grandes de Bases de Datos Alta disponibilidad Envío de bitácoras Introducción Envío de bitácoras • Funcionamiento BD 1 Datos 2 Registro 3 Sentencia UPDATE Árbol de consulta Analizador Consultas Plan Optimizador Ejecutor Consultas Motor Relacional UPDATE Cliente SET nombre = ‘H’ SNI WHERE id = 1; Capa protocolos SNI ¿? Plan cache Registro transacciones Datos Medio físico D D D Administrador Transacciones Métodos de acceso Motor de almacenamiento Data cache Administrador Buffer Buffer Pool Sentencia UPDATE Árbol de consulta Analizador Consultas Plan Optimizador Ejecutor Consultas Motor Relacional UPDATE Cliente SET nombre = ‘H’ SNI WHERE id = 1; Capa protocolos SNI Plan cache Registro transacciones DatosD Medio físico Administrador Transacciones Métodos de acceso Motor de almacenamiento Data cache Administrador Buffer Buffer Pool Sentencia UPDATE UPDATE Cliente SET nombre Tj = ‘H’ WHERE id = 1; <Tj start> <Tj work> … <Tj commit> Registro transacciones DatosD Medio físico Administrador Transacciones Métodos de acceso Motor de almacenamiento Administrador Buffer Arquitectura de bitácoras MDF – NDF: datos LDF – bitácora de transacciones VLF 1 T1: BEGIN T1: COMMIT VLF 2 VLF 3 VLF 4 VLF 5 Arquitectura de bitácoras MDF – NDF: datos LDF – bitácora de transacciones VLF 1 T1: BEGIN T1: COMMIT VLF 2 VLF 3 VLF 4 VLF 5 Arquitectura de bitácoras VLF 1 VLF 2 VLF 3 VLF 4 VLF 5 Sin usar Inicio lógico del archivo Último checkpoint Min LSN Fin lógico del archivo Arquitectura de bitácoras Min LSN Max LSN VLF 1 LSN1 T1 BEG LSN2 T1 UPD Inicio lógico del archivo VLF 2 LSN3 T1 COM LSN4 T2 BEG LSN5 T2 INS LSN6 T3 BEG LSN7 T3 UPD VLF 3 LSN8 T3 COM LSN9 T4 BEG Último checkpoint Log activo LSN 10 CKP Sin usar Fin lógico del archivo Arquitectura de bitácoras VLF 2 VLF 1 Sin usar VLF 3 Sin usar VLF 4 VLF 5 Sin usar Truncados Último checkpoint Min LSN Inicio lógico del archivo Fin lógico del archivo Arquitectura de bitácoras VLF 2 VLF 1 Sin usar VLF 3 VLF 4 VLF 5 Sin usar Truncados Fin lógico del archivo Último checkpoint Min LSN Inicio lógico del archivo Envío de bitácoras • Funcionamiento BD - Idea general – Las peticiones que modifican datos se registran primero en un archivo de transacciones (log) – Técnica WAL (Write ahead log) – Una vez guardadas en el registro, los datos se propagan otro lugar de almacenamiento estable → archivo de datos Envío de bitácoras • Idea general – ¿Qué sucede si se tienen 2 bases de datos iguales y se aplica el mismo archivo de transacciones en ambas? Datos Datos Registro Registro Envío de bitácoras • Idea general – ¿Qué sucede si se tienen 2 bases de datos iguales y se aplica el mismo archivo de transacciones en ambas? Datos Datos Registro Registro Servidor A Servidor B Envío de bitácoras • Detalles generales – Múltiples copias – Conmutación manual Envío de bitácoras • Detalles específicos – Alcance a nivel de base de datos – Base de datos accesible sólo en lectura – Los usuarios deben finalizar sesión para que se aplique el siguiente log – Los respaldos no bloquean los respaldos del log Envío de bitácoras • Funcionamiento Datos Datos Registro Registro Envío de bitácoras • Términos – Servidor primario – Base de datos primaria Datos Registro Envío de bitácoras • Términos – Servidor secundario – Base de datos secundaria Datos Datos Registro Registro Envío de bitácoras • Términos – Servidor monitor Datos Datos Registro Registro Envío de bitácoras • Términos – Tarea de respaldo Datos Datos Registro Registro Envío de bitácoras • Términos – Tarea de copiado Datos Datos Registro Registro Envío de bitácoras • Términos – Tarea de restauración Datos Datos Registro Registro Envío de bitácoras • Términos – Tarea de alerta Datos Datos Registro Registro Envío de bitácoras • Funcionamiento – Un equipo determina el archivo de registro a realizar. – Se genera un respaldo del archivo de registro. – Se envía a otro equipo. – El nuevo equipo aplica el último archivo de registro en su base de datos local, dejando la base de datos en modo de espera. Envío de bitácoras • Conmutación por error – Restaurar el mayor número de archivos de registro con la opción WITH NORECOVERY. – Restaurar el último archivo de registro con la opción WITH RECOVERY. – Verificar permisos de conexión. – Inicializar cualquier tarea programada pendiente. – Direccionar las aplicaciones a la nueva IP instancia Envío de bitácoras • Conmutación contraria controlada - razones – Contratos y servicios dictan ejecución en un equipo en particular – Los equipos difieren y existe degradación en el desempeño Envío de bitácoras • Conmutación contraria controlada – Restaurar un respaldo completo en el servidor “principal”. – Restaurar el último archivo de registro con la opción WITH RECOVERY. – Verificar permisos de conexión. – Inicializar cualquier tarea programada pendiente. – Direccionar las aplicaciones a la IP – instancia original Envío de bitácoras • Ambientes donde se recomienda aplicar – Se necesita un control estable entre los servidores primario y secundarios. – No es necesario una conmutación automática. – Es necesaria una replicación adicional de otro ambiente de HA. – Se necesitan múltiples servidores secundarios. Envío de bitácoras • Ambientes donde se recomienda aplicar – Son necesarios servidores para reportes. Envío de bitácoras • Consideraciones – Velocidad de red. – Desempeño de servidores. – Capacidad de almacenamiento. – Ubicación del monitor. Envío de bitácoras • Consideraciones de diseño – Seguridad. • Especificar los roles adecuados (nivel de dominio). – Modo de recuperación. – Lugar de almacenamiento. • Servidores externos – Lugar intermedio. • Servidores externos – Servidor de monitoreo. Envío de bitácoras • Consideraciones de diseño – Ambiente a nivel de base de datos. • Hay bases de sistema que contienen información relevante. – Identificar si existe dependencias entre bases de datos. – Tiempo de promedio de pérdida de datos • 2 veces el tiempo de recuperación de los registros, por ejemplo: 5 minutos de respaldos → 10 minutos de pérdida de datos