Operación de SQL Server Always On AG (Windows y Linux)

No es una instalación: operación diaria y escenarios de fallo de un Always On Availability Group ya instalado: comprobación de estado, diagnóstico de retraso y crecimiento del log, failover planificado, failover forzado (FORCE_FAILOVER_ALLOW_DATA_LOSS) y pasos posteriores, suspender/reanudar el movimiento de datos, modo síncrono/asíncrono, añadir bases de datos (automatic seeding o backup/restore), añadir/quitar réplicas, read-only routing y cambios del listener. Con comandos de WSFC en Windows y de Pacemaker (pcs) en Linux.

Elija lo que va a hacer en la tarjeta de escenarios; también puede abrir directamente el escenario correspondiente escribiendo el código de error (p. ej. 9002, 35264, 41142) en la búsqueda del catálogo. Si todavía no hay AG: AG (Windows) o AG (Linux).

Topología: AG con 2–9 réplicas (Windows WSFC o Linux Pacemaker)

Escenarios

• Comprobación de estado del AG (consultas del dashboard) — ¿Está todo en orden? Estado de las réplicas / bases de datos, preparación para el failover, cluster y últimos cambios de rol. No modifica nada.
• El secondary se queda atrás / el fichero de log crece (diagnóstico del retraso) — La cola de send/redo crece, los datos del secondary están desfasados, el log del primary está a punto de llenarse (log_reuse_wait = AVAILABILITY_REPLICA) o los commits son lentos (HADR_SYNC_COMMIT).
• Failover planificado (switchover, sin pérdida de datos) — Para mantenimiento, patch o pruebas, mueve el primary a un secondary síncrono y SYNCHRONIZED; unos segundos de interrupción, sin pérdida de datos.
• Primary perdido: failover forzado (FORCE_FAILOVER_ALLOW_DATA_LOSS) — El primary (o todo el sitio / el quórum del cluster) se ha perdido y no se puede esperar: asumiendo pérdida de datos, un secondary pasa a primary; después se comparan los datos y se reanudan las demás réplicas.
• Suspender / reanudar el movimiento de datos (SUSPEND / RESUME) — Detener temporalmente el envío de datos al secondary (mantenimiento de red, proceso masivo) o reanudar una base de datos que ha quedado suspendida (SUSPENDED).
• Cambiar el modo síncrono / asíncrono — Pasar una réplica de SYNCHRONOUS_COMMIT ↔ ASYNCHRONOUS_COMMIT (sitio remoto, red lenta, simulacro de DR) y ajustar la protección del commit (REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT).
• Añadir una base de datos al AG (automatic seeding o backup/restore) — Incorporar al AG una base de datos nueva o existente: automatic seeding para bases de datos pequeñas/medianas, desde backup para bases de datos grandes o con red lenta.
• Añadir una réplica (nodo) — Añadir un nuevo secondary al AG: el nodo se une al cluster, se prepara el endpoint, ADD REPLICA + JOIN, y las bases de datos llegan por seeding.
• Quitar una réplica (nodo) — Quitar del AG y del cluster un secondary que se va a apagar definitivamente o reinstalar.
• Redirección de lecturas (read-only routing) — Redirigir a través del listener las conexiones ApplicationIntent=ReadOnly a los secondary legibles (descargar del primary la carga de informes).
• Crear o modificar el listener (IP, puerto) — Crear el listener si no existe, cambiar su puerto o (en Windows) añadir una IP para una segunda subred.

Antes de empezar

