Supervisar el rendimiento de grupos de disponibilidad AlwaysOn

SQL Server 2012
 

El aspecto del rendimiento de grupos de disponibilidad AlwaysOn es importante para mantener el contrato de nivel de servicio (SLA) para las bases de datos de misión crítica. Comprender cómo los grupos de disponibilidad AlwaysOn enviar registros a las réplicas secundarias puede ayudarle a estimar el objetivo de tiempo de recuperación (RTO) y recuperación de punto de recuperación (RPO) de la implementación de AlwaysOn e identificar cuellos de botella de bajo rendimiento grupos de disponibilidad o réplicas. Este tema describe el proceso de sincronización, muestra cómo calcular algunas de las métricas clave y proporciona los vínculos a algunos de los escenarios de solución de problemas comunes de rendimiento.

Se tratan los siguientes temas:

Para calcular el tiempo necesario para la sincronización completa y para identificar el cuello de botella, debe comprender el proceso de sincronización. Puede ser cualquier valor cuello de botella de rendimiento en el proceso y localizar el cuello de botella puede ayudarle a profundizar en los problemas subyacentes. La figura y la tabla siguiente muestran el proceso de sincronización de datos:

AlwaysOn Availability Group Data Synchronization

SecuenciaDescripción del pasoComentariosMétricas útiles
1Generación de registrosDatos de registro se vacían en el disco. Este registro se debe replicar en las réplicas secundarias. Las entradas del registro entran en la cola de envío.SQL Server: base de datos > flushed\sec de bytes de registro
2CapturarRegistros para cada base de datos se capturan y se envían a la cola de socio comercial correspondiente (uno por cada par de réplica de base de datos). Este proceso de captura se ejecuta continuamente como siempre que la disponibilidad de réplica está conectada y no se suspende el movimiento de datos por alguna razón, y se muestra el par de réplica de base de datos sea Synchronizing o Synchronized. Si el proceso de captura no es capaz de examen y poner en cola los mensajes es lo bastante rápido, la cola de envío de registro se acumula.Réplica de disponibilidad del servidor: SQL > Bytes enviados a Replica\sec, que es una agregación de la suma de todos los mensajes de la base de datos en cola para réplica de disponibilidad.

 log_send_queue_size (KB) y log_bytes_send_rate (KB/seg) en la réplica principal.
3SendLos mensajes de cada cola de réplica de base de datos se quita de la cola y envía a través de la conexión a la réplica secundaria correspondiente.Réplica de disponibilidad del servidor: SQL > Bytes enviados a transport\sec y réplica de disponibilidad del servidor: SQL > tiempo de confirmación del mensaje (ms)
4Recibir y almacenar en cachéCada réplica secundaria recibe y almacena en caché el mensaje.Contador de rendimiento réplica de SQL Server: disponibilidad > Bytes de registro recibidos/seg.
5ProtegerRegistro se vacía en la réplica secundaria para la protección. Tras el vaciado del registro, se envía una confirmación a la réplica principal.

Una vez que se protege el registro, se evita la pérdida de datos.
Contador de rendimiento SQL Server: base de datos > lisa Bytes de registro/seg.

Tipo de espera HADR_LOGCAPTURE_SYNC
6RehacerRehacer las páginas de vaciado de la réplica secundaria. Las páginas se mantienen en la cola de puesta al día mientras esperan debe rehacerse.Réplica SQL Server: base de datos > Rehacer Bytes/seg.

 redo_queue_size (KB) y redo_rate.

Tipo de espera REDO_SYNC

Grupos de disponibilidad AlwaysOn está diseñado con puertas de control de flujo en la réplica principal para evitar el consumo excesivo de recursos, tales como recursos de red y memoria, en todas las réplicas de disponibilidad. Dichas puertas de enlace de control de flujo no afectan el estado de sincronización de las réplicas de disponibilidad, pero pueden afectar al rendimiento general de las bases de datos de disponibilidad, incluido el RPO.

Después de que se han capturado los registros en la réplica principal, están sujetos a dos niveles de control de flujo, tal como se muestra en la tabla siguiente.

NivelNúmero de puertasNúmero de mensajesMétricas útiles
Transporte1 por cada réplica de disponibilidad8192Eventos extendidos database_transport_flow_control_action
Base de datos1 por cada base de datos de disponibilidad11200 (x64)

