SQL Server 2017 con 500 bases de datos: desconexiones frecuentes de AG desde CU9

Hola a todos y gracias de antemano por su ayuda. Estamos experimentando desafíos con los grupos de disponibilidad de SQL Server 2017.

Antecedentes

La compañía es un software de back-end B2B minorista. Alrededor de 500 bases de datos de inquilinos individuales y 5 bases de datos compartidas utilizadas por todos los inquilinos. La característica de carga de trabajo se lee principalmente, y la mayoría de las bases de datos tienen una actividad muy baja.

Los servidores de producción física alojados en la ubicación conjunta se actualizaron recientemente de SQL Server 2014 Enterprise en Windows Server 2012 en una configuración SAN / FCI compartida, a SQL Server 2017 Enterprise en Windows Server 2016 en 2 sockets / 32 núcleos / 768 GB de RAM y local Unidades SSD con AlwaysOn AG. El tráfico AG utiliza puertos NIC 10G dedicados con una conexión de cable cruzado.

Su requisito es que todas las bases de datos se conmuten por error juntas, por lo que tuvieron que ponerlas todas en un solo AG. Es una réplica síncrona única, no legible en un servidor idéntico.

Los nuevos servidores han estado en producción desde junio de 2018. Se instalaron las últimas actualizaciones de CU (CU7 en ese momento) y de Windows, y el sistema funcionaba bien. Aproximadamente un mes después, después de actualizar los servidores de CU7 a CU9, comenzaron a notar los siguientes desafíos, enumerados en orden de prioridad.

Hemos estado monitoreando los servidores usando SQL Sentry y no hemos observado cuellos de botella físicos. Todos los indicadores clave parecen buenos. La CPU tiene un promedio del 20%, el tiempo de E / S suele ser inferior a 1 ms, la RAM no se utiliza por completo y la red <1%.

Desafíos

Los síntomas parecen mejorar después de la conmutación por error, pero reaparecen en unos pocos días, independientemente del servidor primario: los síntomas son idénticos en ambos servidores.

1. Tiempos de espera esporádicos del cliente y fallas de conectividad como

   ... se produjo un error al establecer la conexión ...

   o

   El tiempo de espera de ejecución expiró

   A veces, estos durarán hasta 40 segundos y luego desaparecerán.

2. El trabajo de copia de seguridad del registro de transacciones tarda 10 veces más en completarse que antes. Anteriormente tomaba de 2 a 3 minutos hacer una copia de seguridad de los registros de las 500 bases de datos, ahora toma de 15 a 25. Hemos verificado que el respaldo en sí funciona bien con un buen rendimiento. Sin embargo, hay un pequeño retraso después de completar la copia de seguridad de un registro y antes de comenzar el siguiente. comienza muy bajo, pero en un día o dos llega a 2-3 segundos. Multiplicado por 500 bases de datos, y ahí está la diferencia.

3. Ocasionalmente, algunas bases de datos aparentemente aleatorias se atascan en el estado "Sin sincronización" después de la conmutación por error manual. La única forma de resolver esto es reiniciar el servicio SQL Server en la réplica secundaria o eliminar y volver a unir estas bases de datos al AG.

4. Otro problema introducido por CU10 (y no resuelto en CU11): conexiones al tiempo de espera secundario al bloquear en master.sys.databases e incluso no se puede usar el explorador de objetos SSMS para la réplica secundaria. La causa raíz parece estar bloqueada por el escritor VSS de Microsoft SQL Server que emite la siguiente consulta:

   select name, 
          recovery_model_desc, 
          state_desc, 
          CONVERT(integer, is_in_standby), 
          ISNULL(source_database_id,0) 
     from master.sys.databases

Observaciones

Creo que encontré la pistola humeante en los registros de errores. Los registros de errores están llenos de mensajes AG, que están etiquetados como 'solo informativos', pero parece que no son normales en absoluto, y existe una correlación muy fuerte de su frecuencia con los errores de la aplicación.

Los errores son de varios tipos y vienen en secuencias:

• DbMgrPartnerCommitPolicy :: SetSyncState: GUID

• DbMgrPartnerCommitPolicy :: SetSyncAndRecoveryPoint: GUID

• La conexión de los grupos de disponibilidad AlwaysOn con la base de datos secundaria finalizó para la base de datos primaria 'XYZ' en la réplica de disponibilidad 'DB' con ID de réplica: {GUID}. este es solo un mensaje informativo. No se requiere ninguna acción del usuario.

• La conexión de los grupos de disponibilidad AlwaysOn con la base de datos secundaria establecida para la base de datos primaria 'ABC' en la réplica de disponibilidad 'DB' con ID de réplica: {GUID}. este es solo un mensaje informativo. No se requiere ninguna acción del usuario.

Algunos días hay 10 de miles de esos.

Este artículo analiza el mismo tipo de secuencia de errores en SQL 2016 y allí dice que es anormal. Esto también explica el fenómeno de "no sincronización" después de la conmutación por error. El tema discutido fue para 2016 y se solucionó a principios de este año en una CU. sin embargo, es la única referencia relevante que pude encontrar para los primeros 2 tipos de mensajes, aparte de las referencias a mensajes de inicialización automática que no deberían ser el caso aquí ya que el AG ya está establecido.

