Always On y grupos de disponibilidad SQL Server 2012

2,615 views

Published on

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.

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
2,615
On SlideShare
0
From Embeds
0
Number of Embeds
5
Actions
Shares
0
Downloads
53
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Always On y grupos de disponibilidad SQL Server 2012

  1. 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. 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. 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. 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. 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. 6. Múltiples réplicas secundarias
  7. 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. 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. 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. 10. Availability Group Dashboard
  11. 11. DEMO Creación de un Grupo de Disponibilidad / Agregar un nodo a un Grupo de Disponibilidad
  12. 12. Usos de réplicas secundarias
  13. 13. Database Recovery Advisory
  14. 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. 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. 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. 17. DEMO Backups & Enrutamiento en Grupos de Disponibilidad
  18. 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. 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. 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. 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. 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. 23. DEMO FailOvers
  24. 24. Duración de las consultas (ms)
  25. 25. Duración de las consultas (ms)
  26. 26. Duración de las consultas (ms)
  27. 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:

×