1600 (x 86)
DBMIRROR_SEND

Eventos extendidos hadron_database_flow_control_action

Una vez que se alcanza el umbral de mensaje de cualquier puerta, ya no se envían mensajes de registro en una réplica específica o para una base de datos. Estos se pueden enviar una vez que se reciben los mensajes de confirmación para que los mensajes enviados reducir el número de mensajes enviados por debajo del umbral.

Además de las puertas de control de flujo, hay otro factor que puede impedir que los mensajes de registro se envíen. La sincronización de réplicas garantiza que los mensajes se envían y se aplican en el orden de los números de secuencia de registro (LSN). Antes de enviar un mensaje de registro, su LSN también se compara con el número más bajo confirmado LSN para asegurarse de que es menor que uno de los umbrales (según el tipo de mensaje). Si la diferencia entre los dos números LSN es mayor que el umbral, no se envían los mensajes. Una vez que la diferencia es inferior al umbral de nuevo, se envían los mensajes.

Dos contadores de rendimiento útil, réplica de disponibilidad del servidor: SQL > control de flujo/s y réplica de disponibilidad del servidor: SQL > tiempo de Control de flujo (ms/s), mostrar, durante el último segundo, cuántas veces control de flujo se activó y cuánto tiempo espera en el control de flujo. Mayor tiempo de espera en el control de flujo se traducirá a RPO superior. Para obtener más información sobre los tipos de problemas que pueden provocar un tiempo de espera alta en el control de flujo, vea solucionar: RPO superó de grupo de disponibilidad.

El RTO en su SLA depende del tiempo de conmutación por error de la implementación de AlwaysOn en un momento dado, que se puede expresar en la siguiente fórmula.

AlwaysOn Availability Groups RTO Calculation

System_CAPS_ICON_important.jpg Importante


Si un grupo de disponibilidad contiene más de una base de datos de disponibilidad, la base de datos de disponibilidad con el más alto Tfailover se convierte en el valor de limitación para el cumplimiento de RTO.

El tiempo de detección de errores, Tdetection, es el tiempo que tarda el sistema detectar un error. Este tiempo depende en la configuración del nivel de clúster y no en las réplicas de disponibilidad individuales. Según la condición de conmutación automática por error que se configura, se puede desencadenar una conmutación por error como una respuesta instantánea a un error interno grave de SQL Server, como bloqueos por subproceso huérfanos. En este caso, la detección puede ser tan rápida como la sp_server_diagnostics ( Transact-SQL ) informe de errores se envía al clúster de WSFC (el intervalo predeterminado es 1/3 del tiempo de espera de comprobación de mantenimiento). También puede desencadenarse una conmutación por error debido a un tiempo de espera, como el tiempo de espera de comprobación de estado de clúster ha expirado (30 segundos de forma predeterminada) o la concesión entre la DLL de recursos y la instancia de SQL Server ha expirado (20 segundos de forma predeterminada). En este caso, la hora de detección es siempre que el intervalo de tiempo de espera. Para obtener más información, vea directiva de conmutación por error Flexible para conmutación automática por error de un grupo de disponibilidad ( SQL Server ) .

Lo único que necesita hacer para que estén preparados para una conmutación por error la réplica secundaria es para que la puesta al día para ponerse al día hasta el final del registro. El tiempo de puesta al día, Tredo, se calcula mediante la fórmula siguiente:

AlwaysOn Availability Groups Redo Time Calculation

donde redo_queue es el valor de redo_queue_size y redo_rate es el valor de redo_rate.

El tiempo de carga de conmutación por error, Toverhead, incluye el tiempo necesario para conmutar por error el clúster de WSFC y poner en línea las bases de datos. Este tiempo suele ser breve y constante.

El RPO en el SLA depende de la posible pérdida de datos de la implementación de AlwaysOn en un momento dado. Esta posible pérdida de datos se puede expresar en la siguiente fórmula:

Cálculo de RPO de los grupos de disponibilidad AlwaysOn

donde log_send_queue es el valor de log_send_queue_size y velocidad de generación de registro es el valor de SQL Server: base de datos > lisa Bytes de registro/seg..

System_CAPS_ICON_warning.jpg Advertencia


