Diagnóstico y resolución problemas mirroring AlwaysOn
1 recomendación1,234 vistas
El documento aborda el diagnóstico y la resolución de problemas en database mirroring y la transición a Always On, incluyendo la monitorización de eventos y operaciones inválidas en SQL Server. Se presentan buenas prácticas, como el uso de PowerShell para evaluaciones de estado de salud y la importancia de gestionar bloqueos en réplicas de solo lectura. Además, se detallan las configuraciones clave para detectar fallos y optimizar el rendimiento en entornos de alta disponibilidad.
Diagnóstico y resolución problemas mirroring AlwaysOn
- 1. Diagnóstico y Resolución de problemas en Database Mirroring y evolución a AlwaysON 400 REL40007 @enriquecatala Enrique Catala Bañuls Mentor ecatala@solidq.com MVP - MCT – MAP – Technical Ranger Rubén Garrigós Mentor rgarrigos@solidq.com MCT – MCAD – MCSD – MCITP
- 2. EN CUMPLIMIENTO CON LA LEY 15/1999 DE PROTECCION DE DATOS DE CARÁCTER PERSONAL, PONEMOS EN TU CONOCIMIENTO QUE ESTA SESIÓN VA A SER GRABADA POR SOLIDQ Y QUE ESTA GRABACIÓN PODRÍA SER UTILIZADA COMO MATERIAL DE MARKETING Y HACERSE PUBLICA A TRAVÉS DE DIVERSOS MEDIOS, COMO POR EJEMPLO NUESTRA PAGINA WEB. TENIENDO EN CUENTA QUE TU IMAGEN PUEDE APARECER EN ESA GRABACIÓN, SI NO DESEAS APARECER, ROGAMOS NOS LO COMUNIQUES POR LOS MEDIOS QUE YA CONOCES. COMUNICADO 2
- 3. Agenda 3 1. Monitorización de DB Mirroring 2. Operaciones inválidas en el log 3. Monitorización AlwaysOn 4. Chequeo de estado AlwaysOn 5. Buenas practicas 6. Bloqueos en réplicas de solo lectura
- 4. Monitorización de DB Mirroring 4 Eventos SQL Server del 1400 al 1500 1480 Cambio de rol en mirroring 1440 Activo como principal 1441 Activo como secundario 1442 Mirror inactivo 1443 Mirror finalizado 1432 Reparación de página en curso 1461 Reparación de página con éxito 1481 Reparación de página fallida
- 5. Monitorización de DB Mirroring 5 Eventos de SQL Server configurables (warnings) Eventos 32042, 32043, 32040 y 32044 respectivamente
- 6. Monitorización de DB Mirroring 6 Contadores básicos de rendimiento de DB Mirroring – Log Harden Time (ms) – Redo Queue KB – Send/Receive Ack Time – Log Send Queue KB – Transaction Delay Baseline Límites variables – WAN/LAN – Físico vs Virtual – Mirror para HA o para DR – Mirror dedicado o compartido
- 7. Monitorización de DB Mirroring 7 Eventos WMI DATABASE_MIRRORING_STATE_CHANGE Alertas con lógica y que reaccionen a ciertos eventos – Reintentar volver a poner en marcha la sesión si se ha suspendido – Destruir el mirror si estamos casi sin espacio en el log del principal
- 8. Monitorización de DB Mirroring Threads 8 Revisar que no agotamos los workers de SQL Server Threads en una sesión de database mirroring – Principal • 1 thread global y 2 treads por cada BBDD en mirror – Secundario • 1 thread global y 2 threads por base de datos • EE +1 thread redo por cada 4 cores Es en los thread redo donde podemos encontrarnos con una operación inválida en el secundario Podemos diagnosticarlos en base al cambio de estado a SUSPENDED en el principal y secundario
- 9. Monitorización de DB Mirroring Escenarios N a 1 9 Más apropiado para DR que para HA Problemas por collations distintos Colisiones de logins, de bbdd, jobs… N a 1 N a M instancias/virtuales No subestimar – Tener en cuenta la IO agregada – Capacidad de CPU para hacer los REDO Peor escenario – El secundario común convertido en principal común de todos Secundario común N principales
- 10. Operaciones inválidas log 10 Cuando una operación es introducida en el log, se transmite de forma “ciega” al secundario – Independiente de que la réplica sea síncrona o asíncrona – Lo único que podemos garantizar es que se ha escrito en el log del secundario pero el redo se hace siempre de forma asíncrona – La situación puede ser difícil de solucionar una vez ha ocurrido el error Añade o modifica un fichero de la base de datos – En una ruta que no existe en el secundario – En un disco que no existe en el secundario – En un disco con capacidad insuficiente en el secundario
- 11. DEMO 11 Operaciones inválidas en el log
- 12. Agenda 12 1. Monitorización de DB Mirroring 2. Operaciones inválidas en el log 3. Monitorización AlwaysOn 4. Chequeo de estado AlwaysOn 5. Buenas practicas 6. Bloqueos en réplicas de solo lectura
- 13. Hotfix AlwaysOn No imperativos pero recomendables 13 KB 2654347 para .NET 3.5 SP1 – ApplicationIntent – Enrutamiento de solo lectura – MultiSubnetFailover KB 2544514 para .net 4 (4.0.2) Para Windows Server 2008 y 2008 R2 – Son unos cuantos (Windows update!) 2494036, 2616514, 2531907, 2687741, 976097, 980915, 2578103, 2578113
- 14. Monitorizacion Alwayson Modelo de evaluación de estado de salud 14 Se ha potenciado el modelo de evaluación de estado de salud en dos pilares: – Políticas de administración declarativa – Powershell
- 15. Monitorizacion AlwaysOn Modelo de evaluación de estado de salud: Políticas 15 Availability Group State Availability Replica Database Replica State Server – IsHadrEnabled – ClusterQuorumState – HadrManagerStatus – ClusterQuorumType Nunca olvides asignar una categoría AlwaysOn
- 16. Monitorizacion Alwayson Modelo de evaluación de estado de salud: Políticas 16 Algoritmo de evaluación Start Ejecutar políticas definidas AlwaysOn Alguna política en error? Marcar categoria como Warning NO Marcar categoria como Error YES End Reportar categoria como saludable ¿Alguna política en Warning? YES NO Se obtienen condiciones AlwaysOn
- 17. Monitorizacion Alwayson Modelo de evaluación de estado de salud 17 ¿Dónde creéis que se evalúa el estado? – ¿En la réplica principal? – ¿En cualquier secundaria? – ¿En todas por igual?
- 18. Monitorizacion Alwayson Modelo de evaluación de estado de salud 18
- 19. Monitorizacion Alwayson Modelo de evaluación de estado de salud 19 Availability group errors (any replica) Availability group warnings (any replica) Availability group errors (primary) Availability group warnings (primary) Availability replica errors (any replica) Availability replica warnings (any replica) Availability database errors (any replica) Availability database warnings (any replica)
- 20. Monitorización Modelo de evaluación de estado de salud: PowerShell 20 Necesario módulo SQLPS Todo automatizado en 3 cmdlets: – Test-SqlAvailabilityGroup – Test-SqlAvailabilityReplica – Test-SqlDatabaseReplicaState Flag –AllowUserPolicies importante
- 21. Monitorizacion Alwayson Modelo de evaluación de estado de salud: PowerShell equivalencia 21 Test-SqlAvailabilityGroup Test-SqlAvailabilityReplica Test-SqlDatabaseReplicaState
- 22. DEMO 22 Previniendo problemas con DMF, PowerShell y alertas
- 23. Chequeo estado AlwaysOn Detección de Failover AlwaysOn 23 Frecuencia de chequeo configurable – Propiedad HealthCheckTimeout • En milisegundos • Por defecto 60000 ALTER SERVER CONFIGURATION SET FAILOVER CLUSTER PROPERTY HealthCheckTimeout = ###;
- 24. Chequeo estado AlwaysOn Detección de Failover AlwaysOn 24 Resource DLL ahora llama sp_server_diagnostics – 3 ejecuciones por cada HealthCheckTimeout – Fallos de conexión o devolución datos causarán Failover – Conexión dedicada para evaluación sp_server_diagnostics configurable – Siguiente slide
- 25. Chequeo estado AlwaysOn Detección de Failover AlwaysON 25 ALTER SERVER CONFIGURATION SET FAILOVER CLUSTER PROPERTY FailureConditionLevel = #; Level Condition Failover or Restart Conditions 0 No automatic failover or restart No automatic failover or restart ever 1 Failover or restart on server down SQL Server service is down 2 Failover or restart on server unresponsive SQL Server instance is not responsive 3 Failover or restart on critical server errors (default) sp_server_diagnostics returns “system error” 4 Failover or restart on moderate server errors sp_server_diagnostics returns “resource error” 5 Failover or restart on any qualified failure condition sp_server_diagnostics returns “query_processing error”
- 26. Monitorización AlwaysOn Buenas prácticas 26 1. Despliega políticas en todos los servidores 2. Crea al menos un job de evaluación PowerShell que te envíe correos 3. Crea alertas que te envíen correos 1. Detecta cambios de estado y avísate 2. Detecta situaciones anómalas de rendimiento y avísate
- 27. Bloqueos en réplicas de solo lectura 27 Afecta solo a las réplicas secundarias en solo lectura Threads en los grupos de disponibilidad – Distinta aproximación a la de Database Mirroring – Request queue y worker pool compartido por todas las bbdd de la instancia – Se reduce la cantidad media de threads depende de la carga – Tamaño del pool > bases de datos activas * 2 < bases de datos activas * 5 < (max worker thread – 40) – Los backups y filestream generan threads adicionales select * from sys.dm_exec_requests where command like '%HADR%' or command like '%DB%' or command like '%BRKR%'
- 28. Bloqueos en réplicas de solo lectura 28 Cuando una replica está marcada como solo lectura – Pequeña sobrecarga de 14 bytes para el puntero a las versiones – Similar a habilitar Snapshot Isolation/RCSI pero sin el row versioning en origen – El row versioning se genera en el secundario en tempdb El bloqueo del thread de redo ocurre al intentar obtener un bloqueo de modificación de esquema (SCH-M) que queda bloqueado por un bloqueo de estabilidad de esquema (SCH-S) – En un futuro se podrá configurar el matar la query (log shipping style)
- 29. Bloqueos en réplicas de solo lectura 29 Para su detección – sys.dm_exec_requests – Evento de proceso bloqueado en profiler – Evento extendido log_redo_blocked – Contador de rendimiento Recovery Queue Prevención – Reducir la duración de las consultas – Planificar las operaciones DDL en ventana de mantenimiento – Usar tablas temporales Reacción – Job que mate las queries que bloquean
- 30. DEMO 30 Bloqueos en réplicas de solo lectura
- 31. ¿Preguntas? 31
- 32. ¡Gracias! Siéntate a comer con nosotros o tómate un café y aclara tus dudas @enriquecatala Mentor Enrique Catala Bañuls Mentor Rubén Garrigós 32
- 33. 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: 33