Las bases de datos del grupo de disponibilidad distribuida de SQL Server no se sincronizan después de reiniciar el servidor

Nos estamos preparando para realizar una gran actualización en nuestros servidores SQL y estamos notando un comportamiento inusual con los grupos de disponibilidad distribuida que estoy tratando de resolver antes de seguir adelante.

El mes pasado, actualicé un servidor secundario remoto de SQL Server 2016 a SQL Server 2017. Este servidor forma parte de varios Grupos de disponibilidad distribuida (DAG) y un Grupo de disponibilidad (AG) separado . Cuando actualizamos este servidor, no sabíamos que entraría en un estado ilegible , por lo que durante el último mes solo confiamos en el servidor primario.

Como parte de la próxima actualización, apliqué el parche CU 4 al servidor y lo reinicié. Cuando el servidor volvió a estar en línea, el secundario recién parcheado mostró que todos los DAG / AG se sincronizaban sin ningún problema.

Sin embargo, la primaria mostraba una historia muy diferente. Estaba informando que

• el AG separado se estaba sincronizando sin ningún problema
• pero los DAG estaban en un No Synchronzing / No saludable estado

Después de entrar en pánico inicialmente, intenté lo siguiente para sincronizar las cosas nuevamente en los DAG:

• Desde la primaria, paré y reanudé el movimiento de datos. Esto no comenzó a sincronizar los datos.
• En el secundario (el que acabo de parchar) ejecuté ALTER DATABASE [<database] SET HADR RESUME;, que se ejecuta sin errores, pero no reanudó ninguna sincronización

Mi último intento de sincronizar los datos nuevamente fue iniciar sesión en el secundario y reiniciar manualmente el servicio SQL Server. Reiniciar manualmente el servicio parece un poco extremo, ya que esperaría que el servidor reiniciado hubiera sido suficiente.

¿Alguien se ha encontrado con este problema en el que un DAG no comienza a sincronizarse con un secundario después de un reinicio? Si es así, ¿cómo se resolvió?

Revisé el registro de errores de SQL Server y el visor de eventos en el servidor secundario, no había nada fuera de lo común que pudiera ver.

Tenga en cuenta que esta no es una respuesta definitiva, pero es la mejor respuesta después de chatear con Taryn .

Sin embargo, la primaria mostraba una historia muy diferente. Informaba que el AG separado se estaba sincronizando sin ningún problema, pero los DAG estaban en un estado Sin sincronización / No saludable

Si las bases de datos individuales y los AG subyacentes al ag distribuido dicen que están sanos y sincronizados, existe una buena posibilidad de que esto sea solo un problema en los paneles de control del DMV y / o SSMS. Como no había nada en el registro de errores que sugiriera que la réplica no se conectaba o estaba desconectada.

Desafortunadamente, dado que el problema se resolvió, es difícil decir exactamente qué fue ... pero en el futuro si esto le ocurre a alguien:

• Verifique sys.dm_hadr_database_replica_states en todos los clústeres en busca de algo que no sea saludable. Si todo se muestra saludable, es posible que el DMV aún no se haya actualizado
• Si no es saludable, verifique el registro de errores / DMV para detectar problemas de conectividad (como no poder conectarse al reenviador / primario global)
• La respuesta de Dan menciona problemas que podrían surgir del inicio de la base de datos, aunque en este caso la instancia no se puede leer, por lo que lo más probable es que no haya sido un problema, pero podría serlo en su caso.
• Si la base de datos es legible, realice una prueba de humo con una tabla / inserto ficticio o ...
• Sesión de evento extendida usando los elementos del canal DEBUG sqlserver.hadr_dump_log_blocko sqlserver.hadr_apply_log_blockpara ver si el secundario realmente está recibiendo / aplicando los bloques de registro o ...
• Objeto Perfmon SQLServer:Database Replica\Log Bytes Received/sec

Si está recibiendo datos en ese secundario, pero el ag distribuido aún muestra que no se sincroniza o no funciona, entonces lo dejaría pasar un poco para ver si los valores del DMV cambian, ya que obviamente está recibiendo y procesando bloques de registro.

Sin embargo, si no es así, tendremos que investigar más a fondo lo que está fuera del alcance de la respuesta.

Prefacio todo esto con la advertencia de que no tengo ningún DAG en producción. Fundamentalmente, aunque este consejo debe aplicarse entre los AG y los DAG.

¿Se reanudó la sincronización después del reinicio del servicio? Si es así, mi mejor conjetura de la causa sería bloquear el SPID de rehacer. Si aún no se sincroniza, incluso después del reinicio, esto es lo que comprobaría primero:

Bloqueo de AG redo SPID

Generalmente solo ocurrirá en un secundario legible. Para verificar, ejecute lo siguiente:

select session_id, blocking_session_id, db_name(database_id), wait_type
from sys.dm_exec_requests
where command = 'DB STARTUP'

Si aparece algún SPID de bloqueo, deberá eliminarlo antes de que el secundario pueda reanudarse (el DB STARTUPSPID es el que maneja las operaciones de rehacer). Sugeriría revisar el SPID de bloqueo de antemano para tratar de determinar la causa (generalmente un informe de larga duración).

Si desea más información sobre esto, hay un gran artículo (incluido el seguimiento de este tipo de comportamiento usando los XE) aquí .

Verificar DMV

Si se suspende el movimiento de datos, puede consultar los DMV para obtener más información sobre el motivo de la suspensión. Ejecute lo siguiente:

select db_name(database_id), synchronization_state_desc, database_state_desc, suspend_reason_desc
from sys.dm_hadr_database_replica_states

El artículo de BOL describe el suspend_reason un poco más.

¿Su grupo de disponibilidad distribuida (DAG) está dividido entre diferentes regiones? Si es así, podría estar sufriendo el valor predeterminado de SESSION_TIMEOUT (10 segundos) demasiado bajo. Esto significa que la latencia entre las dos regiones es demasiado alta para completar la sincronización de manera confiable.

Un grupo de disponibilidad normal puede aumentar su valor SESSION_TIMEOUT para que las sesiones de sincronización sean más estables. Noté a fines del año pasado que el parámetro SESSION_TIMEOUT de los DAG no se pudo editar. Esto significaba que los DAG solo eran viables para escenarios de baja latencia. Registramos un ticket con Microsoft y a principios de este año se lanzó una revisión.

Mejora: configure el valor SESSION_TIMEOUT para una réplica de grupo de disponibilidad distribuida en SQL Server 2016 y 2017