Alta Disponibilidad

Alta Disponibilidad en
SQL Server 2005
Rubén Garrigós
Solid Quality Mentors
http://www.solidq.com
1

Solid Quality Mentors
• Mentores
•

Fernando G. Guerrero, Miguel Egea, Alejandro Leguízamo,
Jesús López, Jordi Rambla, Eladio Rincón, Daniel Seara,
Guillermo Som, Antonio Soto, Adolfo Wiernik, …

• +80 mentores en todo el mundo, 45 MVPs, 5 RDs.
• Ayudando a obtener lo mejor deSQLServer y .NET con

•
•
•

Formación
Consultoría
Mentoring

• http://blogs.solidq.com/es
• http://blogs.solidq.com/ES/ElRinconDelDBA
2

Objetivos

• Conocer que nos ofrece SQL Server 2005 para

mantener una alta disponibilidad de la plataforma de
datos de nuestro negocio

• Mostrar el funcionamiento de alguna de estas
capacidades.

3

Alta disponibilidad

• Accesocontinuo y confiable a la información y los
sistemas que la manejan.

• Disponibilidad 24x7, ¿una utopía?
• Presión para reducir costes
• Hardware
• Equipos de IT
• Costes asociados (formación, licencias, etc.)

4

Que nos impide la disponibilidad

• Operaciones de mantenimiento de la base de datos
• Limitaciones en el acceso concurrente
• Errores o desastres en el servidor de base dedatos

5

Características

• Operaciones sobre índices online
• Failover Clustering
• Database Mirroring (BD en espejo)
• Database Snapshot (instantáneas de BD)
• Mejoras en la recuperación de datos

6

Indexación “avanzada”

•¿Cuesta encontrar periodos para
el mantenimiento?

•¿Indexación lenta?
•¿Indexación sin bloqueos?
•¿Y si queremos añadir un índice?

7Indexación ONLINE

• Disponibilidad de la tabla
•

Solo se bloquea un instante al principio y al final del indexado

• Paralelismo

• Con y sin ONLINE

• Consume más espacio
•

Si generamos un nuevo índice cluster se necesita al menos 2x

• Lleva más tiempo

• La duración del proceso es más lenta que en modo OFFLINE
• Depende de la carga, el sistema de IO, etc.
8

DEMOSTRACIÓN:INDEXACIÓN
Indexación on-line

9

Failover clustering

• Complicado de configurar
• Hardware especializado y almacenamiento
compartido

• Hasta 8 nodos
• Tiempo de recuperación variable (~20s)
• Failover a nivel de instancia de SQL Server
10

Database Mirroring

•

Funcionamiento de Database Mirroring
o Modo síncrono
o Modo asíncrono

•

Únicamente 2 nodos (principal –secundario)
o Alternativa a más nodos  Log shipping

•

Tiempo de recuperación rápido (~3s)

11

Cómo funciona Database Mirroring
Modo síncrono – alta disponibilidad

Cliente

7. Reconocimiento
(ACK)

Testigo

1. Transacción

2. Transfiere a espejo
6. Reconocimiento (ACK)
4. Escribe en log
2. Escribe en Log
3. Log escrito

Data

Log escrito

Log

Data

PrincipalMirror
12

Log

Cómo funciona Database Mirroring
Modo asíncrono – alto rendimiento

Cliente

7. Reconocimiento
(ACK)
1. Transacción

2. Transfiere a espejo
6. Reconocimiento (ACK)
4. Escribe en log
2. Escribe en Log
3. Log escrito

Data

Log escrito

Log

Data

Principal

Mirror
13

Log

Niveles de sincronismo

• FULL (síncrono)
• Se confirma transacción enPrincipal sólo cuando la
transacción es registrada en el Mirror

o Requerido para recuperaciones automáticas
o La menor perdida de datos

o Impone dependencia de comunicación mutua

• OFF (asíncrono)
•

Se confirma la transacción en Principal según es registrada
o No espera confirmación en Mirror
o Permite independencia entre servidores

14

Consideraciones – Failover
ModoTestigo

Failover
Posible pérdida
automático
de datos

Síncrono
con testigo

Si

Yes

No

Síncrono sin
testigo
Asíncrono

No

No

No

No

No

Si

15

Consideraciones
• Permite tener alta disponibilidad con un coste mucho
más reducido que una solución en cluster

• Al igual que en la replicación se utiliza el log de

transacciones el cual puede crecer mucho...