Si un grupo de disponibilidad contiene más de una base de datos de disponibilidad, la base de datos de disponibilidad con el más alto Tdata_loss se convierte en el valor de limitación para el cumplimiento de RPO.

El registro de envío cola representa todos los datos que se pueden perder de un error catastrófico. A primera vista, es curioso que la velocidad de generación de registro se utiliza en lugar de la velocidad de envío de registro (vea log_send_rate). Sin embargo, recuerde que el uso de la velocidad de envío de registro solo le concede el tiempo para sincronizar, mientras que RPO mide la pérdida de datos en función de la velocidad se genera, no en la rapidez con se sincroniza.

Una manera más sencilla de calcular Tdata_loss consiste en usar last_commit_time. La DMV en la réplica principal informa de este valor para todas las réplicas. Puede calcular la diferencia entre el valor de la réplica principal y el valor de la réplica secundaria calcular la velocidad del registro en la réplica secundaria se pone al día a la réplica principal. Como se mencionó anteriormente, este cálculo no indican la posible pérdida de datos en función de la velocidad se genera el registro, pero debe ser una aproximación.

Esta sección muestra cómo supervisar los grupos de disponibilidad para las métricas RTO y el RPO. Esta demostración es similar del tutorial de GUI de el AlwaysOn estado modelo parte 2: Extender el modelo de estado.

Elementos de la hora de conmutación por error y los cálculos de pérdida de datos potencial en tiempo de conmutación por error estimar (RTO) y pérdida de datos posible estimar (RPO) cómodamente se proporcionan como estadísticas de rendimiento de la faceta de administración de directivas estado de réplica de base de datos (consulte ver las facetas de administración basada en directivas en un objeto de SQL Server). Puede supervisar estas dos métricas según una programación y recibir alertas cuando las métricas superan el RTO y el RPO, respectivamente.

Las secuencias de comandos demostrados crean dos directivas del sistema que se ejecutan en sus respectivos calendarios, con las siguientes características:

  • Una directiva RTO que se produce un error al tiempo estimado de conmutación por error supera los 10 minutos, evaluados cada 5 minutos

  • Una directiva RPO que genera un error cuando la pérdida de datos estimada supera 1 hora, evaluada cada 30 minutos

  • Las dos directivas tienen una configuración idéntica en todas las réplicas de disponibilidad

  • Las directivas se evalúan en todos los servidores, pero solo en los grupos de disponibilidad para el que la réplica de disponibilidad local es la réplica principal. Si la réplica de disponibilidad local no es la réplica principal, no se evalúan las directivas.

  • Errores de directiva cómodamente se muestran en el panel AlwaysOn cuando se ve en la réplica principal.

Siga las instrucciones que aparecen a continuación en todas las instancias de servidor que participan en el grupo de disponibilidad:

  1. Iniciar el servicio Agente SQL Server si no se ha iniciado.

  2. En SQL Server Management Studio, desde la herramientas menú, haga clic en opciones.

  3. En el SQL Server AlwaysOn ficha, seleccione habilitar Directiva de AlwaysOn definida por el usuario y haga clic en Aceptar.

    Esta configuración le permite mostrar configuradas correctamente las directivas personalizadas en el panel de AlwaysOn.

  4. Crear un condición de administración basada en directivas con las especificaciones siguientes:

    • Nombre:RTO

    • Faceta: estado de réplica de base de datos

    • Campo:Add(@EstimatedRecoveryTime, 60)

    • Operador:<=

    • Valor:600

    Esta condición se produce un error cuando el tiempo de conmutación por error posibles supera los 10 minutos, incluido un segundo 60 sobrecarga para la detección de errores y conmutación por error.

  5. Cree un segundo condición de administración basada en directivas con las especificaciones siguientes:

    • Nombre:RPO

    • Faceta: estado de réplica de base de datos

    • Campo:@EstimatedDataLoss

    • Operador:<=

    • Valor:3600

    Esta condición se produce un error cuando la posible pérdida de datos supera 1 hora.

  6. Cree un tercer condición de administración basada en directivas con las especificaciones siguientes:

    • Nombre:IsPrimaryReplica

    • Faceta: grupo de disponibilidad

    • Campo:@LocalReplicaRole

    • Operador:=

    • Valor:Primary

    Esta condición se comprueba si la réplica de disponibilidad local para un grupo de disponibilidad determinado es la réplica principal.

  7. Crear un crear una directiva de administración basada en directivas con las especificaciones siguientes:

    • General página:

      • Nombre:CustomSecondaryDatabaseRTO

      • Condición de comprobación:RTO

      • Para destinos: DatabaseReplicaState cada en IsPrimaryReplica AvailabilityGroup

        Esta configuración garantiza que la directiva se evalúa solo grupos de disponibilidad para el que la réplica de disponibilidad local es la réplica principal.

      • Modo de evaluación: en programación

      • Programación: CollectorSchedule_Every_5min

      • Habilitado: seleccionado

    • Descripción página:

      • Categoría: advertencias de base de datos de disponibilidad

        Esta configuración permite que los resultados de la evaluación de directivas que se mostrará en el panel de AlwaysOn.

      • Descripción: la réplica actual tiene un RTO que supera los 10 minutos, suponiendo una sobrecarga de 1 minuto para la detección y conmutación por error. Debería investigar problemas de rendimiento en la instancia de servidor respectivo inmediatamente.

      • Texto que se va a mostrar: RTO superado.

  8. Cree un segundo crear una directiva de administración basada en directivas con las especificaciones siguientes:

    • General página:

      • Nombre:CustomAvailabilityDatabaseRPO

      • Condición de comprobación:RPO

      • Para destinos: DatabaseReplicaState cada en IsPrimaryReplica AvailabilityGroup

      • Modo de evaluación: en programación

      • Programación: CollectorSchedule_Every_30min

      • Habilitado: seleccionado

    • Descripción página:

      • Categoría: advertencias de base de datos de disponibilidad

      • Descripción: la base de datos de disponibilidad ha superado el RPO de 1 hora. Debería investigar problemas de rendimiento en las réplicas de disponibilidad inmediatamente.

      • Texto que se va a mostrar: RPO superó!

Cuando haya terminado, dos nuevos trabajos de agente SQL Server se crean, uno para cada una de la programación de evaluación de directivas. Estos trabajos deberían tener nombres que comienzan por syspolicy_check_schedule.

Puede ver el historial de trabajos para inspeccionar los resultados de la evaluación. Errores de evaluación se registrarán también en el registro de aplicación de Windows (en el Visor de eventos) con el Id. de evento 34052. También puede configurar el Agente SQL Server para enviar alertas sobre los errores de la directiva. Para obtener más información, consulte configurar alertas para notificar a los administradores de directiva de errores de directiva.

En la tabla siguiente se enumera los escenarios comunes de solución de problemas relacionados con el rendimiento.

EscenarioDescription
Solucionar problemas: Grupo de disponibilidad superado RTODespués de una conmutación por error automática o planeada manual sin pérdida de datos, el tiempo de conmutación por error supera el RTO. O bien, al calcular el tiempo de conmutación por error de una réplica secundaria de confirmación sincrónica (por ejemplo, un asociado de conmutación automática por error), encontrará que supera el RTO.
Solucionar problemas: Grupo de disponibilidad superado RPODespués de realizar una conmutación por error manual forzada, la pérdida de datos es mayor que el RPO. O bien, al calcular la posible pérdida de datos de una réplica secundaria de confirmación asincrónica, encontrará que supera el RPO.
Solucionar problemas: Cambios en la réplica principal no se reflejan en la réplica secundariaLa aplicación cliente finaliza una actualización en la réplica principal correctamente, pero consulta la réplica secundaria se muestra que el cambio no se refleja.

Los siguientes eventos extendidos son útiles al solucionar problemas de réplicas en el Synchronizing estado.

Nombre del eventoCategoríaCanalRéplica de disponibilidad
redo_caught_uptransaccionesDepuraciónSecundario
redo_worker_entrytransaccionesDepuraciónSecundario
hadr_transport_dump_messageAlwaysOnDepuraciónPrincipal
hadr_worker_pool_taskAlwaysOnDepuraciónPrincipal
hadr_dump_primary_progressAlwaysOnDepuraciónPrincipal
hadr_dump_log_progressAlwaysOnDepuraciónPrincipal
hadr_undo_of_redo_log_scanAlwaysOnAnalíticosSecundario
Mostrar: