MariaDB 12.0: características, riesgos de la actualización y estrategia de alojamiento

Clasificar correctamente MariaDB 12.0

La denominación „MariaDB 12“ no hace referencia a una versión del producto unificada y con mantenimiento continuo. Para obtener información técnica concreta, consulte la serie «Rolling» MariaDB 12.0 es decir. Dentro de esta serie, las versiones presentan distintos grados de madurez: la 12.0.0 se publicó el 26 de marzo de 2025 como versión preliminar, la 12.0.1, el 5 de junio de 2025 como versión candidata, y la 12.0.2, el 7 de agosto de 2025 como versión estable de lanzamiento general (GA).

Las versiones «Preview» y «Release Candidate» sirven para realizar pruebas y no deben equipararse a una plataforma estable. El hecho de que la versión 12.0.2 esté documentada como «Stable» o «GA», por el contrario, describe el estado de madurez precisamente de esta versión. De ello no se deduce ni que todas las instalaciones deban actualizarse de inmediato, ni que las versiones posteriores vayan a tener automáticamente las mismas características, paquetes o límites de funcionamiento.

Las ramas posteriores, como la 12.1, la 12.2 o la 12.3, también deben considerarse por separado. Las funciones, las correcciones de errores o los valores predeterminados modificados de dichas series no constituyen prueba de MariaDB 12.0. Lo mismo se aplica a las ramas de desarrollo: ningún anuncio o documentación que aparezca en ellas sustituye a la información sobre el estado publicado de un servidor de la comunidad.

Por lo tanto, antes de una implementación, la plataforma necesita una nueva comprobación del estado real de los paquetes previstos. En particular, deben comprobarse la serie de servidores disponible, la compatibilidad entre los paquetes de cliente y los paquetes adicionales, la compatibilidad con la versión del sistema operativo utilizada y la clasificación de la versión actual. El contenido del repositorio y los paquetes de distribución pueden diferir de la denominación general del producto.

Diferencias entre «Rolling Release» y LTS

En el caso de las plataformas de alojamiento, no solo es relevante el número de versión, sino también el Modelo de lanzamiento. MariaDB distingue entre versiones de innovación y versiones LTS. Las versiones de innovación incorporan nuevas funciones a intervalos cortos y, tras su lanzamiento general (GA), suelen pasar a la siguiente serie continua. Por su parte, según el fabricante, las versiones LTS reciben mantenimiento durante tres años a partir de su lanzamiento general (GA).

Por lo tanto, una versión estable de GA solo responde a la pregunta de si esa versión concreta se ha publicado como estable. No responde de manera general a cuestiones como cuánto tiempo estarán disponibles las correcciones de seguridad, si un distribuidor seguirá suministrando paquetes o si una cartera de clientes existente puede permanecer en la serie sin necesidad de migrar. Estos aspectos dependen del contrato, de la distribución y del resumen actual de versiones.

Una serie de innovaciones puede resultar adecuada cuando una plataforma desea implementar cuanto antes una función claramente necesaria y puede probar de forma aislada las aplicaciones, los conectores y los procesos operativos afectados. Para ello, los equipos deben planificar continuar con la ruta de actualización prevista en un plazo breve. Especialmente en el caso de las ofertas multicliente, esto aumenta la carga de trabajo relacionada con las autorizaciones, la comunicación y los procedimientos de contingencia.

A Puntuación objetivo de LTS Se adapta mejor a plataformas estandarizadas con muchas aplicaciones clásicas, cuando las ventanas de mantenimiento planificables y una versión de software estable a largo plazo son más importantes que las nuevas funciones individuales. Esto no es una regla en contra de las versiones innovadoras: lo decisivo es si los beneficios de una función justifican las pruebas adicionales y el cambio previsible a la siguiente serie.

Por lo tanto, la selección debería tener en cuenta, como mínimo, las necesidades funcionales, el estado actual de los paquetes y el soporte técnico, la compatibilidad de las aplicaciones probadas, la capacidad de recuperación y los costes de personal para el mantenimiento. Para una nueva instalación, no basta con considerar que „MariaDB 12“ es la versión más moderna. La plataforma debe decidir deliberadamente entre el uso de funciones a corto plazo y un estado de la base de datos estandarizado a largo plazo.

Evaluar las nuevas funciones teniendo en cuenta sus limitaciones

MariaDB 12.0 incorpora Consejos para el optimizador para influir de forma más específica en los planes de ejecución, por ejemplo, en el orden de las uniones, la optimización de rangos o determinados algoritmos de unión. Las ampliaciones también afectan a los componentes de los índices ordenados descendentemente en el «Loose Index Scan» y el «Index Condition Pushdown». En el ámbito del alojamiento web, se trata sobre todo de una herramienta de diagnóstico para consultas concretas que plantean problemas, y no sustituye a los índices adecuados, las condiciones de unión correctas ni las estadísticas de tabla actualizadas.

Una recomendación puede limitar un plan no deseado, pero puede resultar contraproducente si aumenta el volumen de datos o cambian las estadísticas. Por lo tanto, debe formar parte de un análisis reproducible de la aplicación en cuestión y no constituir una directriz general en los servidor de bases de datos. En el caso de las bases de datos típicas de CMS y tiendas online, la mera disponibilidad de estas sugerencias no es un motivo convincente para actualizar a MariaDB.

Durante la auditoría, el complemento de auditoría de la versión 12.0 registra además el host y el puerto de las conexiones entrantes, así como la versión de TLS utilizada. En el caso de accesos a través de proxies, NAT o equilibradores de carga, esto puede mejorar la identificación forense. Sin embargo, la ventaja solo se obtiene mediante una recopilación centralizada de registros, protegida contra el acceso no autorizado, y unas normas de conservación bien definidas; los datos de registro adicionales deben encajar en la planificación de la capacidad y la protección de datos.

En cuanto al cifrado, se dispone de compatibilidad con SHA-2 en file_key_management.so y ssl_passphrase Módulos listos. Los entornos de replicación disponen de opciones para tablas temporales, así como de una variable para gestionar eventos relacionados con el ID del propio servidor. Además, la versión 12.0 incluye, entre otras cosas, SYS_REFCURSOR, un límite de cursor por sesión y funciones SIG como la validación, la simplificación y la conversión a Geohash. Estas herramientas solo son útiles en determinadas aplicaciones y topologías.

MariaDB Server, MaxScale y Galera siguen siendo componentes independientes: MaxScale tiene sus propias versiones y configuraciones, y los cambios relacionados con Galera afectan exclusivamente a los clústeres. Del mismo modo, la compatibilidad con MySQL no implica que sean intercambiables sin antes comprobarlo. MariaDB utiliza su propio modelo GTID y, por ejemplo, no es compatible con el de MySQL. SET PERSIST. Las nuevas funciones SIG pueden resultar útiles para las aplicaciones de datos geográficos basadas en MySQL 8, pero, en el caso de las bases de datos web habituales, no suelen ser motivo para actualizar.

Comparar el estado de la versión y las funciones

Para el funcionamiento de la plataforma, es determinante la versión concreta dentro de la serie. MariaDB 12.0.0 era una versión preliminar, la 12.0.1 una versión candidata y solo la 12.0.2 está documentada como estable o GA. Estos estados indican distintos grados de madurez; no indican si la serie es adecuada para una implementación de alojamiento concreta, un sistema operativo o un contrato de soporte técnico.

Las nuevas funciones resultan especialmente útiles cuando abordan un problema operativo concreto. Consejos para el optimizador pueden, por ejemplo, limitar un plan de ejecución no deseado para una consulta compleja concreta. No sustituyen a los índices adecuados, ni a las condiciones de unión correctas, ni a las estadísticas actualizadas, y no deben utilizarse como configuración global para las aplicaciones de los clientes.

