Database Mirroring

Objetivos

Implementando Database Mirroring

Contenido

Lección 1: Resumen de Database Mirroring
Lección 2: Inicialización Database Mirroring
Lección 3: Diseño de conmutación por error y conmutación por recuperación Estrategias

Lección 1: Resumen de Database Mirroring

1. Funciones de base de reflejo
2.  Los puntos finales Database Mirroring 
3. Modos de funcionamiento 
4. Almacenamiento en caché 
5. Transparent Client Redirect 
6. Database Mirroring Roscado 
7. Las instantáneas de base de datos 
8. Prácticas

Roles de base de datos Espejo

Puede configurar un servidor testigo opcional para cada sesión, y una sola
servidor testigo puede gestionar varias sesiones de creación de reflejo de base de datos.
  

Rol Principal

La base de datos que se configura en el papel principal se convierte en la fuente de todas las transacciones en una sesión de creación de reflejo de la base de datos

Rol Espejo 

• La base de datos que se define en la función de reflejo es el socio de base de datos de la base de datos principal y recibe continuamente las transacciones.
•  Constantemente reproducir transacciones de la base de datos principal en el registro de transacciones y el lavado diario de las transacciones de los archivos de datos en la base de datos reflejada.
• La base de datos espejo está en un estado de recuperación. 
• Puede crear una instantánea de base de datos contra una base de datos reflejada. 
• Base de datos puede asumir el papel de principal o espejo en cualquier momento.  

 Servidor Testigo

• El único propósito del testigo es el de servir como un árbitro dentro del modo operativo de alta disponibilidad para asegurar que la base de datos se puede servir en una sola instancia de SQL Server a la vez.
•  La base de datos espejo puede tomar el papel principal y hacer que sus datos estén disponibles para los usuarios.
•  Un servidor testigo puede dar servicio a múltiples pares de reflejo de base de datos.

EndPoints

• Todo el tráfico de Database Mirroring se transmite a través de un Endpoint TCP con una carga útil de DATABASE_MIRRORING (puerto 5022).
•  Sólo se puede crear un extremo de reflejo de la base de datos por cada instancia de SQL Server. 
• La comunicacion del Endpoint puede ser encriptada o no encriptada.

Modos de Operación

Alta Disponibilidad

Detección de fallos y conmutación por error automática siga los siguientes pasos generales:

1. El director y el espejo continuamente ping entre sí
2. El testigo periódicamente pings tanto el principal y el espejo
3. El director de la falla
4. El espejo detecta el fallo y hace una petición a la testigo para promocionarse a la base de datos principal.
5. El testigo no puede hacer ping a la principal, pero puede hacer ping al espejo, por lo que el testigo está de acuerdo con el cambio de roles, y SQL Server promueve el espejo con el director.
6. El servidor principal vuelve a la línea de la falla y detecta que el espejo ha sido ascendido a director.
7. SQL Server degrada el capital original a un espejo, y las transacciones comience a fluir a esta base de datos para sincronizar con el nuevo director.

Alto Rendimiento

Alta Seguridad 

Cuando manualmente la conmutación por error en el modo de alta seguridad de funcionamiento:

1. SQL Server 2008 se desconectan todas las conexiones de la base de datos principal.
2. Cambia el estado de la sincronización (prevención de nuevas conexiones que ser)
3. El final del registro de transacción se envía al espejo.
4. Los roles de director y el espejo se activan

Almacenamiento Cache

Database Mirroring, no tiene problemas de almacenamiento en caché.
Además de enviar las transacciones al espejo, realiza transferencias periódicas de metadatos
El propósito de estas transferencias de metadatos es para hacer que el espejo para leer las páginas en la memoria caché de datos.
 

Redireccionamiento del cliente de forma transparente

• Cuando un cliente realiza una conexión a un principal
•  Las cachés de objetos de conexión (MDAC-Transparent Client Redirect) 
• Si una sesión de creación de reflejo de la base de datos falla, el cliente sólo necesita para volver a conectar, el caché de conexión dentro de MDAC automáticamente redirige la conexión a el servidor reflejado

 Database Mirroring Threading

• Comunicación Global
• Failover
• Estado de mensajes
• En el Espejo 
• Gestionar el proceso de escritura de los registros 
• El mantenimiento de las cachés de consulta y los datos
• En el Testigo
• Gestione todos los mensajes entre el testigo y sesiones principales participantes / espejo
• Los cambios de estado y solicitudes de conmutación por error

 Instantaneas de Base de Datos

La base de datos espejo dentro de una sesión de duplicación de base de datos está en un estado constante de recuperación y es inaccesible a los usuarios.
Puede crear una instantánea de base de datos en una base de espejo que ofrece un punto en el tiempo, acceso de sólo lectura.

 Lección 2: Inicialización Database Mirroring

1.  Introduction
2. Recovery Model
3. Backup and Restore
4. Copy System Objects
5. Practices

Introducción

Los cuatro pasos generales que debe tomar para prepararse para la creación de reflejo de base de datos:

1. Asegúrese de que las bases de datos están configurados para utilizar el modelo de recuperación completa.
2. Copia de seguridad de la base de datos principal
3. Restaurar la base de datos a la instancia que aloja la base de datos reflejada mediante la opción NORECOVERY.
4. Copie todos los objetos del sistema necesarios para la instancia que aloja la base de datos reflejada.

Modo Recuperación

Porque Database Mirroring mantiene tanto el primario y bases de datos espejo como duplicados exactos, incluyendo la sincronización de todas las estructuras internas tales como números de secuencia de registro (LSN).
El modelo de recuperación de una base de datos única que se puede utilizar para participar en la creación de reflejo de base de datos es el modelo de recuperación completa

Respaldos y Restauración

• El proceso de inicialización de Database Mirroring implica la realización de una copia de seguridad de la base de datos principal y su restauración en el espejo.
•  Al restaurar la base de datos al espejo, es esencial que se especifica la opción NORECOVERY para el comando RESTORE.
  El espejo refleja el estado de la base de datos principal, incluyendo los LSN.
• La última copia de seguridad completa de la base de datos principal y luego aplicar todos los registros de transacciones posteriores.

Copia de los objetos de sistema

• Si desea permitir a las aplicaciones funcionar después de una conmutación por error, debe asegurarse de que todos los demás objetos son transferidos a la instancia que aloja la base de datos reflejada.
•  Los objetos más comunes que se deben transferir los inicios de sesión son los que permiten a las aplicaciones autenticarse para acceder base de datos.
•  También puede hacer que a servidores vinculados, SQL Server Integration Services (SSIS), trabajos del Agente SQL Server.
•  Para transferir objetos a la instancia que aloja la base de datos reflejada, puede utilizar SSIS, que incluye la tarea Transferir inicios de sesión para transferir los inicios de sesión de una instancia de SQL Server a otro.
•  SSIS también proporciona tareas para la transferencia de trabajos del Agente SQL Server, mensajes de error y otros tipos de objetos.

Lección 3: Diseño de conmutación por error y conmutación por recuperación Estrategias

1. Designing Mirroring Session Failover
2. Designing Mirroring Session Failback
3. Failback After Graceful Failover
4. Failback After Forced Failover
5. Practices

Diseño de conmutación por error de sesión de creación de reflejo

• Migración de conexiones y servidores vinculados es el paso más importante que usted debe tomar para asegurarse de que las aplicaciones sigan funcionando después de una conmutación por error.
•  SSIS tiene una tarea que se puede utilizar para migrar los inicios de sesión entre instancias
•  Los servidores vinculados necesitan ser re-creado.
•  Si la seguridad de acceso se define mediante inicios de sesión de SQL Server, es posible que tenga que realizar pasos adicionales después de una conmutación por error
•  Es necesario para ejecutar ALTER LOGIN para reasignar los inicios de sesión (SID-Security Identifier)
•  Los otros objetos que usted necesita para volver a crear en el espejo para asegurarse de conmutación por error completa y adecuada para las aplicaciones son trabajos del Agente SQL Server, paquetes SSIS y los mensajes de error personalizados.
•  Los trabajos del Agente SQL Server se debe crear, sino que son discapacitados porque no pueden acceder a una base de datos reflejada. 

Diseño de conmutación por recuperación Mirroring Sesión

El aspecto de culto más dificultades de cualquier solución de alta disponibilidad está diseñando una estrategia de recuperación. Cuando una solución de disponibilidad por error a un servidor secundario, todas las transacciones que se emiten ahora en contra de la secundaria.
Para permitir que las aplicaciones, la conmutación por recuperación y conectarse a la primaria, es necesario aplicar la copia actualizada de los datos antes de colocar la base de datos de nuevo en servicio.

Conmutacion por recuperacion de fallos

Si los socios se sincronizaron en el momento de la conmutación por error, puede solicitar copias de seguridad del registro de transacciones para rodar la pareja no pudo avanzar en el tiempo, y luego Database Mirroring finaliza el proceso de resincronización.
Siga los siguientes pasos:

1. Detenga las copias de seguridad del registro de transacciones en el principal.
2. Coloque nuevamente el socio no en línea
3. Restaurar las copias de seguridad del registro de transacciones desde la hora de la falla hasta el presente, garantizando así que siempre especifique la opción NORECOVERY
4. Después de que el director empieza a enviar las transacciones al espejo, reinicie las copias de seguridad del registro de transacciones en el principal.
5. Cuando el director y el espejo se vuelve a sincronizar completamente, con gracia conmutar la sesión de duplicación y vuelva a conectar las aplicaciones con el director.

Recuperación forzada

• Si los socios no se sincronizaron en el momento de la conmutación por error, debe quitar el reflejo y reinicializar.
• Conmutación por error para el alto rendimiento, el modo de funcionamiento, es manual. Debe ejecutar el siguiente comando desde el espejo para hacer que la sesión de la conmutación por error:

ALTER DATABASE AdventureWorks SET PARTNER FORCE_SERVICE_ALLOW_DATA_LOSS;

• Si el socio no no se puede volver a sincronizar, debe quitar la sesión de duplicación y reinicializar reflejo de la base de datos.
•  Puede eliminar una sesión de duplicación ejecutando el siguiente comando:  

ALTER DATABASE AdventureWorks SET PARTNER OFF;