Aquí hay un resumen de los errores diarios de la semana pasada, para los días que tenían errores> 10K por tipo en el PRIMARIO (el secundario muestra 'perdiendo conexión con el primario ...'):

Date        Message Type (First 50 characters)                  Num Errors
10/8/2018   DbMgrPartnerCommitPolicy::SetSyncAndRecoveryPoint:  61953
10/3/2018   DbMgrPartnerCommitPolicy::SetSyncAndRecoveryPoint:  56812
10/4/2018   DbMgrPartnerCommitPolicy::SetSyncAndRecoveryPoint:  27951
10/2/2018   DbMgrPartnerCommitPolicy::SetSyncAndRecoveryPoint:  24158
10/7/2018   DbMgrPartnerCommitPolicy::SetSyncAndRecoveryPoint:  14904
10/8/2018   Always On Availability Groups connection with seco  13301
10/3/2018   DbMgrPartnerCommitPolicy::SetSyncState: 783CAF81-4  11057
10/3/2018   Always On Availability Groups connection with seco  10080

También ocasionalmente vemos mensajes "extraños" como:

La base de datos del grupo de disponibilidad "DB" está cambiando los roles de "SECUNDARIO" a "SECUNDARIO" porque la sesión de duplicación o el grupo de disponibilidad fallaron debido a la sincronización de roles. este es solo un mensaje informativo. No se requiere ninguna acción del usuario.

... entre una gran cantidad de estados cambiantes de "SECUNDARIO" a "RESOLVER".

Después de la conmutación por error manual, el sistema puede pasar varios días sin un solo mensaje de este tipo, y de repente, sin razón aparente, obtendremos miles a la vez, lo que a su vez hace que el servidor deje de responder y provoque la aplicación tiempos de espera de conexión. Este es un error crítico ya que algunas de sus aplicaciones no incorporan un mecanismo de reintento y, por lo tanto, pueden perder datos. Cuando se produce un estallido de errores, los siguientes tipos de espera se disparan. Esto muestra las esperas justo después de que AG parece haber perdido la conexión con todas las bases de datos a la vez:

Aproximadamente 30 segundos después, todo vuelve a la normalidad en términos de esperas, pero los mensajes de AG siguen inundando los registros de errores a diferentes velocidades y durante diferentes momentos del día, en momentos aparentemente aleatorios que incluyen las horas pico. El aumento concurrente en la carga de trabajo durante estas ráfagas de errores empeora las cosas, por supuesto. Si solo se desconectan unas pocas bases de datos, generalmente no hace que las conexiones se agoten, ya que se resuelve con la suficiente rapidez por sí solo.

Intentamos verificar que efectivamente CU9 comenzó el problema, pero pudimos degradar ambos nodos solo a CU9. Los intentos de degradar cualquiera de los nodos a CU8, hicieron que ese nodo se atascara en el estado 'Resolviendo' mostrando el mismo error en el registro:

No se puede leer la configuración persistente del grupo de disponibilidad Siempre activado con el ID de recurso correspondiente '... La configuración persistente está escrita por un servidor SQL de versión superior que aloja la réplica de disponibilidad primaria. Actualice la instancia local de SQL Server para permitir que la réplica de disponibilidad local se convierta en una réplica secundaria.

Esto significa que tendremos que introducir el tiempo de inactividad para poder degradar ambos nodos a CU8 al mismo tiempo. Esto también sugiere que hubo una actualización importante de AG que puede explicar lo que estamos experimentando.

Ya intentamos ajustar el max_worker_threads de su valor predeterminado de 0 (= 960 en nuestro cuadro basado en este artículo ) gradualmente hasta 2,000 sin ningún impacto observado en los errores.

¿Qué podemos hacer para resolver estas desconexiones AG? ¿Alguien por ahí experimenta problemas similares? ¿Pueden otras personas con una gran cantidad de bases de datos en un AG ver mensajes similares en el registro de errores de SQL que comienzan con CU9 o CU8?

¡Gracias de antemano por cualquier ayuda!

Actualizar:

1. Se confirmó que las desconexiones del grupo de disponibilidad frecuente eran una regresión introducida por CU9 y se resolvieron después de instalar CU12.

2. Se confirmó que los problemas de bloqueo en la réplica secundaria eran un problema con una actualización del código de escritor VSS que se introdujo en CU10. Esperemos que se resuelva en CU 13. La solución provisional es reemplazar manualmente las DLL del escritor VSS con las DLL Pre-CU10 ...

   BEGIN RANT-SACTION;

   Desafortunadamente, Microsoft parece estar fallando repetidamente en el control de calidad adecuado no solo de las actualizaciones de Windows 10, sino también de software de misión crítica empresarial como SQL Server.

   Preferí su estrategia anterior de service packs, al menos tuvieron tiempo suficiente para probarlos adecuadamente antes de infligir crisis de producción y pérdida de datos a sus clientes con el lanzamiento descuidado de actualizaciones a medias.

   COMMIT RANT-SACTION;

¿Revisaste los hilos de trabajo? Normalmente siempre se usa más hilo de trabajo para trabajar y normalmente el valor predeterminado no es suficiente. Tuve el mismo problema con 600 bases de datos siempre activadas, por lo que agregamos más subprocesos en el parámetro de instancia y eso solucionó nuestro problema. ¡Espero que esto ayude!