Los campos de auditoría adicionales pueden registrar el servidor, el puerto y la versión de TLS utilizada en una conexión entrante. La opción clave ssl_passphrase Por el contrario, las funciones avanzadas del SIG o del cursor no justifican un cambio generalizado de versión. Su utilidad solo se pone de manifiesto en aplicaciones cuya arquitectura, modelo de datos y requisitos de seguridad requieran realmente estas capacidades.

Preparar de forma controlada la actualización de MariaDB

Una actualización de MariaDB en un alojamiento gestionado o compartido comienza con un inventario: es necesario conocer las instancias, las bases de datos, los conectores, los complementos, los archivos de configuración, las rutas de replicación y las aplicaciones afectadas. A continuación, se crea un entorno de pruebas que reproduce los datos de producción y la configuración únicamente bajo los requisitos de seguridad permitidos. De este modo, se pueden detectar problemas de arranque y discrepancias en SQL antes de que afecten a varios clientes.

Antes de cada implementación limitada, es necesario realizar una copia de seguridad completa y disponer de un procedimiento de recuperación documentado. No basta con que existan los archivos de copia de seguridad: los responsables deben comprobar si a partir de ellos se puede restaurar un estado de datos coherente y utilizable para las aplicaciones. A continuación, deben comprobar los inicios de sesión, las operaciones de escritura, los trabajos en segundo plano y las rutas típicas de los clientes como Regresión de la aplicación. El procedimiento concreto depende del método de seguridad utilizado y de la arquitectura de la plataforma.

Un plan de recuperación establece quién decide qué estados de datos son válidos y cómo las aplicaciones vuelven al estado coherente anterior en caso de interrupción. Se trata de una práctica operativa habitual, no de una característica propia de una versión concreta de MariaDB. Por lo tanto, la replicación, la supervisión y la conmutación por error deben comprobarse en la topología de staging correspondiente, en lugar de deducir su funcionamiento a partir de una actualización satisfactoria de una instancia individual.

MariaDB 12.0 elimina las variables de sistema big_tables, large_page_size y storage_engine. Por lo tanto, las entradas existentes deben figurar en my.cnf y en todos los fragmentos de configuración relacionados, y se evaluarán para el estado de destino. La limpieza debe realizarse antes de la actualización del paquete; en el caso de large_page_size Además, hay que distinguir entre la variable MariaDB eliminada y una configuración de HugePages del sistema operativo independiente de ella.

La planificación de paquetes también merece un paso específico: un repositorio puede contener varias versiones de MariaDB, y los paquetes relacionados (de servidor, cliente, compartidos y comunes) deben tener la misma versión. La versión del sistema operativo y las fuentes de los paquetes forman parte del proceso de aprobación. En cuanto a las dependencias a nivel de host, el artículo sobre Novedades relevantes para servidores de alojamiento con el kernel de Linux 6.x contexto adicional; sin embargo, no sustituye a la comprobación de preparación específica de la base de datos.

Configurar correctamente los casos especiales

En el caso de consultas de informes inestables, el diagnóstico debe comenzar por los planes de ejecución, los índices, las condiciones de unión y las estadísticas de las tablas. Solo cuando se haya identificado de forma reproducible un plan indeseado, una sugerencia al optimizador puede constituir una restricción específica. La indicación forma parte de la consulta en cuestión y debe incluirse en un análisis documentado, ya que el crecimiento de los datos o los cambios en las estadísticas pueden alterar su efecto posteriormente.

Las consultas de lectura son adecuadas para realizar un análisis del estado actual sin riesgos. Ejecútalas con una cuenta que solo tenga los derechos de acceso necesarios para ello; estas consultas no modifican ni los datos, ni los derechos, ni la configuración del servidor. Los resultados recogen el servidor de base de datos realmente conectado y ayudan a verificar las suposiciones que figuran en la documentación de implementación.

SELECT VERSION();
SHOW VARIABLES LIKE 'max_open_cursors';
SHOW VARIABLES LIKE 'create_tmp_table_binlog_formats';

En una arquitectura de proxy, SET SESSION AUTHORIZATION No es una característica de comodidad, sino una modificación del modelo de seguridad. El cambio de sesión requiere el privilegio SET USER y no está disponible en transacciones, sentencias preparadas ni procedimientos almacenados.

Las versiones compatibles de MaxScale pueden utilizar las credenciales de servicio para la conexión al backend y, a continuación, cambiar a la identidad del cliente. Para ello, se necesita un servidor backend MariaDB 12 o posterior y el privilegio SET USER es necesario para la cuenta de servicio. Sin embargo, esta capacidad no se deriva únicamente de un backend de MariaDB 12.0: antes de la implementación, hay que comprobar la combinación concreta de servidor MariaDB, versión de MaxScale y configuración.

La configuración de MaxScale use_service_credentials Determina, en las versiones compatibles con esta función, si MaxScale inicia sesión primero en el backend con los datos de acceso almacenados en el servicio y, a continuación, cambia a la identidad del cliente. La cuenta de servicio no debe tener ningún derecho de administración adicional más allá de los derechos técnicamente necesarios. La auditoría y una desconexión de emergencia documentada deben ajustarse al modelo de conexión y agrupación.

Las topologías de replicación y Galera requieren una ruta de prueba específica para la conmutación por error, la reincorporación y la recuperación. Las opciones relativas a las tablas temporales o al tratamiento de los mismos ID de servidor no deben modificarse sin comprender el formato del binlog, el ID de servidor y la ruta de retorno. Además, una optimización de Galera no supone una garantía general de rendimiento para los clústeres, ya que el perfil de carga y la latencia de la red siguen siendo factores determinantes.

Quien evalúe tablas internas, estructuras temporales o motores de almacenamiento en el entorno debería considerar el papel de cada motor por separado de la migración de versiones. El artículo sobre la Motor de almacenamiento MariaDB Aria en el alojamiento web clasifica este tipo de cuestiones relacionadas con la puesta en marcha. Sin embargo, para la decisión sobre la actualización, lo decisivo es si la aplicación concreta y sus procesos operativos funcionan de forma reproducible en el entorno de destino.

Asegurar el cambio de sesión y la auditoría

SET SESSION AUTHORIZATION es un componente fundamental para arquitecturas de conexión diseñadas de forma deliberada, no solo una facilitación de la administración. Esta instrucción permite a una cuenta autorizada actuar, dentro de la sesión actual, bajo la identidad de otro usuario. El requisito previo es el privilegio SET USER. De este modo, la responsabilidad del registro y la verificación de la identidad pasa, en parte, de las conexiones individuales de los clientes a un componente controlado de la plataforma.

Este patrón puede resultar útil para un proxy, pero el servidor MariaDB y MaxScale siguen siendo productos independientes con sus propias versiones. Solo las versiones de MaxScale que admiten el uso de credenciales de servicio con el consiguiente cambio de identidad pueden ofrecer este proceso. Un backend de MariaDB 12.0 no amplía automáticamente esta capacidad a una rama de MaxScale más antigua o configurada de forma diferente.

En una combinación compatible, el proxy inicia sesión en el servidor MariaDB con la cuenta de servicio y, a continuación, cambia a la identidad de usuario solicitada. La configuración use_service_credentials requiere un servidor backend MariaDB 12 o posterior, así como SET USER para la cuenta de servicio. Por lo tanto, antes de la implementación, es necesario comprobar conjuntamente las versiones concretas de MariaDB y MaxScale que se vayan a utilizar, la configuración y el método de autenticación previsto.

La cuenta de servicio se debe a la posibilidad de El cambio de identidad es crítico para la seguridad. El privilegio SET USER no le otorga automáticamente derechos de administración globales; además, solo debe recibir los permisos técnicamente necesarios. Al cambiar de sesión, se pueden eludir, entre otras cosas, el bloqueo de la cuenta, la caducidad de la contraseña, la autenticación y la comprobación REQUIRE-SSL de la cuenta de destino. Además, el cambio no está disponible dentro de transacciones, sentencias preparadas o procedimientos almacenados.

En el caso del alojamiento multicliente, esto significa que las cuentas de los clientes permanecen separadas de forma lógica, y que el ciclo de intercambio permitido queda documentado y limitado. Además, la plataforma debe contar con un mecanismo de desconexión de emergencia, por ejemplo, mediante el bloqueo de la cuenta de servicio o la eliminación de la ruta de conexión afectada, siguiendo un procedimiento de gestión de incidencias establecido. La medida más adecuada debe determinarse teniendo en cuenta el agrupamiento de conexiones, las sesiones activas y las repercusiones en otros clientes.

El complemento de auditoría de MariaDB 12.0 añade a las conexiones entrantes el host y el puerto, así como la versión de TLS utilizada. Estos datos ayudan a identificar mejor los accesos que se producen detrás de NAT, equilibradores de carga o proxies. Sin embargo, no sustituyen a una identificación fiable cuando un sistema anterior modifica la información de origen o solo transmite su propia dirección al servidor de la base de datos.

Entrará en vigor Auditoría En primer lugar, mediante un proceso operativo: los registros deben recopilarse de forma centralizada, protegerse contra modificaciones no autorizadas y gestionarse según un plazo de conservación establecido. Los derechos de acceso para la consulta y la exportación deben separarse, al igual que las competencias en materia de alertas e investigación. Sin realizar mediciones, no es posible deducir a partir de la versión si los datos de registro adicionales influyen de forma apreciable en la capacidad o el rendimiento de una plataforma concreta.

En caso de incidente de seguridad, los operadores deben poder determinar qué identidad ha establecido el proxy, a través de qué acceso se ha iniciado la sesión y qué datos de auditoría existen al respecto. Las comprobaciones periódicas y documentadas de la desconexión y de la disponibilidad de los registros son más importantes que un registro lo más exhaustivo posible. En particular, un registro de auditoría no debe sustituir al modelo de derechos, al cifrado de transporte ni a la gestión segura de claves.

Supervisar el funcionamiento tras la actualización

Tras una actualización de MariaDB, se inicia una fase de observación; no se lleva a cabo ninguna optimización automática. En primer lugar, hay que distinguir si el Inicio del servidor se produce un error, una aplicación ya no puede establecer conexión o una ruta de replicación presenta desviaciones. Estas situaciones de error tienen causas distintas y requieren soluciones específicas, en lugar de responderse con cambios generales en la configuración.

Los errores de inicio se localizan mediante el registro de errores del servidor y un inventario con control de versiones de los archivos de configuración realmente cargados. En MariaDB 12.0, por ejemplo, big_tables y storage_engine eliminadas. Estas entradas no deben mantenerse sin modificar en my.cnf o en fragmentos de configuración integrados; la referencia de variables documentada y el mensaje de inicio indican qué ajuste concreto se ve afectado.

En el caso de los conectores y los complementos, deben registrarse conjuntamente los paquetes instalados, las versiones de los módulos cargados y el mensaje de error de la aplicación. La mera selección de un repositorio no garantiza por sí sola una instalación compatible: en el caso de una versión específica de servidor, los paquetes de servidor, cliente, compartidos y comunes deben planificarse con la misma versión. Los nombres y versiones disponibles dependen del repositorio y del sistema operativo utilizados.

La mejor forma de analizar los errores de aplicación es mediante un caso SQL reproducible y lo más sencillo posible, junto con los registros correspondientes del cliente o del conector. Se puede realizar un análisis de lectura con SELECT VERSION(); comenzar. El resultado identifica el servidor de base de datos que responde, pero no demuestra ni la compatibilidad de un ORM ni el correcto funcionamiento de una configuración de la aplicación.

En lo que respecta a la replicación, el informe de diagnóstico debe incluir el estado de replicación documentado, el formato del binlog, los ID de los servidores, así como los eventos relacionados con la conmutación por error y la reincorporación. Las tablas temporales, la topología y los cambios en las opciones de replicación deben comprobarse por separado. Una prueba de escritura local satisfactoria no basta para demostrar la coherencia y el comportamiento esperado en todas las instancias implicadas.