• En cada nodo, sqlcmd (/opt/mssql-tools18/bin/sqlcmd) y … como sysadmin; permisos de root (pcs). Contraseña: read -rsp 'Contraseña: ' SQLCMDPASSWORD; export SQLCMDPASSWORD y sudo --preserve-env=SQLCMDPASSWORD bash <script>.sh.
• PowerShell abierto como administrador con una cuenta de dominio que es sysadmin en SQL Server y administradora en el WSFC; están disponibles sqlcmd y el módulo FailoverClusters.
• La 1.ª fila de la lista de réplicas del formulario es el primary actual (compruébelo con la primera consulta de la comprobación de estado); los pasos se asignan al nodo correcto según este orden.
• Se ha aprobado la ventana de cambio y se ha informado al equipo de la aplicación…: el listener se corta unos segundos y las transacciones abiertas se revierten……: el cambio de puerto/IP afecta a las cadenas de conexión….
• La decisión del failover forzado la ha tomado una persona autorizada y se ha aceptado la pérdida de datos: no se puede llegar al primary y no volverá en un tiempo razonable. Si el primary puede volver, esperar o hacer un failover planificado siempre es mejor.

Fases de la guía

• Comprobación de estado del AG — Panel del AG: réplicas, bases de datos, preparación para el failover · Estado del cluster (WSFC) · Estado del cluster (Pacemaker) · Últimos cambios de rol (AlwaysOn_health)
• Diagnóstico del retraso y del crecimiento del log — Diagnóstico: colas, velocidades y tiempo estimado para ponerse al día (primary) · Diagnóstico: esperas de commit (primary) · Diagnóstico: ¿está bloqueado el redo? (en los secondary) · Opciones de solución y comprobación del log
• Failover planificado — Diagnóstico: ¿está el destino preparado para el failover? (…) · Red de seguridad: ¿hay transacciones largas o jobs en ejecución? (primary) · Failover: que … sea el primary (T-SQL) · Failover: que … sea el primary (pcs) · Verificar: nuevo primary y listener
• Failover forzado (puede haber pérdida de datos) — Diagnóstico: estado del destino y posible pérdida de datos (…) · Iniciar el WSFC forzando el quórum (…) · Impedir que Pacemaker gestione el recurso del AG (…) · Failover forzado: que … sea el primary · Verificar: el nuevo primary está abierto y los demás SUSPENDED · Tomar un snapshot en el antiguo primary para recuperar los datos perdidos (…, cuando vuelva) …
• Suspender / reanudar el movimiento de datos — Diagnóstico: bases de datos suspendidas y motivo · …Suspender el movimiento de datos (SUSPEND)…Reanudar el movimiento de datos (RESUME)… · Verificar y supervisar
• Cambio del availability mode — Diagnóstico: modos actuales y protección del commit · … → … · Ajustar la protección del commit (Windows) · Ajustar la protección del commit (Pacemaker) · Verificar
• Añadir una base de datos al AG — Diagnóstico: ¿es apta la base de datos para el AG? (primary) · Preparar: recovery FULL y backup (primary) · Pasar las réplicas a seeding manual (primary) · Añadir la base de datos al AG (primary) · Seguir el seeding (primary) · Preparar en el secondary desde backup (NORECOVERY): … …
• Añadir réplica — Añadir el nuevo nodo al WSFC (primary) · Habilitar Always On (nuevo nodo) · Crear el endpoint y conceder permisos (nuevo nodo) · Preparar el nuevo nodo: agente HA, Always On, software de cluster · Copiar el certificado del endpoint al nuevo nodo (primary) · Certificado, endpoint y login de Pacemaker (nuevo nodo) …
• Quitar una réplica — Diagnóstico: réplica que se quita y estructura restante · Quitar el nodo del cluster de Pacemaker (primary) · Quitar la réplica del AG (primary) · Quitar el nodo del WSFC (opcional) · Limpiar las bases de datos RESTORING del nodo retirado (…)
• Read-only routing — Diagnóstico: permisos de lectura y routing actual · Definir las URL de routing y las listas (primary) · Verificar: lista de routing · Prueba: ¿adónde va una conexión ReadOnly? · Prueba: ¿adónde va una conexión ReadOnly?
• Listener — Diagnóstico: listeners actuales · Crear el recurso de IP virtual y los constraints (Pacemaker) · …Crear el listener…Cambiar el puerto del listener…Añadir una IP al listener… (primary) · Ajustes de firewall y DNS · Ajustes del firewall · Verificar: conexión a través del listener