Always On Availability Groups: lista operativa

Un grupo de disponibilidad puede mostrar réplicas sanas mientras los objetivos de recuperación siguen en riesgo. Colas, listener, copias y failover requieren supervisión explícita.

Por qué este tema requiere atención deliberada

Un problema de este tipo rara vez existe aislado. Un cambio que mejora una consulta puede aumentar escrituras, registro, bloqueos, recuperación o complejidad en otro punto. Trata el trabajo como una decisión de ingeniería con objetivo medible, restricciones conocidas y responsable claro.

La disponibilidad es una capacidad operativa practicada, no un indicador verde.

Qué medir

Controla sincronización, colas de envío y redo, tiempo estimado de recuperación, conectividad, estado de bases, listener, preferencia de copias y failovers recientes.

Flujo de diagnóstico

• Define exactamente el síntoma, carga afectada, inicio, frecuencia e impacto visible.
• Captura evidencia durante periodos normales y degradados para la misma operación de negocio.
• Separa correlación de causa revisando planes, esperas, recursos, bloqueos, configuración y cambios recientes.
• Prueba grupos representativos de bases, consultas o parámetros, no solo el ejemplo más sencillo.
• Conserva configuración, plan, definición y contadores actuales antes de cambiar nada.
• Expresa numéricamente el resultado esperado: latencia, CPU, lecturas, rendimiento, cola o recuperación.

Cómo elegir la intervención

Prefiere el cambio más limitado que trate la causa demostrada. La configuración del servidor afecta muchas cargas, mientras que consultas, índices, estadísticas u horarios pueden ser más precisos. Considera licencia, versión, alta disponibilidad, ventanas y capacidad del equipo para supervisar.

Enfoque práctico

Define RPO y RTO medibles. Alerta sobre crecimiento sostenido de colas, prueba failover planificado y no planificado mediante la conexión de la aplicación y documenta quórum, endpoints, certificados, DNS y jobs.

Secuencia segura de implementación

• Reproduce el comportamiento en un entorno seguro con datos a escala de producción.
• Cambia una variable importante cada vez y conserva la definición original para revertir.
• Mide duración, CPU, lecturas, escrituras, esperas, memoria, registro y efectos posteriores.
• Prueba entradas normales, picos y extremos, además de reinicio o failover cuando corresponda.
• Despliega en una ventana adecuada con operador, propietario de aplicación y decisor conectados.
• Revisa el resultado de inmediato y durante el siguiente pico representativo.

Ejemplo de SQL Server

El siguiente ejemplo es un punto de partida para investigar o implementar de forma controlada. Adapta nombres, límites, retención y permisos antes de producción. Conserva la salida junto con la cronología del incidente y no trates una sola muestra como diagnóstico completo.

SELECT
    ag.name AS availability_group,
    ar.replica_server_name,
    DB_NAME(drs.database_id) AS database_name,
    drs.synchronization_state_desc,
    drs.log_send_queue_size,
    drs.redo_queue_size,
    drs.last_hardened_time,
    drs.last_redone_time
FROM sys.dm_hadr_database_replica_states AS drs
JOIN sys.availability_replicas AS ar ON ar.replica_id = drs.replica_id
JOIN sys.availability_groups AS ag ON ag.group_id = ar.group_id;

Qué evitar

No confundas sincronizado con probado, no olvides jobs en secundarios y no pruebes únicamente un failover manual ideal.

Supervisión después del cambio

Vigila la métrica que debía mejorar y al menos dos posibles efectos secundarios. Compara ventanas y volúmenes equivalentes. Observa el tiempo suficiente para incluir mantenimiento, copias, informes, failover y tareas periódicas. Documenta si la mejora persiste y si el cambio debe mantenerse, ajustarse o retirarse.

Reversión y responsabilidad

La reversión debe indicar el valor o definición anterior, quién decide y qué señal la activa. Conserva el plan y script originales para cambios de planes o metadatos. Para infraestructura, confirma capacidad y tiempo de mantenimiento antes de empezar.

Resultado operativo

La disponibilidad es una capacidad operativa practicada, no un indicador verde.

Lista de producción

Captura una línea base y define la mejora esperada. Prueba con datos y concurrencia representativos. Conserva la configuración o el plan original, prepara una reversión, despliega en una ventana adecuada y observa el siguiente pico normal de carga.

Preguntas antes de cerrar

• ¿Mejoró el síntoma original bajo la misma carga?
• ¿Aparecieron costes de escritura, almacenamiento, bloqueo, memoria o disponibilidad?
• ¿Sobrevivirá el resultado a reinicios, failover, estadísticas y crecimiento?
• ¿Las alertas detectarán una regresión antes que los usuarios?
• ¿Quedaron registrados la decisión, el responsable y la fecha de revisión?

Si quieres aplicar este método a un entorno SQL Server concreto, usa el formulario inferior e incluye la versión, el tamaño de la base, el patrón de carga y las evidencias ya recopiladas.