Módulo 11

1. Módulo 11 Database Mirroring

2. TEMARIO • ¿Qué es el Database Mirroring? • Características • Escenarios claves • Fomra de trabajo • Seguridad • Modos en que opera • Estados del Database Mirroring • Witness • Failover • Redirección de cliente transparente

3. ¿Qué es el Database Mirroring? • Database Mirroring es una solución para suministrar alta disponibilidad a nivel de database • Opuesto al clustering, el cual satisface la necesidad de alta disponibilidad a nivel de instancia • Database mirroring ofrece un incremento considerable en la disponibilidad posible utilizando SQL Server log shipping • Cambios son reflejados en real-time sobre el server standby • Failover es automático • Database Mirroring trabaja manteniendo un hot standby server • Después de que un server de producción falla, aplicaciones pueden recuperarse rápidamente reconectando al hot standby server

4. Características • Database mirroring provee alta disponibilidad para databases individuales a través de redundancia completa • Dos copias separadas de los datos • Failover es casi instantáneo (típicamente, requiere menos que tres segundos). • No se requiere hardware especial • Servers comunican sobre una conexión de red directamente y puede ser en ubicaciones separadas

5. Escenarios claves • Hay dos escenarios principales para lo que el Database Mirroring esta diseñado: • Planned downtime: • El DBA quiere hacer un upgrade o modificar un sistema existente • Database mirroring es seteado con otro server • Hay un failover manual • Disaster Recovery: • La database “mirror” es ubicada en un lugar diferente de la principal, listo para reemplazar a la database principal en caso de que haya problemas

6. Fomra de trabajo • Una database “mirror” esta constituido de tres instancias de SQL Server 2005 • ‘principle’ database, reside sobre el ‘principle’ server • El server principal es el server al cual el cliente se conecta y realiza actualizaciones a la database • ‘Mirror’ database, reside sobre el mirror server • El mirror server ejecuta los mismos cambios sobre la esta database • ‘Witness’ server • El witness server monitorea el estatus los servers principal y ‘mirror’

7. Mirroring y Seguridad • Hay dos niveles de seguridad a considerar en database mirroring: • Server level • Database level

8. Security Server Level • Endpoints son usados para controlar el acceso • El administrador de sistema tiene que especificar cuales son los otros servers confiables. • Logins de NT deben estar presentes en ambas máquinas • El administrador de sistema le da a esos servers permiso para participar en mirroring • Debe estar completo sobre los 3 servers • Servers son mutuamente autenticados cada vez que se conectan

9. Modos en que opera • Hay tres modos posibles de operación para una sesión de database mirroring

10. Estados del Database Mirroring • SYNCHRONIZING • SYNCHRONIZED • DISCONNECTED • SUSPENDED

11. Como comenzar el Mirroring • Una vez que la ‘mirror database’ esta en su lugar y cualquier log de transacciones sobresaliente ha sido aplicado, entonces la mirroring session puede ser empezada • En el Query Editor: • Conectarse al mirror server, y poner el server en estado listo para formar una session cundo el mismo este contactado por el principal server: • ALTER DATABASE database SET PARTNER = ‘principal_server_instance' • Esto comienza la database mirroring session • Conectar al principal server, e identifica el mirror server: • ALTER DATABASE database SET PARTNER = ‘mirror_server_instance' • In SSMS • Click derecho sobre la database ->properties • Click sobre Mirroring option sobre la parte superior izquierda • opciones para • Configurar Seguridad • Comenzar mirroring

12. Pausar/Reanudar/Parar el Mirroring • Para suspender una database mirroring session utilizar Transact-SQL en cualquier partner: • En el Query Editor, ejecutar una sentencia ALTER DATABASE con la cláusula SET PARTNER SUSPEND • ALTER DATABASE database SET PARTNER SUSPEND • Para reanudar la database mirroring session • ALTER DATABASE database SET PARTNER RESUME • La mirror database automáticamente va hacia el estado SYNCHRONIZING

13. Pausar/Reanudar/Parar el Mirroring • Para detener una database mirroring session • ALTER DATABASE database SET PARTNER OFF • Este comando borrara la información de las mirroring sessions de los servers • Cada partner server ahora tendrá su propia copia de la database

14. Witness • Requerida para “automatic” failover • Es una instancia adicional opcional de SQL Server 2005 • Por default, una database mirroring session no tiene witness • La mirroring session no tiene que estar en modo de operación sincrónico para configurar un witness • Las computadoras partner participantes monitorean la conexión al witness server • Crear un Witness • ALTER DATABASE database SET WITNESS = ‘witness_server_instance' • Apagar al Witness • ALTER DATABASE database SET WITNESS OFF

15. Failover • Failover depende, principalmente, de dos cosas • Si un witness es participante en la session • Si la mirror database fue sincronizada con el principal • Cuando un witness esta presente y las copias de las database están ya sincronizadas, ocurre un failover automático • Cuando el witness esta ausente, un failover manual es posible si las copias de las database están ya sincronizadas • Cuando la database no esta sincronizada (independientemente de la presencia de un witness), el dueño de la database puede forzar a la mirror database a servir, sin embargo hay posibilidad de que se pierdan datos

16. Failover automático

17. Failover Manual

18. Servicio forzado

19. Redirección de cliente transparente • Object SqlConnection que apunta a una mirrored database: • La aplicación cliente se conecta exitosamente a la database principal, y el server envía de vuelta el nombre del partner server, el cual es entonces cacheado en el cliente • El Server que contiene la databaseprincipal falla o la conectividad es interrumpida entonces el estado de la conexión y transacción se pierden • La aplicación cliente intentará re-estabilizar una conexión a la databaseprincipal y fallará • La aplicación cliente intentará, transparentemente, estabilizar una conexión a la databasemirror sobre partner server • Si esta tiene éxito, la conexión es redireccionada a la mirror database, la cual entonces se torna en la nueva database principal • Si la nueva databaseprincipal tiene un partner server, entonces ese nuevo nombre de partner server es recuperado y cacheado en el cliente