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.

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

6. Múltiples réplicas secundarias

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

10. Availability Group Dashboard

11. DEMO
Creación de un Grupo de Disponibilidad /
Agregar un nodo a un Grupo de Disponibilidad

12. Usos de réplicas secundarias

13. Database Recovery Advisory

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

17. DEMO
Backups & Enrutamiento en Grupos de Disponibilidad

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

21.  sys.availability_databases_cluster
 sys.availability_group_listener_ip_addresses
 sys.availability_group_listeners
 sys.availability_groups
 sys.availability_groups_cluster
 sys.availability_read_only_routing_lists
 sys.availability_replicas
 sys.dm_tcp_listener_states
DMVs para AlwaysOn Availability Groups, Listeners,
Replicas, Cluster…

22.  sys.dm_hadr_auto_page_repair
 sys.dm_hadr_availability_group_states
 sys.dm_hadr_availability_replica_cluster_nodes
 sys.dm_hadr_availability_replica_cluster_states
 sys.dm_hadr_availability_replica_states
 sys.dm_hadr_cluster
 sys.dm_hadr_cluster_members
 sys.dm_hadr_cluster_networks
 sys.dm_hadr_database_replica_cluster_states
 sys.dm_hadr_database_replica_states
 sys.dm_hadr_instance_node_map
 sys.dm_hadr_name_id_map
DMVs para AlwaysOn Availability Groups, Listeners,
Replicas, Cluster…

23. DEMO
FailOvers

24. Duración de las consultas (ms)

25. Duración de las consultas (ms)

26. Duración de las consultas (ms)

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: