Las dos lecciones anteriores diseñaron sistemas nuevos con libertad total. Esta es distinta, y por eso se parece mucho más a lo que te vas a encontrar en un proyecto real. El portal de contenidos y el blog corporativo de Contoso Airlines —noticias de la aerolínea, guías de destinos, avisos de operaciones y la sala de prensa— es un WordPress que lleva ocho años funcionando sobre un MySQL 5.7 instalado en un servidor del sótano de la oficina de Barcelona. Tiene 14 GB de datos, 40.000 artículos, plugins de terceros, copias de seguridad en un disco USB que nadie ha probado a restaurar y, sobre todo, una regla clara de dirección: no se reescribe nada.

El objetivo es llevárselo a Azure tal cual, ganando copias automáticas, alta disponibilidad y parcheo, sin tocar una línea de PHP. Eso es exactamente lo que hace Azure Database for MySQL - Servidor flexible, y esta lección lo despliega, lo conecta a la red privada y ejecuta la migración con su ventana de mantenimiento acordada.

Aviso de coste: un servidor flexible de nivel De uso general con 2 vCores ronda los 120-150 € al mes más almacenamiento, y la alta disponibilidad con redundancia de zona duplica el cómputo. La buena noticia frente a Azure SQL Database es que aquí sí se puede detener el servidor (hasta 30 días seguidos), lo que en desarrollo cambia por completo la factura. Aun así, elimina el grupo de recursos de laboratorio al terminar.

1. El punto de partida y qué hay que conservar
2. Servidor flexible: qué gestiona Azure y qué sigues gestionando tú
3. Niveles de cómputo y almacenamiento
4. Alta disponibilidad y su coste
5. Despliegue con Azure CLI y acceso privado
6. Parámetros del servidor
7. Réplicas de lectura para el tráfico del blog
8. Copias de seguridad, retención y restauración
9. La migración desde el servidor de Barcelona
10. Detener el servidor para ahorrar en desarrollo
11. Conexión segura por TLS y qué cambia en la aplicación
12. Errores Comunes y Consejos
13. Ejercicios
14. Conclusión

Ese último dato es el que gobierna toda la lección: una ventana de cuatro horas permite una migración fuera de línea, que es mucho más simple que una en línea. Si el corte admisible fuera de minutos, la estrategia cambiaría.

Servidor flexible es el modelo de despliegue actual del servicio (el antiguo "servidor único" está en retirada y no debe usarse en proyectos nuevos). Cada servidor es una instancia de MySQL sobre una máquina virtual gestionada, con almacenamiento remoto redundante, integrable directamente en tu red virtual y con control fino de parámetros y ventanas de mantenimiento.

La frontera es nítida: Azure se ocupa de la máquina y del proceso; tú sigues siendo responsable de todo lo que hay dentro de la base de datos. Migrar a PaaS no convierte un esquema malo en uno bueno.

La trampa del nivel Ampliable es que funciona perfectamente hasta que se agotan los créditos de CPU, y entonces el rendimiento se desploma justo cuando hay tráfico. Sirve para el entorno de desarrollo del portal, no para el portal.

El almacenamiento tiene un detalle que casi nadie mira: las IOPS van ligadas al tamaño aprovisionado. Un disco de 32 GB ofrece muy pocas operaciones por segundo, y ampliarlo es la forma más barata de arreglar un problema de E/S. Se puede activar el crecimiento automático, muy recomendable porque quedarse sin espacio deja el servidor en solo lectura, y en los niveles superiores se pueden aprovisionar IOPS por encima de lo que corresponde al tamaño. El almacenamiento solo se puede aumentar, nunca reducir.

Contoso elige para producción De uso general, 2 vCores, 128 GB (con margen sobre los 14 GB actuales para crecer y para tener IOPS suficientes) y para desarrollo Ampliable B1ms con 32 GB.

Dos modalidades, más la opción de no tener ninguna:

Si vas a pagar el doble, elige redundancia de zona: cuesta lo mismo que la misma zona y protege de más cosas. La modalidad de misma zona solo tiene sentido en regiones sin zonas de disponibilidad o cuando la latencia entre zonas es crítica.

Contoso activa redundancia de zona en producción —el portal es la cara pública de la aerolínea y también publica los avisos de incidencias, justo cuando más se consulta— y ninguna alta disponibilidad en desarrollo.

Hay dos métodos de conectividad y se eligen al crear el servidor, sin posibilidad de cambiarlos después:

• Acceso público con reglas de firewall: el servidor tiene nombre público y se filtra por IP. Cómodo para empezar, y una superficie de ataque permanente.
• Acceso privado con integración en red virtual: el servidor se coloca en una subred delegada y solo es accesible desde la red. No tiene punto de entrada desde internet.

Contoso elige acceso privado, por coherencia con lo hecho en pe-sql-reservas y porque el WordPress se ejecuta en App Service con integración de red virtual: nada tiene que llegar a la base desde fuera. La subred delegada es snet-integracion-app, que ya se reservó en el módulo 2 para este tipo de servicios.

Dos parámetros merecen atención especial. --private-dns-zone reutiliza la zona privada interno.contosoairlines.example del módulo 2, de modo que el servidor se resuelve por nombre interno desde toda la red. Y --charset utf8mb4: MySQL arrastra un juego de caracteres histórico llamado utf8 que no es UTF-8 completo y no admite emojis ni ciertos caracteres; usar utf8mb4 desde el principio evita el clásico artículo del blog que aparece con símbolos rotos tras la migración.

No hay acceso al fichero my.cnf, pero todos sus parámetros están expuestos como configuración del servidor. Los que se tocan en la práctica:

Sobre max_connections: subirlo sin más es una mala solución, porque cada conexión consume memoria y el máximo permitido depende del tamaño del servidor. Si la aplicación abre muchas conexiones cortas, lo correcto es agrupar conexiones en el cliente. Algunos parámetros son estáticos y exigen reiniciar el servidor; la CLI lo advierte, y ese reinicio hay que planificarlo.

El portal es un caso de manual: el 98 % del tráfico son lecturas de artículos y solo el 2 % son escrituras del equipo de comunicación. Una réplica de lectura copia el servidor de forma asíncrona y absorbe ese tráfico:

Tres advertencias imprescindibles: la réplica es asíncrona, así que puede ir unos segundos por detrás y no sirve para leer algo que se acaba de escribir; la aplicación debe dirigir explícitamente las lecturas a su nombre, lo que en WordPress se resuelve con un plugin de bases de datos separadas; y la réplica factura como un servidor completo, así que se justifica cuando el tráfico lo pide, no por defecto. Si hiciera falta promocionarla a servidor independiente, se detiene la replicación con az mysql flexible-server replica stop, operación irreversible.

Las copias son automáticas: completa diaria y del registro de transacciones cada pocos minutos, con retención configurable de 1 a 35 días y opción de redundancia geográfica hacia North Europe, que es la que se activó con --geo-redundant-backup Enabled. Contoso fija 14 días, suficiente para detectar el error típico del portal —un plugin que corrompe tablas o un borrado masivo de comentarios— sin engordar la factura.

La restauración funciona igual que en Azure SQL Database: crea un servidor nuevo, nunca sobrescribe el original.

Y la regla que se repite en todo el módulo: ese servidor restaurado factura desde el primer minuto. Se recuperan los datos, se verifican y se elimina el mismo día. Una copia probada vale infinitamente más que tres copias sin probar, así que conviene ensayar la restauración una vez al trimestre.

Dos caminos, y la elección depende del corte admisible:

Con 14 GB y una ventana de cuatro horas un domingo de madrugada, Contoso elige mysqldump en modo fuera de línea. Es más simple, y lo simple falla menos a las tres de la mañana.

Checklist previo (la semana anterior, no el mismo día):

1. Versión de origen y destino compatibles; probar antes la migración en mysql-contoso-portal-dev.
2. Inventariar juegos de caracteres y cotejamientos de todas las tablas: SELECT table_name, table_collation FROM information_schema.tables WHERE table_schema='portal_contenidos';
3. Comprobar que no se usan funcionalidades no soportadas (motor MyISAM en tablas críticas, SUPER, procedimientos que dependen del sistema de ficheros).
4. Anotar el recuento de filas de las tablas grandes: wp_posts, wp_postmeta, wp_comments.
5. Revisar usuarios y permisos: los usuarios de MySQL no viajan en un volcado normal.
6. Congelar la publicación de contenidos y avisar al equipo de comunicación.

Ejecución, con la conectividad ya montada por la VPN de sitio a sitio del módulo 2:

Verificación posterior, antes de reabrir el portal:

1. Recuento de filas por tabla, comparado con el anotado antes.
2. Comprobar acentos y emojis en artículos recientes; si aparecen rotos, el problema está en el juego de caracteres y hay que repetir el volcado, no arreglarlo a mano.
3. Recrear usuarios y permisos de aplicación con CREATE USER y GRANT mínimos (nunca el administrador para la aplicación).
4. Cambiar la cadena de conexión de WordPress y probar la web completa: portada, artículo, búsqueda, comentario, panel de administración.
5. Dejar el servidor de Barcelona apagado pero intacto dos semanas, como plan de reversión.

Esta es la diferencia práctica más agradable frente a Azure SQL Database: un servidor flexible se puede detener, y mientras está detenido no se factura cómputo (el almacenamiento sí).

Se reinicia solo tras 30 días detenido, así que no sirve como forma de "archivar" un servidor: para eso, se hace un volcado y se elimina. Combinado con un runbook de Azure Automation (07-04) que lo detiene a las 19:00 y lo arranca a las 8:00 de lunes a viernes, el entorno de desarrollo pasa a costar aproximadamente un tercio.

Azure Database for MySQL exige TLS de forma predeterminada, y así debe quedarse. Para la aplicación esto significa dos cambios pequeños pero obligatorios en la cadena de conexión: indicar el modo TLS y, si el cliente lo requiere, el certificado raíz.

Ten en cuenta que el nombre del host es el privado, resoluble solo desde la red virtual; que el usuario es uno de aplicación con permisos mínimos sobre portal_contenidos; y que la contraseña no debería estar en el fichero, sino en Key Vault, referenciada desde los ajustes de la aplicación de App Service (lección 04-03). Si un cliente antiguo no soporta TLS 1.2, la solución es actualizar el cliente, no rebajar el servidor.

• Elegir acceso público "para probar" y quedarse así. El método de conectividad no se puede cambiar después de crear el servidor: obliga a recrearlo y volver a migrar.
• Usar utf8 en lugar de utf8mb4. El utf8 de MySQL no es UTF-8 completo. Se detecta cuando los artículos aparecen con caracteres rotos y ya hay tráfico encima.
• Poner el nivel Ampliable en producción. Va bien hasta que se agotan los créditos de CPU, y eso ocurre precisamente el día de más visitas.
• Subir max_connections como respuesta a cualquier error de conexiones. Cada conexión consume memoria; la solución suele ser agrupar conexiones en la aplicación.
• Confiar en la réplica de lectura para datos recién escritos. Es asíncrona: el redactor publicaría un artículo y no lo vería en la web.
• Migrar sin contar filas antes y después. Sin ese recuento no hay forma objetiva de saber si la migración fue completa.
• Olvidar los usuarios y permisos. Un mysqldump de una base no incluye las cuentas de MySQL: si nadie las recrea, la aplicación no arranca en la ventana de corte.
• Consejo: ensaya la migración completa en el entorno de desarrollo con una copia real de los datos. La primera vez siempre aparece algo, y es mejor que aparezca un miércoles por la tarde.
• Consejo: mantén el servidor de origen apagado e intacto dos semanas. Es el plan de reversión más barato que existe.

El portal recibe 120.000 visitas al mes, con picos los lunes por la mañana cuando se publican los avisos operativos. La base ocupa 14 GB y crece unos 3 GB al año.

1. Elige nivel de cómputo, tamaño de almacenamiento y modalidad de alta disponibilidad para producción y para desarrollo, justificando cada elección.
2. ¿Qué método de conectividad eliges y por qué es una decisión que no admite arrepentimiento?
3. ¿Qué retención de copias fijarías en cada entorno?

El equipo dispone de una ventana de cuatro horas el domingo de 02:00 a 06:00.

1. Elige entre mysqldump y Azure Database Migration Service y justifícalo.
2. Escribe tres comprobaciones previas y tres posteriores, indicando qué harías si alguna falla.
3. Describe el plan de reversión si a las 05:30 el portal no funciona correctamente.

Tras la migración, el portal responde bien salvo los lunes a las 09:00, cuando algunas páginas tardan más de 10 segundos y aparecen errores de "too many connections".

1. ¿Qué parámetro del servidor activarías primero para diagnosticar, y cómo?
2. Enumera tres causas posibles, con su corrección respectiva.
3. ¿Resolvería el problema una réplica de lectura? ¿Y una simple ampliación del almacenamiento?

Solución 1:

1. Producción: De uso general con 2 vCores (la CPU dedicada evita el desplome del nivel Ampliable en el pico del lunes), 128 GB de almacenamiento —no por espacio, sino por las IOPS asociadas al tamaño y por margen de crecimiento— con crecimiento automático activado, y alta disponibilidad con redundancia de zona, ya que el portal publica los avisos de incidencias justo cuando más se consulta. Desarrollo: Ampliable B1ms, 32 GB, sin alta disponibilidad.
2. Acceso privado con integración en snet-integracion-app. No admite arrepentimiento porque el método de conectividad se fija al crear el servidor: cambiarlo obliga a crear otro servidor y repetir la migración completa.
3. Producción, 14 días con redundancia geográfica; desarrollo, 7 días sin ella, ya que los datos son una copia y son regenerables.

Solución 2:

1. mysqldump fuera de línea. Con 14 GB, el volcado y la carga caben holgadamente en cuatro horas, y no se necesita replicación continua. El servicio de migración añadiría complejidad de configuración sin resolver ningún problema real; se reservaría para volúmenes de cientos de GB o cortes de minutos.
2. Previas: (a) probar la migración completa en desarrollo —si falla, se pospone la ventana, nunca se improvisa; (b) verificar juegos de caracteres de todas las tablas —si hay mezcla, se normaliza antes; (c) anotar recuentos de filas —sin ellos no habrá verificación posible. Posteriores: (a) comparar recuentos —si no cuadran, se revierte; (b) revisar acentos y emojis —si están rotos, se repite el volcado con --default-character-set=utf8mb4; (c) probar el recorrido completo de la web, incluida la publicación de un artículo de prueba.
3. Reversión: devolver la cadena de conexión de WordPress al servidor de Barcelona, que se ha mantenido apagado pero intacto, arrancarlo, verificar el portal y reprogramar la ventana. Como la publicación de contenidos estaba congelada, no hay escrituras nuevas que perder.

Solución 3:

1. slow_query_log en ON con long_query_time en 2 segundos, y después revisar el registro para identificar las consultas que se repiten en el pico. Es la primera medida porque convierte una queja en datos.
2. Causas y correcciones: (a) consultas lentas de un plugin sobre wp_postmeta sin índice adecuado, que se corrige creando el índice o desactivando el plugin; (b) exceso de conexiones cortas por no agrupar conexiones, que se corrige con agrupación en el cliente y, secundariamente, ajustando max_connections; (c) IOPS insuficientes por un almacenamiento pequeño, que se corrige ampliando el disco o aprovisionando IOPS adicionales.
3. Una réplica de lectura sí ayudaría, porque el 98 % del tráfico son lecturas y repartirlas alivia el servidor principal, pero requiere que la aplicación dirija las lecturas a la réplica. Ampliar el almacenamiento ayuda solo si el cuello de botella son las IOPS; si el problema son consultas mal indexadas o conexiones, no cambia nada y solo sube la factura. Por eso el diagnóstico va primero.

Has llevado a Azure un sistema heredado sin reescribir una línea, que es la migración más frecuente y menos glamurosa de cualquier proyecto real. Sabes qué es Azure Database for MySQL - Servidor flexible, dónde está la frontera entre lo que gestiona Azure y lo que sigue siendo tuyo, y por qué el modelo de servidor único ya no se usa. Distingues los niveles Ampliable, De uso general y Optimizado para memoria y conoces la trampa de los créditos de CPU, además de la relación entre tamaño de almacenamiento e IOPS y por qué conviene el crecimiento automático. Has comparado la alta disponibilidad de misma zona frente a redundancia de zona —mismo precio, más protección— y has desplegado mysql-contoso-portal-pro con acceso privado en snet-integracion-app y su zona DNS interna, sabiendo que ese método de conectividad no se puede cambiar después.

Has ajustado los parámetros que realmente se tocan —max_connections, slow_query_log, character_set_server con utf8mb4 para que los acentos y los emojis no se rompan—, añadido una réplica de lectura para el 98 % de tráfico de lectura del blog con sus tres advertencias, configurado copias con 14 días de retención y restaurado a un servidor nuevo que hay que eliminar el mismo día. Y sobre todo has ejecutado la migración: la comparación entre mysqldump y Azure Database Migration Service, la elección del modo fuera de línea por la ventana de cuatro horas, el checklist previo, los comandos de volcado y carga, la verificación posterior con recuentos de filas y el plan de reversión de dos semanas. Cierras con dos detalles muy prácticos: que este servicio sí permite detener el servidor para no pagar cómputo en desarrollo y qué cambia exactamente en la cadena de conexión al forzar TLS.

El siguiente sistema del mapa de datos también viene de fuera, pero por un motivo opuesto. El sistema de planificación de tripulaciones de Contoso no usa PostgreSQL por casualidad: lo eligió porque necesita consultas complejas sobre turnos y descansos, tipos de datos ricos y extensiones que no existen en otros motores, en particular cálculos geográficos de distancias y rutas entre aeropuertos. En Azure Database for PostgreSQL verás lo que comparte con lo que acabas de aprender —que es mucho, y lo marcaremos explícitamente para no repetirlo— y, sobre todo, lo diferencial: las extensiones y su lista de permitidas, con postgis para las rutas y pgvector mirando ya hacia los servicios de IA del módulo 6, el ajuste de rendimiento con EXPLAIN ANALYZE, el problema del autovacuum en tablas con mucha rotación y la agrupación de conexiones con PgBouncer.