Upgrade de MySQL 8.0 → 8.4 LTS (in-place)

Actualiza un MySQL 8.0 instalado a 8.4 LTS en el mismo servidor (in-place): servidor único, source + replicas (primero las replicas, el source al final) o InnoDB Cluster (Router → Shell → metadata → secondaries de uno en uno → el primary al final). Incluye en cada servidor la comprobación previa util.checkForServerUpgrade, las variables eliminadas en 8.4 y mysql_native_password desactivado por defecto, un punto de vuelta atrás con copia en frío, la verificación y un runbook para volver a 8.0. Como el downgrade no está soportado, la única forma de volver atrás es la copia previa al upgrade. Para migrar trasladando a servidores nuevos (dump/load), use el modo "Migrar a otro servidor" de la guía de backup lógico.

Topología: 1 servidor, source + replicas o InnoDB Cluster (3+ miembros + servidores de MySQL Router)

Antes de empezar

• Los servidores tienen la última versión menor de MySQL 8.0 (8.0.4x), instalada desde el repositorio oficial de MySQL. El paso directo de 8.0 a 8.4 está soportado; el paso directo de 5.7 a 8.4 no está soportado (primero a 8.0).
• Hay espacio libre en … igual al tamaño del directorio de datos + binlog (para la copia en frío).
• Existe un backup reciente correcto (XtraBackup 8.0 o mysqldump) y una prueba de restauración. Después del upgrade hay que pasar a XtraBackup 8.4 (la versión 8.0 no puede hacer backup de un servidor 8.4).
• Se ha verificado en un entorno de pruebas que la aplicación y los drivers cliente (JDBC, PHP mysqlnd, Python…) soportan MySQL 8.4 y caching_sha2_password.
• La ventana de mantenimiento está aprobada…; como las replicas se actualizan de una en una, el tráfico de lectura puede reducirse, y hay interrupción de escrituras mientras se actualiza el source….
• La retención de binlogs en el source es mayor que la duración del upgrade de las replicas (los binlogs que necesitan las replicas detenidas no deben purgarse).
• El cluster está sano: todos los miembros ONLINE, modo single-primary; el primer miembro del formulario es el primary actual. No inicie el upgrade si hay un miembro RECOVERING o un estado OK_PARTIAL / OK_NO_TOLERANCE.
• La cuenta de administración del cluster … puede conectarse a todos los miembros por el puerto … y se conoce su contraseña (MySQL Shell la pide en cada conexión).
• En los servidores de Router, MySQL Router está instalado desde el repositorio oficial de MySQL y se ejecuta como servicio systemd (mysqlrouter). Si el tráfico de la aplicación llega a través de varios Routers, los Routers se actualizan de uno en uno.
• La aplicación se conecta solo a través de Router (una aplicación que se conecta directamente al nombre de un miembro no puede escribir cuando cambia el rol de primary).

Fases de la guía

• Comprobación previa — Estado actual · Añadir el repositorio de 8.4 e instalar MySQL Shell 8.4 · Ejecutar el Upgrade Checker · Buscar variables eliminadas en la configuración · Migrar las cuentas mysql_native_password
• Comprobación previa de InnoDB Cluster — Registrar el estado del cluster y los Routers · Comprobar si hace falta un upgrade de la metadata (dryRun)
• Upgrade de la metadata — Ejecutar dba.upgradeMetadata()
• Preparación del cambio de primary — Verificar que los secondaries están en 8.4 y ONLINE
• Comprobación final de InnoDB Cluster — Comprobar el estado extendido del cluster · Devolver el rol de primary al primer miembro
• Después del upgrade — Comprobar la replicación (…) · Pasar XtraBackup a 8.4 y hacer un nuevo backup full · Migrar las cuentas mysql_native_password (solución definitiva) · Decisión de borrar la copia de vuelta atrás
• Vuelta atrás (regreso a 8.0) — Vuelta atrás: detener 8.4 y apartar el directorio de datos · Vuelta atrás: detener 8.4 y apartar el directorio de datos · Vuelta atrás: volver al software 8.0 · Vuelta atrás: volver al software 8.0 · Vuelta atrás: restaurar la copia en frío · Vuelta atrás: restaurar la copia en frío …