Los registros de servidor y de auditoría, el inventario de configuraciones, las consultas de versiones y las pruebas de consultas reproducibles conforman en conjunto una cadena de errores comprensible. También facilita la decisión de si es necesario activar un plan de recuperación ante fallos. Un número de versión más alto no implica ni un rendimiento concreto ni un ajuste universal; los cambios en los parámetros de memoria, del optimizador o de replicación requieren una hipótesis concreta y un efecto comprobable.

Decidir estratégicamente el resultado final

El objetivo adecuado depende de la función de la plataforma y del modelo operativo, no de la denominación genérica «MariaDB 12». En el caso de las bases de datos clásicas de CMS, tiendas online y aplicaciones web, la seguridad en las actualizaciones, la separación clara entre clientes y una vía de recuperación fiable suelen tener prioridad sobre las nuevas funciones SQL concretas. Las nuevas funciones o rutinas GIS no constituyen un motivo de migración por sí mismas si las aplicaciones no las utilizan.

Las aplicaciones de generación de informes complejas pueden beneficiarse de las sugerencias del Optimizer cuando un análisis delimita claramente un plan de ejecución no deseado. Previamente, es necesario comprobar los índices, las condiciones de unión, la distribución de los datos y las estadísticas. Una sugerencia es una vinculación específica a una decisión sobre el plan y puede dejar de ser adecuada tras un aumento del volumen de datos o un cambio en las estadísticas; por lo tanto, debe incluirse en la documentación de la aplicación junto con la consulta, la justificación y los criterios de revocación.

Los entornos de proxy y de clúster requieren una ruta de prueba específica. En el caso de un proxy, esto afecta especialmente al modelo de permisos de la cuenta de servicio, a los cambios de sesión y a la auditabilidad. En el caso de la replicación o Galera, esto incluye la conmutación por error, la reincorporación, la restauración y el comportamiento de las tablas temporales. El hecho de que la actualización de una única instancia se haya realizado con éxito no garantiza que estos procesos funcionen correctamente en toda la topología.

El Estrategia de lanzamiento Debe evaluar por separado las versiones de innovación y las LTS. MariaDB describe las versiones de innovación como versiones continuas que, por regla general, no se mantienen de forma continua con versiones de parches tras el lanzamiento general (GA); la trayectoria prevista conduce a la siguiente serie continua. Las versiones LTS, por el contrario, reciben mantenimiento durante tres años a partir del lanzamiento general (GA). De ello no se deriva ningún compromiso generalizado de soporte mediante paquetes o contratos para un entorno de alojamiento concreto.

Por lo tanto, antes de tomar una decisión, hay que evaluar en su conjunto el estado de los paquetes y el soporte técnico de la distribución, la compatibilidad probada de las aplicaciones, una restauración comprobada, el modelo de seguridad y los gastos de funcionamiento corrientes. A pesar de compartir muchos patrones SQL comunes, MariaDB y MySQL no son intercambiables: MariaDB utiliza su propio modelo GTID y, por ejemplo, no es compatible con el de MySQL. SET PERSIST. Por lo tanto, es necesario comprobar las suposiciones de migración procedentes de un entorno MySQL.

Para la serie 12.0, la versión 12.0.2 figura como versión estable (GA), mientras que la 12.0.0 era una versión preliminar y la 12.0.1, una versión candidata. Esta clasificación describe el estado de madurez en aquel momento, pero no sustituye a ninguna decisión de lanzamiento actual. Inmediatamente antes del despliegue o la publicación, los operadores deben volver a contrastar la versión del paquete ofrecida, la compatibilidad con el sistema operativo y la clasificación actual de la versión con la información del fabricante.

Por lo tanto, lo decisivo es el estado concreto de la plataforma que se ha comprobado, con sus dependencias y normas de funcionamiento. Un despliegue controlado está justificado si se ha demostrado que se han preparado adecuadamente la compatibilidad, la reversibilidad y las responsabilidades. Si no se cumplen estos requisitos, el nombre «MariaDB 12» no es un argumento válido para asumir riesgos en un alojamiento compartido o en un entorno de bases de datos críticas para el negocio.