MariaDB 13.0 en Docker: qué trae y si te conviene actualizar

MariaDB 13.0.2 es estable desde el 15 de septiembre de 2026, pero es una versión rolling: la Fundación MariaDB le da soporte comunitario solo hasta el cuarto trimestre de 2026, frente al 12 de junio de 2029 de la 12.3 LTS. Trae el archivado del redo log de InnoDB (innodb_log_archive), UPDATE ... RETURNING, nombres implícitos para los hints del optimizador y metadatos de variables obsoletas. Lo he probado en Docker sobre aarch64 y he actualizado dos directorios de datos reales, uno de 12.3.3 y otro de 11.8.9, para ver qué se rompe. Tienes también la versión en inglés de este análisis.

Puntos clave

• MariaDB 13.0 es rolling, no LTS: su soporte comunitario acaba en el cuarto trimestre de 2026, y la etiqueta mariadb:latest de Docker Hub ya apunta a 13.0.2 mientras que mariadb:lts sigue en 12.3.3.
• Un directorio de datos de 12.3.3 arrancó en 13.0.2 sin MARIADB_AUTO_UPGRADE; mariadb-upgrade detectó el salto de versión mayor y pasó sus 8 fases sin errores.
• Desde 11.8.9, mariadb-upgrade también lo dio todo por bueno, pero un procedimiento con una variable llamada to_date falló al llamarlo, porque TO_DATE es palabra reservada desde la 12.3.
• Con innodb_log_archive=ON, InnoDB sustituye ib_logfile0 por ficheros ib_<lsn>.log de 32 MiB que pasan a solo lectura; mariadb-backup falla con "cannot read redo log header".
• Con sysbench oltp_write_only en 4 CPU, el archivado bajó la mediana de 6 073 a 5 883 transacciones por segundo (3,1 %, dentro del ruido), pero dejó hasta 1,5 GiB de redo en un minuto.
• La recuperación a un punto en el tiempo funcionó hasta el final de un fichero archivado, pero ningún LSN intermedio como destino: el servidor respondió "cannot fulfill innodb_log_recovery_target" en todas las pruebas.
• Las notas de mariadb.com anuncian CREATE OR REPLACE TABLE atómico, pero el anuncio de la versión estable y la incidencia MDEV-25292 en Jira dicen que no ha llegado a la 13.0.

Qué es MariaDB 13.0 y cuánto tiempo tendrá soporte

MariaDB 13.0 es la serie estable más reciente del canal rolling, el que publica funciones nuevas cada trimestre. La política de mantenimiento de la Fundación MariaDB^[1] promete una LTS al año, con binarios comunitarios durante 3 años, y anuncia las rolling cada trimestre. El anuncio de la versión estable^[2], firmado por Frédéric Descamps, lo resume así: "Stable describes the maturity of the release. Rolling describes its update path."

Estas son las fechas que publica la Fundación para las series que un servidor en producción puede tener hoy:

El calendario de la Fundación marca la 13.3 como la próxima LTS. En octubre de 2026, a la 13.0 le quedan como mucho tres meses de parches: quien adopte la rolling se compromete a pasar a la 13.1 y a las siguientes cada trimestre. La página de todas las versiones^[3] ya lista la 13.1.1 RC y la 13.2.0 preview.

En Docker Hub la diferencia importa más de lo que parece. El 28 de septiembre de 2026, mariadb:latest, mariadb:13 y mariadb:13.0 compartían el digest de 13.0.2, y mariadb:lts y mariadb:12.3 el de 12.3.3. Un compose.yaml con image: mariadb:latest y un volumen de datos pasa a una rolling en el siguiente docker compose pull.

Qué trae MariaDB 13.0 y qué se quedó fuera

Las notas de la versión 13.0.2^[4] la describen como "an evolution of MariaDB 12.3 with several entirely new features". Estas son las novedades, con las que probé marcadas:

• innodb_log_archive (MDEV-37949): conserva el redo log en ficheros sucesivos en vez de sobrescribir un búfer circular. Probado.
• UPDATE ... RETURNING (MDEV-5092) para tablas sueltas, con OLD_VALUE() para leer el valor anterior. Probado.
• Nombres implícitos de bloque para vistas, CTE y tablas derivadas, y la forma QB_NAME(nombre, ruta) (MDEV-38045). Probado.
• IS_DEPRECATED y DEPRECATED_REPLACEMENT en INFORMATION_SCHEMA.SYSTEM_VARIABLES (MDEV-35369). Probado.
• binlog_row_event_max_size sube su valor por defecto a 64 KB (MDEV-37608). Probado.
• TYPE ... IS REF CURSOR y RECORD como parámetro o RETURN de rutinas de paquete, en modo Oracle. No probado.
• Resúmenes de Performance Schema con XXH3_128, formato de fecha configurable en el plugin de auditoría, init_rpl_role visible en SHOW VARIABLES y default_master_connection global.

Dos funciones del anuncio de la preview no han llegado. Descamps lo avisa en el anuncio estable: la traza del optimizador con las estadísticas usadas (MDEV-38701) y el CREATE OR REPLACE TABLE atómico (MDEV-25292) "didn’t make it to the release yet". Las notas de mariadb.com, en cambio, siguen listando las dos. Consulté Jira el 28 de septiembre: MDEV-25292^[5] está en estado "Stalled" con versión objetivo 13.2, y MDEV-38701 se cerró en la 13.1.1.

El motor de almacenamiento DuckDB que menciona el anuncio es un paquete aparte (MariaDB-duckdb-engine, en fase gamma). La imagen oficial de Docker 13.0.2 no lo incluye: su directorio de plugins no tiene ningún ha_duckdb.

Cómo monté el laboratorio en Docker

Usé las imágenes oficiales mariadb:13.0.2, mariadb:12.3.3 y mariadb:11.8.9 de Docker Hub en una máquina virtual aarch64 de OrbStack sobre Apple silicon, con 18 núcleos y 47 GB de RAM, compartida con otras pruebas. La imagen 13.0.2 ocupa 531 MB en disco sobre Ubuntu 26.04.1, y la 12.3.3, 486 MB sobre Ubuntu 24.04.5. Si partes de cero, la guía para instalar MariaDB con Docker cubre el arranque básico.

Cada directorio de datos se sembró con la versión antigua: una base tienda con 20 000 clientes, 200 000 pedidos, una vista, un procedimiento almacenado y un usuario con mysql_native_password. Los contenedores llevan el prefijo b6p3 de mi laboratorio y los datos viven en carpetas enlazadas, para poder copiarlas entre versiones:

docker run -d --name b6p3-v123 -v "$PWD/data/v123:/var/lib/mysql" \
  -e MARIADB_ROOT_PASSWORD=root_pass mariadb:12.3.3
docker exec -i b6p3-v123 mariadb -uroot -proot_pass --force < lab/seed.sql

Antes de cada prueba copié la carpeta con cp -a, así cada actualización partía del mismo estado. Es la misma copia en frío que te conviene hacer antes de tocar un servidor real, porque una bajada de versión mayor no está soportada.

Actualizar de MariaDB 12.3 a 13.0 con mariadb-upgrade

La actualización desde la 12.3 LTS funcionó sin cambios en los datos, pero la imagen no la completa sola. Arranqué 13.0.2 sobre la copia del directorio de 12.3.3 sin la variable MARIADB_AUTO_UPGRADE:

docker run -d --name b6p3-up123 -v "$PWD/data/up123:/var/lib/mysql" \
  -e MARIADB_ROOT_PASSWORD=root_pass mariadb:13.0.2
docker logs b6p3-up123 2>&1 | grep -i upgrade

El entrypoint avisó de que la actualización hacía falta y la saltó: "MariaDB upgrade (mariadb-upgrade or creating healthcheck users) required, but skipped due to $MARIADB_AUTO_UPGRADE setting". El servidor aceptó conexiones igualmente. La referencia de mariadb-upgrade^[6] lo explica: "The MariaDB server never performs the upgrade itself". Los paquetes de Debian y Ubuntu lo lanzan por ti; un contenedor, no.

El paso manual lee la versión anterior del fichero mariadb_upgrade_info del directorio de datos:

docker exec b6p3-up123 mariadb-upgrade -uroot -proot_pass
# Major version upgrade detected from 12.3.3-MariaDB to 13.0.2-MariaDB.
# Phase 1/8: Checking and upgrading mysql database
# ...
# Phase 8/8: Running 'FLUSH PRIVILEGES'
# OK

Las 8 fases revisaron las tablas de mysql, las vistas de sys, la vista tienda.v_pedidos_es y las dos tablas de datos, y todas dieron OK. En tres repeticiones sobre copias del mismo directorio de 185 MB, mariadb-upgrade tardó una mediana de 2,25 s (entre 2,04 y 2,68 s), con el contenedor ya arrancado. Una segunda ejecución respondió "This installation of MariaDB is already upgraded to 13.0.2-MariaDB". Los usuarios con mysql_native_password siguieron entrando sin cambios.

No existe todavía una guía oficial "Upgrading from MariaDB 12.3 to 13.0" en la documentación: el índice llms.txt de mariadb.com llega hasta la de 11.8 a 12.3.

Qué se rompe al saltar de 11.8 a 13.0

El salto directo desde la 11.8 LTS arrastra los cambios de la 12.x, y el que me mordió no lo detecta ninguna herramienta. Esta vez usé MARIADB_AUTO_UPGRADE=1 y dejé en my.cnf la opción big_tables = 1, que la guía de 11.8 a 12.3^[7] manda quitar porque se eliminó en la 12.0.

El servidor no se negó a arrancar. Solo escribió un aviso: "’big-tables’ was removed. It does nothing now and exists only for compatibility with old my.cnf files". El entrypoint guardó una copia del esquema de sistema en system_mysql_backup_11.8.9-MariaDB.sql.zst, ejecutó mariadb-upgrade y arrancó el servidor definitivo.

El problema apareció después. En la 11.8 creé un procedimiento que declara una variable llamada to_date, algo válido entonces. La 12.3 convirtió TO_DATE y CONVERSION en palabras reservadas, y la 13.0 hereda el cambio:

CALL resumen('2025-01-01');
-- ERROR 1457 (HY000): Failed to load routine tienda.resumen
-- (internal code -6). For more details, run SHOW WARNINGS
SHOW WARNINGS;
-- Error 1064: You have an error in your SQL syntax; ...
-- near 'to_date DATE DEFAULT CURRENT_DATE; ...'

mariadb-upgrade no lo ve porque el cuerpo de una rutina se analiza al llamarla, no al actualizar: incluso con --force marcó mysql.proc como OK. La vista INFORMATION_SCHEMA.ROUTINES sí guarda el texto, así que una búsqueda antes de actualizar encuentra los candidatos:

SELECT ROUTINE_SCHEMA, ROUTINE_NAME
FROM information_schema.ROUTINES
WHERE ROUTINE_DEFINITION REGEXP '\\b(to_date|conversion)\\b';

En mi caso devolvió tienda.resumen. La consulta da falsos positivos si la palabra aparece en un comentario o en una cadena, pero es más barata que descubrir el fallo en producción.

Cómo funciona el archivado del redo log

El archivado sustituye el búfer circular de InnoDB por una secuencia de ficheros que no se sobrescriben, pensada para recuperaciones a un punto en el tiempo y copias incrementales. La variable es dinámica y se activa en caliente:

SET GLOBAL innodb_log_archive = ON;
SHOW GLOBAL STATUS LIKE 'innodb_lsn%';
-- Innodb_lsn_current         24373947
-- Innodb_lsn_last_checkpoint 24373931
-- Innodb_lsn_archived        24373931

Al instante, ib_logfile0 desapareció del directorio de datos y en su lugar apareció ib_000000000173eaab.log. El nombre es el LSN en hexadecimal: 0x173eaab es 24 373 931, el mismo valor de Innodb_lsn_archived. Cada fichero mide lo que diga innodb_log_file_size, 32 MiB en mi configuración.

Tras seis UPDATE de los 200 000 pedidos había cuatro ficheros, 128 MB en disco: dos en solo lectura (-r--r-----), el actual y uno reservado por adelantado. Los nombres avanzan de 0x1FFD000 en 0x1FFD000, es decir, 32 MiB menos la cabecera de 12 KiB que describe la página de InnoDB Log Archiving^[8]. Según esa página, un fichero pasa a solo lectura cuando se completa un checkpoint en el siguiente, y ese es el momento de moverlo a otro almacenamiento.

Qué falla con el archivado activado

El archivado cambia el formato del redo log, y cuatro cosas dejaron de funcionar en mis pruebas:

• mariadb-backup se detiene con "Error: cannot read redo log header" y código de salida 1. Las notas lo reconocen: todavía no hay herramienta de copia que entienda este formato.
• Activarlo en my.cnf antes que en caliente impide arrancar: "[ERROR] InnoDB: innodb_log_archive=ON but ./ib_logfile0 exists". Primero SET GLOBAL, después el fichero de configuración.
• Volver a la 12.3.3 falla con "[ERROR] InnoDB: File ./ib_logfile0 was not found". Con SET GLOBAL innodb_log_archive = OFF, la 13.0 recreó ib_logfile0, borró los ficheros escribibles y dejó los de solo lectura; después la 12.3.3 arrancó y leyó los 200 000 pedidos.
• Reiniciar sin la variable en la configuración no lo desactiva: el servidor volvió con @@innodb_log_archive a 1 al encontrar los ficheros. Pero Innodb_lsn_archived pasó de 24 373 931 a 96 524 445 aunque los ficheros antiguos seguían en su sitio.

Si tu copia de seguridad diaria es mariadb-backup, activar el archivado la rompe hoy. Una copia de los ficheros con restic sobre una parada limpia sigue funcionando, pero pierdes la copia en caliente.

Cuánto cuesta el archivado en escrituras

En mi prueba, el archivado restó un 3,1 % de transacciones por segundo, menos que la variación entre ejecuciones. Usé sysbench 1.0.20 con oltp_write_only: 4 tablas de 250 000 filas, 8 hilos y 60 s por ejecución. El servidor 13.0.2 corría con --cpus 4 --memory 4g, 1 GB de buffer pool e innodb_log_file_size de 256 MiB, sobre un directorio nuevo en cada ejecución. Alterné tres ejecuciones con el archivado desactivado y tres activado, y cada una arrancó con una carga del equipo entre 2,78 y 2,98:

Las ejecuciones sin archivado fueron de 5 698 a 6 207 transacciones por segundo, así que la diferencia entra en el ruido de un equipo compartido y virtualizado. El coste que sí se ve es el disco. En un minuto de escrituras, el archivado dejó entre 5 y 6 ficheros de 256 MiB, y crecerá mientras no los muevas a otro almacenamiento.

Recuperar a un punto en el tiempo con los ficheros archivados

La guía de recuperación con el archivado^[9] usa dos opciones de arranque: innodb_log_recovery_start, el LSN donde empieza la reproducción, e innodb_log_recovery_target, donde termina. Lo ensayé con una copia en frío del directorio y tres cambios posteriores. Primero, 1 000 filas marcadas como lote1 y otras 1 000 como lote2; después, un UPDATE de 200 000 filas que no llegó a completarse en el primer fichero.

El LSN de inicio tiene que coincidir con un checkpoint registrado en la cabecera. Con el valor de Innodb_lsn_last_checkpoint (24 375 896) respondió "Did not find innodb_log_recovery_start=24375896 in ib_000000000173eaab.log". La cabecera guarda desplazamientos de 64 bits en big-endian, y este script los traduce a LSN:

import struct, sys, os
for path in sys.argv[1:]:
    base = int(os.path.basename(path)[3:19], 16)
    h = open(path, 'rb').read(12288)
    offs = [struct.unpack('>Q', h[i:i+8])[0] for i in range(0, 12288, 8)]
    offs = [o for o in offs if 12288 <= o < 1 << 40]
    print(os.path.basename(path), [base + o - 12288 for o in offs])

Con el checkpoint real, 24 375 880, la recuperación arrancó. Ningún destino intermedio funcionó: probé seis valores y todos acabaron en "cannot fulfill innodb_log_recovery_target=T<X", con X unos bytes por encima de T. Lo que sí funcionó fue reproducir hasta el final del primer fichero con el destino a 0:

docker run -d --name b6p3-pitr \
  -v "$PWD/data/pitr-restore:/var/lib/mysql" \
  -v "$PWD/lab/arch2.cnf:/etc/mysql/conf.d/zz-lab.cnf:ro" \
  -e MARIADB_ROOT_PASSWORD=root_pass mariadb:13.0.2 \
  --innodb-log-recovery-start=24375880 --innodb-log-recovery-target=0

El servidor informó "Starting crash recovery from checkpoint LSN=24375880" y "End of log at LSN=57904184". Las 2 000 filas de los dos lotes estaban, y el UPDATE incompleto se deshizo. Un detalle: la copia del fichero archivado conserva su permiso de solo lectura, y con él el servidor murió con "[FATAL] InnoDB: pwrite(log) returned -1, operating system error 9". Tuve que darle permiso de escritura antes de arrancar.

En resumen, en la 13.0.2 la recuperación con el archivado tiene la granularidad de un fichero, no de una transacción. Jira registra tres fallos de esta función corregidos en la 13.0.2, entre ellos MDEV-40080 ("innodb_log_archive=ON may corrupt the log") y MDEV-39861, que abría el log en lectura y escritura durante una recuperación con destino.

QB_NAME y los nombres implícitos de bloque

Lo nuevo en la 13.0 no es QB_NAME(), que ya existía: son los nombres implícitos por alias y la forma con ruta. Comprobé que un QB_NAME(dt) explícito dentro de una tabla derivada ya funciona en la 12.3.3. La novedad es que cada vista, CTE o tabla derivada recibe su alias como nombre de bloque sin escribir nada, según la página de Query Block Naming^[10]:

EXPLAIN SELECT /*+ NO_INDEX(p@dt idx_estado) */ COUNT(*)
  FROM (SELECT * FROM pedidos p WHERE estado = 'devuelto') AS dt;

En 13.0.2 el hint se aplicó: el plan pasó a recorrer la tabla entera (type ALL, 200 000 filas estimadas) en vez de usar idx_estado. En 12.3.3 el mismo texto dejó el índice y un aviso: "Warning 4220: Query block name dt is not found for NO_INDEX hint". Con la vista v_pedidos_es pasó lo mismo: NO_INDEX(p@v_pedidos_es idx_estado) quitó el índice de possible_keys en la 13.0.

La forma con ruta, QB_NAME(qv, v_pedidos_es), da nombre a un bloque dentro de una vista, y la 12.3.3 la rechaza como error de sintaxis del hint. Las dos formas solo valen en SELECT, no en UPDATE ni DELETE, y no funcionan dentro de la definición de una vista. Los hints mal escritos no fallan: el optimizador los ignora con un aviso, así que revisa SHOW WARNINGS al probarlos.

UPDATE con RETURNING y las variables obsoletas

UPDATE ... RETURNING devuelve las filas modificadas en la misma sentencia, y OLD_VALUE() da el valor anterior de cada columna:

UPDATE pedidos SET estado = 'enviado'
  WHERE id IN (1, 2, 3) AND estado <> 'enviado'
  RETURNING id, OLD_VALUE(estado) AS antes, estado AS despues;
-- | id | antes    | despues |
-- |  1 | pagado   | enviado |
-- |  3 | devuelto | enviado |

Devolvió 2 filas porque el pedido 2 ya estaba enviado y el filtro lo excluyó. La 12.3.3 responde con un error de sintaxis. Solo funciona con una tabla: el UPDATE multitabla todavía no admite RETURNING, según las notas.

La otra mejora práctica son las columnas IS_DEPRECATED y DEPRECATED_REPLACEMENT. En 13.0.2 hay 19 variables obsoletas, y cruzarlas con GLOBAL_VALUE_ORIGIN te dice cuáles vienen de tu my.cnf:

SELECT VARIABLE_NAME, GLOBAL_VALUE, DEPRECATED_REPLACEMENT
FROM information_schema.SYSTEM_VARIABLES
WHERE IS_DEPRECATED = 'YES' AND GLOBAL_VALUE_ORIGIN = 'CONFIG';

Con un my.cnf de prueba señaló innodb_flush_method y log_slow_admin_statements; para esta última propone log_slow_filter. También comprobé que binlog_row_event_max_size pasó de 8 192 bytes en 12.3.3 a 65 536 en 13.0.2.

¿Te conviene actualizar a MariaDB 13.0?

Para un servidor en producción, no: la 12.3 LTS tiene soporte hasta junio de 2029 y la 13.0 hasta finales de 2026. El propio anuncio de la Fundación dice que actualizar tiene sentido si quieres probar alguna de las funciones nuevas. Esta tabla resume mi recomendación:

Si vienes del análisis de MariaDB 11.7, aquella también era una rolling: su última versión, la 11.7.2, salió el 13 de febrero de 2025. Es el mismo patrón, y la lección es mirar el tipo de serie antes que el número.

Preguntas frecuentes

¿MariaDB 13.0 es una versión LTS?

No. Es una versión rolling estable, con soporte comunitario hasta el cuarto trimestre de 2026 según la política de la Fundación. La próxima LTS del calendario es la 13.3; la LTS actual es la 12.3, con soporte hasta el 12 de junio de 2029.

¿Necesito ejecutar mariadb-upgrade al pasar a 13.0 en Docker?

Sí. La imagen oficial lo ejecuta solo si defines MARIADB_AUTO_UPGRADE, y antes guarda una copia del esquema mysql. Sin esa variable, el servidor arranca, avisa en el log y tienes que lanzar mariadb-upgrade a mano.

¿Puedo usar innodb_log_archive con mariadb-backup?

No, en la 13.0.2. mariadb-backup falla con "cannot read redo log header" mientras el archivado está activo, y la documentación dice que la herramienta que entienda ese formato está en desarrollo.

Conclusión

MariaDB 13.0 cumple lo que promete en SQL: UPDATE ... RETURNING, hints que alcanzan el interior de vistas y tablas derivadas, y metadatos para limpiar la configuración funcionaron a la primera en mis pruebas. El archivado del redo log es la novedad de más calado y la menos madura. Rompe mariadb-backup, complica volver atrás y en la 13.0.2 solo me permitió recuperar hasta el final de un fichero.

Mi recomendación es mantener producción en la 12.3 LTS y fijar la etiqueta de la imagen, porque mariadb:latest ya es una rolling. Antes de cualquier salto de versión mayor, haz una copia en frío, busca to_date y conversion en tus rutinas y ejecuta mariadb-upgrade, aunque su OK no garantice que tus procedimientos sigan compilando.

Fuentes: [1] MariaDB 13.0 Is Now Stable^[2], [2] MariaDB 13.0 Preview Now Available^[11], [3] MariaDB Server: todas las versiones^[3], [4] Política de mantenimiento de la Fundación MariaDB^[1], [5] Notas de la versión 13.0.2 de MariaDB^[4], [6] MDEV-25292 en el Jira de MariaDB^[5], [7] Documentación de InnoDB Log Archiving^[8], [8] Recuperación a un punto en el tiempo con el archivado de InnoDB^[9], [9] Documentación de Query Block Naming^[10], [10] Variables de entorno de la imagen oficial de Docker^[12], [11] Referencia de mariadb-upgrade^[6], [12] Guía de actualización de MariaDB 11.8 a 12.3^[7].

Fuentes

1. política de mantenimiento de la Fundación MariaDB
2. anuncio de la versión estable
3. página de todas las versiones
4. notas de la versión 13.0.2
5. MDEV-25292
6. referencia de mariadb-upgrade
7. guía de 11.8 a 12.3
8. página de InnoDB Log Archiving
9. guía de recuperación con el archivado
10. página de Query Block Naming
11. MariaDB 13.0 Preview Now Available
12. Variables de entorno de la imagen oficial de Docker