Operación diaria y escenarios de fallo de MySQL InnoDB Cluster (MySQL Shell 8.4)

No es una instalación: un runbook por escenarios para la operación diaria y la recuperación ante fallos de un InnoDB Cluster que ya está en marcha (Group Replication + MySQL Router, desplegado con la AdminAPI de MySQL Shell). Elija una tarjeta de escenario: comprobación de estado, añadir miembros (clone / incremental) y quitarlos (incluido force), reincorporar un miembro caído, reiniciar después de que se haya caído todo el cluster (rebootClusterFromCompleteOutage), forceQuorumUsingPartitionOf tras perder la mayoría, cambio planificado de primary, añadir Router / repetir su bootstrap, opciones del cluster (consistency, expelTimeout, memberWeight, autoRejoinTries, exitStateAction) y rescan() para los metadatos. Cada escenario sigue el orden diagnóstico → red de seguridad → ejecución → verificación → después. Si va a montar el cluster por primera vez, abra la guía de instalación de InnoDB Cluster; para la replicación clásica source–replica, la guía de operación de replicación; para la migración 8.0 → 8.4, la guía de upgrade.

Topología: 3–9 nodos MySQL (single-primary) + MySQL Router

Escenarios

• Estado del cluster y comprobación de salud (¿va todo bien?) — Solo lectura: cluster.status({extended: 1}), rol/estado/versión de los miembros, colas del applier, lista de Routers y error log; no se modifica nada, sin interrupción. Empiece aquí si no está seguro o si ha saltado una alerta; el último paso le lleva al escenario adecuado.
• Añadir un miembro nuevo (addInstance: clone / incremental) — Quiere añadir un nuevo nodo MySQL al cluster, aumentar la tolerancia a fallos (3 → 5) o recuperar un nodo que se había quitado. El cluster sigue aceptando escrituras; durante el clone el donor soporta carga de disco/red y el nodo nuevo se reinicia.
• Quitar un miembro (removeInstance, con force si hace falta) — Quiere quitar un nodo del cluster de forma permanente (devolución de hardware, reducción) o el nodo se ha perdido y hay que borrarlo de los metadatos (force). Quitar un secondary no causa interrupción; quitar el primary provoca una interrupción de escritura de unos segundos.
• Reincorporar un miembro caído (MISSING / ERROR / OFFLINE) — Un miembro se reinició, perdió la red o fue expulsado del grupo (expelled); la mayoría funciona y la aplicación puede escribir. Con rejoinInstance el miembro recupera lo que le falta y vuelve; el cluster no sufre interrupción.
• Todo el cluster se ha caído: reiniciarlo (rebootClusterFromCompleteOutage) — Por un corte eléctrico, del centro de datos o del hipervisor, todos los nodos se apagaron y volvieron a arrancar; Group Replication no funciona en ningún miembro y la aplicación no puede escribir (la interrupción continúa). El cluster se reinicia desde el miembro más actualizado.
• Pérdida de la mayoría (NO_QUORUM): forzar el quorum con los miembros restantes — La mayoría de los miembros se perdió a la vez (p. ej., 2 de 3) y los restantes dejaron de escribir con NO_QUORUM (las escrituras se quedan bloqueadas). Si está seguro de que los miembros perdidos están realmente apagados, el cluster vuelve a funcionar con la partición restante. Un uso incorrecto provoca split-brain; la pérdida de un solo miembro (la mayoría sigue en pie) no es este escenario.
• Cambio planificado de primary (setPrimaryInstance) — Quiere traspasar de forma planificada el rol de primary a un secondary concreto por mantenimiento (parches del SO, hardware), reparto de carga o un simulacro de DR. Las escrituras esperan unos segundos y las transacciones abiertas se terminan; Router redirige solo al nuevo primary.
• Añadir un Router o volver a hacer su bootstrap — Quiere instalar Router en un nuevo servidor de aplicaciones, volver a hacer el bootstrap de Router (actualización de versión, cluster recreado, aviso routerErrors) o limpiar registros antiguos de Router. Durante el nuevo bootstrap, las conexiones de la aplicación a ese Router se cortan brevemente.
• Cambiar opciones del cluster (consistency, expelTimeout, memberWeight…) — Quiere ajustar la consistencia en el failover, el tiempo tras el que se expulsa a un miembro cuando la red oscila, la prioridad de failover, la reincorporación automática o el comportamiento del miembro ante un error. Se cambia con el cluster en marcha, sin reinicio; consistency se aplica a las sesiones nuevas.
• Sincronizar los metadatos con el grupo real (rescan) — cluster.status() menciona un miembro que no está en los metadatos o un registro antiguo que ya no está en el grupo (se hizo START GROUP_REPLICATION a mano, no se eliminó un miembro antiguo, se reinstaló un servidor). Sin interrupción; solo se actualizan los metadatos.

Antes de empezar

• En los nodos afectados están instalados MySQL Shell … y MySQL …; el cluster se creó con AdminAPI siguiendo la guía de instalación de InnoDB Cluster o de forma equivalente (existen los metadatos). El root del sistema operativo puede conectarse sin contraseña con el mysql local. Tome el nombre del cluster del formulario de dba.getCluster().getName() y las direcciones de los miembros de las líneas ip:port de la topología de cluster.status().
• Se conoce la contraseña de la cuenta … (la misma en cada nodo). MySQL Shell pide la contraseña en cada conexión; con --save-passwords=never no la guarda.
• Los nodos se alcanzan entre sí por los puertos de MySQL (……:……, ……) y por los puertos de comunicación de Group Replication.
• En el nodo nuevo está instalado MySQL … con la misma versión menor que los miembros del cluster (requisito de clone), GTID activado, un server_id distinto del de los demás nodos y la configuración de Group Replication de la guía de instalación en my.cnf; los puertos de firewall/SELinux están abiertos.
• El servidor de Router accede a los nodos por el puerto de MySQL… y puede salir a repo.mysql.com….
• Están preparados la aprobación del cambio, la ventana de mantenimiento (si hace falta) y la comunicación con el equipo de aplicación.

Fases de la guía

• Estado: cluster, miembros y Router (solo lectura) — Obtener y guardar el estado detallado del cluster · Comprobar los miembros y las colas con SQL · Revisar los registros de error de Group Replication · Comprobar el enrutamiento RW/RO a través de Router · Interpretar el resultado y elegir el escenario correcto
• 1. Diagnóstico: ¿están listos el nodo nuevo y el cluster? — Comprobar la versión y la identidad del nodo nuevo · Comprobar el estado del cluster y las versiones de los miembros
• 2. Red de seguridad — Guardar la topología actual
• 3. Ejecución: añadir el miembro — Configurar el nodo nuevo y crear la cuenta de administración · Validar el nodo nuevo desde el cluster · Añadir el nodo al cluster (…)
• 4. Verificación — Verificar que el miembro nuevo está ONLINE
• 5. Después — Actualizar Router, la monitorización y el inventario
• 1. Diagnóstico: ¿es seguro quitar el miembro? — Mostrar el estado del miembro de destino y la tolerancia que queda
• 2. Red de seguridad — Guardar la topología actual
• 3. Ejecución: quitar el miembro — Quitar el miembro del cluster… (force)…
• Si vuelve el nodo quitado con force — Detener y limpiar Group Replication en el nodo que ha vuelto
• 4. Verificación — Verificar los miembros restantes
• 5. Después — Número impar, Router y monitorización
• 1. Diagnóstico: ¿por qué cayó el miembro y puede reincorporarse? — Estado del miembro de destino desde el punto de vista del cluster · Mostrar el estado de MySQL y de Group Replication en el nodo de destino · Comprobación de transacciones errant (en el destino pero no en el cluster)
• 2. Red de seguridad — Guardar el estado actual
• 3. Ejecución: reincorporar el miembro — Reincorporar el miembro con rejoinInstance
• 4. Verificación — Verificar que el miembro está ONLINE
• 5. Después — Causa raíz y reincorporación automática
• 1. Diagnóstico: ¿está realmente caído todo el cluster? ¿Cuál es el miembro más actualizado? — Iniciar MySQL en cada nodo y mostrar el estado de Group Replication · Preguntar a Shell cuál es el miembro más actualizado (dryRun)
• 2. Red de seguridad — Guardar el conjunto de GTID de todos los nodos
• 3. Ejecución: arrancar el cluster desde el miembro más actualizado — Reiniciar el cluster
• 4. Verificación — Verificar que todos los miembros están ONLINE
• 5. Después — Router, aplicación y causa raíz
• 1. Diagnóstico: ¿se ha perdido realmente el quorum? — Mostrar el estado del cluster desde el nodo que sigue en pie
• 2. Red de seguridad: aislar los miembros perdidos — Asegurarse de que los nodos perdidos están apagados (fencing) · Guardar el estado de la partición restante
• 3. Ejecución: forzar el quorum — Formar el quorum con la partición restante
• 4. Verificación y recuperación de los miembros perdidos — Verificar que las escrituras están habilitadas · Reincorporar los miembros perdidos (…)
• 5. Después — Revisar la topología
• 1. Diagnóstico: ¿puede el destino ser primary? — Comprobar el estado y las versiones de los miembros
• 2. Red de seguridad — Guardar el estado actual
• 3. Ejecución: cambiar el primary — Traspasar el rol de primary a …