http://summit.solidq.com/madrid
SQL Server 2012 da un salto cuantitativo en sus capacidades de Alta Disponibilidad con los grupos de disponibilidad AlwaysOn. En esta sesión mostraremos la nueva solución y obtendremos una visión global de cómo nos ayudará a mantener la continuidad de nuestro negocio con una mayor flexibilidad y menor coste que las soluciones actuales.
Adaptive Query Processing: Mejoras en el motor de consulta de SQL Server 2017...
Always On y grupos de disponibilidad SQL Server 2012
1. Always On y Grupos de Disponibilidad
SQL Server 2012
LUÍS J. MORÁN
REL300006
DPA - Relacional
lmoran@solidq.com
RUBÉN GARRIGÓS
Mentor - Relacional
rgarrigos@solidq.com
2. Conocer los Grupos de Disponibilidad
Identificar los elementos que conforman un grupo
Crear un Grupo de Disponibilidad
Realizar Backups en un Grupo de Disponibilidad
Enrutamiento
Funcionamiento de los Failovers
Objetivos de la sesión
3. AlwaysOn Availability Groups
Evolución de las tecnologías actuales
Database Mirroring
Síncrono/asíncrono
Failover Clustering
Nombre virtual
Log Shipping
Múltiples secundarios
SQL Server 2012 AlwaysOn
4. No sustituye (por ahora) a Database Mirroring
Necesita Windows Clustering por debajo
Windows Server Enterprise Edition (>32 GB)
Las máquinas deben pertenecer al mismo dominio
Compresión y encriptación de serie
No se han introducido mejoras en Database Mirroring
Es probable que deje de soportarse en futuras versiones
Database Mirroring
5. Ofrecer alta disponibilidad y recuperación ante desastres
manteniendo réplicas de las bases de datos
Maximizar la utilización de los servidores
Réplicas secundarias activas (solo lectura)
Múltiples réplicas secundarias (4 max)
Síncronas (2 max) y asíncronas
AlwaysOn Availability Groups
7. Un grupo es un contenedor
Bases de datos lógicamente relacionadas
Máximo recomendado: 100 bases de datos
Bases de datos r/w, multiuser y full recovery model
Número máximo recomendado de grupos por instancia: 10 grupos
Una réplica es una copia de un grupo
Primaria (única)
Secundarias (de 1 a 4)
Definimos el comportamiento como secundario en cada réplica
NONE Sin acceso, solo para HA/DR
READ_ONLY Requiere ApplicationIntent = ReadOnly
ALL Todas las conexiones se aceptan
AlwaysOn Availability Groups & Availability Replicas
8. Sobre instancias clusterizadas o no clusterizadas
Dado un grupo de disponibilidad normalmente cada
réplica debe estar en una instancia distinta
Colisión nombres bases de datos, ficheros, etc.
Si es posible en instancias clusterizadas
Es viable también con máquinas virtuales en el mismo host
Las réplicas no sustituyen a las instancias clusterizadas
Bases de datos de sistema independientes
Seguridad, jobs, configuración, servidores enlazados…
Availability Replicas
9. Similar al Network Name en SQL Server clustering
Necesario utilizar el protocolo TCP para conectar
Server=tcp:MiServidor;Database=db1;IntegratedSecurity=SSPI
Redirección en función del valor de ApplicationIntent
ReadWrite Réplica principal (por defecto)
ReadOnly A una de las réplicas read-only disponibles
Availability Listeners
14. Servidor informes en tiempo real
Alternativas
Logshipping
Mirroring + Snapshots
Replicación transaccional
Réplicas solo lectura
Versionado de filas: Snapshot isolation level automático
14 bytes extra por fila para punteros Page splits y espacio
extra
Las estadísticas automáticas se crean en tempdb al no poderse
crear en la réplica
Dimensionar tempdb acorde para soportar esta carga extra
Usos de réplicas secundarias
15. Enrutamiento de solo lectura
Redirige las peticiones de solo lectura a otro nodo del grupo para
liberar de trabajo al nodo primario
Se configura mediante T-SQL
Hay que indicar:
Endpoints de conexión
Orden deseado en las instancias de enrutamiento
Usos de réplicas secundarias
16. Reparación automática de errores
suspect_pages + sys.dm_hadr_auto_page_repair
CHECKDB
Se puede ejecutar en el secundario sin snapshot
Puede darnos algún error por el thread REDO Snapshot
Usos de réplicas secundarias
18. Más rápida que Clustering “clásico”, similar a DB Mirroring
El tiempo total depende del tiempo de detección del fallo
Red Casi instantáneo
Servidor “colgado” ~10 segundos sp_server_diagnostics
HEALTH_CHECK_TIMEOUT
Tipos de failover
Automático En caso de fallo a réplicas síncronas en estado OK
Manual Por mantenimiento y a réplicas síncronas en estado OK
Forzado Solo para casos de desastre
Failover de Availability Groups
19. Pasos durante el failover automático
Si el servidor aún responde, desconectamos a todos los clientes
Movemos el listener al secundario
El secundario aplica los cambios en el log pendientes
El secundario se promueve a principal y se hace rollback de las
posibles transacciones no confirmadas
Puede interesar configurar los votos de cada nodo en el
cluster y no depender tanto del número de nodos físicos
KB 2494036: http://support.microsoft.com/kb/2494036/en-us
Failover de Availability Groups
20. Nivel de fallo para el failover automático flexible
ALTER AVAILABILITY GROUP group_name SET
FAILURE_CONDITION_LEVEL =
1 El servicio SQL Server está caído
2 HEALTH_CHECK_TIMEOUT expirado (por defecto)
3 Errores críticos: dumps, spinlocks huérfanos, etc.
4 Errores graves: out of memory
5 Errores moderados: deadlocks irresolubles, workers agotados
Failover de Availability Groups
27. Si quieres disfrutar de las mejores sesiones de
nuestros mentores de España y Latino América,
ésta es tu oportunidad.
http://summit.solidq.com/madrid/
Síguenos: