MariaDB vs RDS MariaDB: ¿Cuál provoca menos sorpresas extrañas de compatibilidad?

La tesis: cuál te sorprende menos

Si quieres menos sorpresas de compatibilidad, la respuesta depende de lo que llames “compatibilidad.”
Si te refieres a “la BD se comporta exactamente como en mi servidor anterior”, MariaDB autogestionado gana—porque controlas todo el entorno.
Mismos paquetes, mismo sistema de archivos, mismos plugins, mismos scripts de inicio, mismo kernel, mismos parámetros.

Si por “compatibilidad” entiendes “sigue funcionando durante actualizaciones, fallos de hardware y backups sin que yo invente una nueva religión”,
RDS MariaDB te sorprende menos operativamente, porque es un producto con protecciones. Pero esas protecciones son a su vez una superficie de compatibilidad:
grupos de parámetros, plugins restringidos, comportamiento de almacenamiento gestionado, actualizaciones gestionadas, privilegios SUPER restringidos y un enfoque distinto
sobre la observabilidad y la recuperación ante fallos.

Orientación de opinión:

• Elige MariaDB autogestionado cuando tu carga dependa de plugins específicos, comportamiento del sistema de archivos,
  compilaciones personalizadas o afinación precisa (y tengas personal responsable de guardia que lo pueda operar).
• Elige RDS MariaDB cuando tu dolor sea principalmente la carga operativa (parches, backups, failover, almacenamiento),
  y tu aplicación sea disciplinada respecto al comportamiento SQL, migraciones y pruebas.

Las sorpresas de compatibilidad no son aleatorias. Se agrupan alrededor de privilegios, plugins, modos SQL, ajustes de replicación,
valores predeterminados de charset/collation y la infraestructura “invisible”: almacenamiento, límites de I/O y eventos de mantenimiento.

Qué significa realmente “compatibilidad” en producción

Compatibilidad no es solo “arranca” o “se carga el esquema.” En sistemas reales, te das cuenta de que no eras compatible cuando:
las consultas devuelven resultados sutilmente distintos, la replicación diverge, una migración se atora por locks de metadatos, una construcción de índice dispara I/O,
o un parche de seguridad cambia la autenticación y la mitad de tus clientes se estrellan.

Divido las sorpresas de compatibilidad en cinco buckets:

1. Semántica SQL: modos SQL, cambios del optimizador, collations por defecto, comportamiento JSON, funciones de ventana, conversiones al límite.
2. Modelo de privilegios: equivalentes de SUPER, objetos DEFINER, administración de replicación, instalación de plugins, acceso a archivos.
3. Características del servidor: plugins, auditoría, cifrado, hooks de backup, configuración de performance_schema.
4. Acoplamiento con infraestructura: subsistema de almacenamiento, comportamiento de fsync, límites de IOPS, jitter de red, comportamiento de failover.
5. Eventos del ciclo de vida: actualizaciones de versión, releases menores, deriva de parámetros, ventanas de mantenimiento, failover automatizado.

La realidad cruda: RDS MariaDB es “MariaDB con una envoltura de producto.” MariaDB autogestionado es “MariaDB con lo que tú hayas montado encima.”
Tus sorpresas vienen de la envoltura o de tu propio pegamento—elige tu veneno.

Contexto histórico y hechos que explican las rarezas actuales

Las sorpresas de compatibilidad se sienten personales hasta que recuerdas los últimos 15 años de dramas familiares entre motores de BD y decisiones de producto en la nube.
Algunos hechos concretos ayudan a predecir qué fallará antes de que falle.

• Hecho 1: MariaDB se bifurcó de MySQL tras la adquisición de Sun por parte de Oracle. Esa bifurcación creó una realidad de “mayormente compatible, hasta que no lo es”.
• Hecho 2: Los números de versión de MariaDB no se mapean limpiamente al timeline de MySQL. “10.x” no es “MySQL 10.” Es una línea propia.
• Hecho 3: MariaDB ha intercambiado motores y funciones a lo largo del tiempo (por ejemplo, Aria, trabajo distinto en el optimizador). Eso importa en casos límite y rendimiento.
• Hecho 4: AWS RDS no es una VM a la que puedas acceder como root. Es un servicio gestionado con un conjunto curado de parámetros y plugins soportados.
• Hecho 5: RDS tiene un usuario “master” que parece root pero no lo es; ciertos privilegios y operaciones de sistema de archivos están intencionalmente bloqueados.
• Hecho 6: MySQL 8 cambió autenticación y collations por defecto de formas que enseñaron a la industria: “los valores predeterminados son cambios incompatibles disfrazados.” MariaDB tiene sus propios cambios de valores por defecto entre versiones mayores.
• Hecho 7: El almacenamiento en RDS está abstraído; tu rendimiento de I/O lo rigen los tipos de EBS, provisión de IOPS, comportamiento de ráfagas y vecinos ruidosos—no tu controladora RAID favorita.
• Hecho 8: En servicios gestionados, los parches de versión menor pueden incluir cambios de comportamiento que no pediste, porque seguridad y parches de estabilidad se despliegan cuando AWS los certifica.
• Hecho 9: La replicación en MariaDB tiene múltiples modos y variantes de GTID; mezclar sabores entre entornos puede crear rarezas de replicación que parecen corrupción pero son deriva de configuración.

Una cita que sigue siendo relevante, porque las bases de datos son sistemas distribuidos con disfraz:
La esperanza no es una estrategia. —General Gordon R. Sullivan

De dónde vienen las sorpresas de compatibilidad (categorías reales)

1) Privilegios: la ilusión de “soy root”

En MariaDB autogestionado, si tienes root del servidor y un usuario con todos los privilegios, normalmente puedes hacer cualquier cosa:
instalar plugins, leer/escribir archivos para LOAD DATA INFILE, establecer variables globales, manipular internals de replicación.

En RDS MariaDB, el usuario master es potente pero no omnipotente. AWS bloquea ciertas operaciones porque los clientes que comparten
infraestructura gestionada no deberían poder inutilizar el host o exfiltrar datos de otros inquilinos. Verás errores como:
“Access denied; you need (at least one of) the SUPER privilege” o “File not found” aunque el archivo “exista” en tu cabeza.

2) Plugins: tu plugin favorito es el incidente de otra persona

MariaDB autogestionado te permite ejecutar lo que quieras: plugins de auditoría, plugins de autenticación personalizados, helpers de backup/restore,
instrumentación de rendimiento adicional.

RDS soporta un subconjunto. Ese subconjunto varía por versión del motor y por la certificación de AWS. Si tu plan de compatibilidad incluye
“simplemente instala el plugin”, ese plan no es un plan.

Broma #1 (corta, relevante): La nube te da ruedines de entrenamiento, y luego te cobra por hora por el privilegio de no quitártelos.

3) Modos SQL, collations y consultas que “funcionan en mi laptop”

La mayoría de las explosiones de compatibilidad son autoinfligidas. Valores por defecto distintos para sql_mode, character_set_server
y collation_server pueden convertir un comportamiento laxo en desarrollo en fallos estrictos en producción—o peor, en truncamientos silenciosos y
diferencias de ordenación.

RDS puede venir con valores por defecto que difieren de tus paquetes on‑prem. Y aun si los valores por defecto son los mismos hoy, una actualización del motor puede cambiarlos.
Los entornos autogestionados también se actualizan, pero normalmente controlas el momento y validas la compilación alrededor del cambio.

4) Semántica de almacenamiento: IOPS, fsync y la física con la que no puedes negociar

Si ejecutas MariaDB en tus propios hosts, controlas el layout de disco subyacente, el sistema de archivos, las opciones de montaje,
la política de caché del RAID y si tus ajustes de “durabilidad” te están mintiendo. También asumes las consecuencias.

RDS corre sobre almacenamiento gestionado. Puedes elegir clases de volumen e IOPS, pero no puedes ajustar el kernel del host ni las profundidades de cola de almacenamiento.
Las sorpresas de compatibilidad aparecen como “mismo plan de consulta, latencia diferente” o “cambió el comportamiento de checkpointing tras escalar.”

5) Mantenimiento y failover: eventos planificados que se comportan como no planificados

RDS realiza mantenimiento. A veces eliges la ventana; otras AWS la elige por ti si estás atrasado en parches de seguridad.
También convives con la semántica de failover: desconexiones, cambios de DNS y una pequeña ventana donde tu app o se reconecta correctamente o arde.

En autogestionado puede ser más suave si implementas tu propio failover y orquestación de conexiones correctamente. O puede ser un proyecto artístico caótico.

MariaDB autogestionado: menos protecciones, menos limitaciones invisibles

El perfil de compatibilidad de MariaDB autogestionado es “lo que construyes es lo que obtienes.” Eso es tanto lo mejor como lo peor.
Si tu aplicación espera un conjunto específico de comportamientos—plugins personalizados, ciertos patrones de acceso al sistema de archivos, una configuración de InnoDB afinada,
o una topología de replicación estricta—puedes hacerlo realidad.

Dónde MariaDB autogestionado tiende a sorprenderte menos

• Disponibilidad de plugins: puedes instalar lo que necesites, probarlo y fijar versiones.
• Acceso al sistema de archivos: LOAD DATA INFILE, SELECT ... INTO OUTFILE y flujos de trabajo basados en archivos locales se comportan de forma predecible.
• Afinación a nivel OS: ajustes de THP, swappiness, scheduler de I/O, opciones de montaje del FS, pinning NUMA—estos pueden importar en cargas de borde.
• Control exacto de versiones: puedes retener actualizaciones “menores” que cambien comportamiento hasta validarlas.

Dónde las sorpresas de autogestión son peores

Estás construyendo la red de seguridad tú mismo: backups, PITR, pruebas de snapshot, drills de failover, cobertura de monitorización.
Cuando se rompe, se rompe en un fin de semana. Además, asumes las partes difíciles que la gente subestima: reemplazo de discos, bugs de firmware,
y “de alguna manera el sistema de archivos quedó en solo lectura.”

La sorpresa de compatibilidad aquí suele ser organizativa: los equipos asumen que una base de datos es “instalar un paquete,” no un sistema operativo en producción.
Esa suposición funciona hasta que deja de hacerlo.

RDS MariaDB: fiabilidad gestionada con restricciones gestionadas

RDS MariaDB es para equipos que quieren dejar de interpretar el papel de proveedor de almacenamiento. Backups, parcheo automatizado, integración de monitorización
y failover están incorporados. Eso elimina clases enteras de fallos operativos.

Dónde RDS te sorprende menos

• Backups y flujos de restauración: la realidad basada en snapshots es consistente y probada a escala.
• Fallos de hardware y almacenamiento: son problema de AWS (aunque tu outage sigue siendo tu problema).
• Monitorización básica: métricas CloudWatch y eventos RDS te dan señales aunque tu propio stack sea limitado.
• Gestión estandarizada de parámetros: menos configuraciones editadas a mano que divergen entre hosts.

Dónde las sorpresas en RDS son más comunes

• Privilegios: no hay SUPER real, no hay acceso al SO, sistema de archivos controlado.
• Plugins: “soportado” es una decisión de producto, no una posibilidad técnica absoluta.
• Semántica de parámetros: algunas variables son dinámicas, otras requieren reboot, algunas están bloqueadas; a veces el nombre existe pero se comporta distinto.
• Realidad de IOPS: la base de datos no está lenta, el almacenamiento está ocupado—o limitado—o sin créditos.
• Actualizaciones: las actualizaciones del motor pueden ser más suaves, pero aun así cambiar planes del optimizador, valores por defecto o semánticas límite.

Broma #2 (corta, relevante): Nada te hace apreciar los backups gestionados como darte cuenta de que tu “servidor de backup” también es el host del Minecraft del becario.

Matriz de compatibilidad: qué difiere con más frecuencia

Autenticación y compatibilidad de clientes

La mayoría de las roturas de clientes no son exóticas. Son conectores antiguos, configuraciones TLS o cambios en la autenticación por defecto. Autogestionado te permite
replicar exactamente tu entorno antiguo; RDS te empuja hacia las bases seguras preferidas por AWS, a veces más rápido de lo que tu app puede actualizarse.

Regla de decisión: si tienes clientes legacy que no puedes actualizar rápido, autogestionado te compra tiempo. Si puedes actualizar clientes y forzar TLS,
RDS suele reducir el riesgo a largo plazo.

Replicación y sabor GTID

El GTID de MariaDB no es el GTID de MySQL. Y “replicación compatible” no es lo mismo que “replicación idéntica.” Al mover entornos, necesitas fijar:
binlog_format, gtid_domain_id, gtid_strict_mode, semántica row vs statement, y cómo tus herramientas leen posiciones.

RDS soporta funciones de replicación, pero las gestionas mediante la API y procedimientos almacenados en lugar de acceso al SO. La forma del flujo operativo cambia,
y las sorpresas vienen más de ese cambio que de MariaDB en sí.

Modos SQL y rigor

Los modos SQL estrictos son tus amigos si te gusta tener datos correctos. Son tus enemigos si tu app ha confiado en comportamiento indefinido,
truncamiento silencioso o atajos de “group by”. La sorpresa no es que el modo estricto rompa cosas; es que el modo laxo alguna vez funcionó.

Zonas horarias, locales y “ayer funcionaba”

Las instancias RDS corren con imágenes OS gestionadas. Tus hosts autogestionados pueden tener tzdata personalizado o un proceso de carga de tablas de zona horaria distinto.
Migraciones que tocan timestamps o conversiones de fecha son donde esto duele.

Características de rendimiento de almacenamiento

En autogestionado puedes sobredimensionar RAM, fijar buffers, stripear discos y ajustar la pila de I/O. En RDS compras una clase de instancia
y un perfil de volumen. Ambos pueden funcionar; ambos pueden sorprenderte.

El patrón de sorpresa es consistente: cargas con picos o con grandes ráfagas de checkpoint tienden a comportarse distinto según el backend de almacenamiento.
Si tu sistema es sensible a la latencia en cola, prueba bajo carga, no “smoke test con cinco usuarios.”

Tres mini-historias corporativas desde la trinchera

Mini-historia 1: Un incidente causado por una suposición equivocada

Una compañía SaaS mediana decidió mover una carga de reporting de MariaDB autogestionado a RDS MariaDB. Era “no crítica.”
Eso es lo que la gente dice justo antes de que se vuelva crítica.

Tenían una pipeline que dejaba CSV en el host de la base de datos y usaba LOAD DATA INFILE para cargar en tablas de staging.
En sus propios servidores, el proceso de carga escribía en un directorio conocido y el usuario de BD tenía el privilegio FILE. Era aburrido.

En RDS, el mismo enfoque se topó con un muro: la base de datos no podía leer rutas arbitrarias del filesystem del host, y el “usuario master”
no se comportaba como root. Intentaron forzarlo con grants y no llegaron a nada. Mientras tanto, las tablas de reporting se quedaron atrás,
los dashboards mintieron y el equipo de ventas descubrió que la “toma de decisiones basada en datos” era mayormente sensaciones.

La solución no fue ingeniosa. Cambiaron el mecanismo de carga a una ruta soportada: importar desde el lado de la aplicación usando inserciones por lotes
y tamaños de transacción sensatos, y más tarde lo rehicieron como un job ETL que depositaba datos en object storage y cargaba mediante un flujo soportado.
La lección no fue “RDS es malo.” La lección fue: si tu ingestión de datos depende de semánticas del SO, necesitas rediseñarla antes de migrar.

Mini-historia 2: Una optimización que salió mal

Un equipo fintech ejecutaba MariaDB en RDS y notó picos ocasionales de latencia en escritura. Alguien sugirió aumentar el paralelismo
ejecutando más writers concurrentes y subir varios parámetros relacionados con InnoDB en el parameter group. Los gráficos mejoraron un día.

Luego los picos empeoraron y un job nocturno empezó a expirar. ¿Qué cambió? El checkpointing y el comportamiento de flush en background se volvieron
más ruidosos con las nuevas configuraciones, y el volumen de almacenamiento ya estaba cerca de su techo real de IOPS en pico.
En lugar de suavizar, amplificaron la contención.

Su postmortem encontró una trampa clásica: optimizaron la BD como si estuviera en NVMe local dedicado, pero en realidad corría sobre almacenamiento en red gestionado.
Las mismas configuraciones pueden comportarse distinto. Además, no probaron el cambio con concurrencia realista, solo “funciona en staging.”
Staging tenía menos datos, menos índices y ninguno de los patrones reales de tráfico.

La solución fue revertir las configuraciones más agresivas, provisionar almacenamiento con IOPS consistentes y reducir la ráfaga de writers
cambiando batching de la app y aislando el job nocturno a una ventana con menos escrituras concurrentes. La “afinación” más efectiva fue en realidad modelar la carga.

Mini-historia 3: Una práctica aburrida pero correcta que salvó el día

Una gran plataforma B2B ejecutaba una flota mixta: MariaDB autogestionado para cargas especializadas y RDS MariaDB para la mayoría de sistemas transaccionales.
Su arma secreta no era una arquitectura elegante. Era disciplina.

Cada migración de esquema pasaba por un arnés de compatibilidad: la migración se ejecutaba contra dos entornos—una build autogestionada “lo más parecida posible”
y una instancia de prueba en RDS—luego ejecutaban una suite de planes de consulta y comprobaciones de corrección. Comparaban salidas de EXPLAIN,
revisaban drift de collation y ejecutaban una reproducción mínima de consultas de producción.

Una semana, una actualización menor del motor en el entorno de prueba RDS cambió el plan del optimizador para una consulta que usaba un índice compuesto más una condición de rango.
No era incorrecto, solo más lento. El arnés lo detectó, añadieron un índice dirigido y pospusieron la actualización hasta que se publicó la corrección.
Producción nunca vio la regresión.

Nadie recibió un ascenso por “pruebas realizadas y nada explotó.” Pero la rotación on‑call siguió siendo humana, y eso es un KPI mejor que el que merecen muchas empresas.

Diagnóstico práctico: comandos, salidas y decisiones (12+)

Estos son los tipos de comprobaciones que realmente hago cuando alguien dice “RDS MariaDB se está comportando raro” o “autogestionado está bien pero la nube está maldita.”
Cada tarea incluye: un comando, qué significa la salida y la decisión que tomas a partir de ella.

Task 1: Identify engine version and distribution

cr0x@server:~$ mysql -h db.example.internal -u app -p -e "SELECT VERSION(), @@version_comment;"
Enter password:
+---------------------+----------------------------------+
| VERSION()           | @@version_comment                |
+---------------------+----------------------------------+
| 10.6.16-MariaDB     | MariaDB Server                   |
+---------------------+----------------------------------+

Significado: Estás en MariaDB 10.6.x. @@version_comment ayuda a distinguir builds de proveedor.
En RDS verás a menudo un comentario con sabor AWS.

Decisión: Construye una matriz de compatibilidad alrededor del major/minor exacto. No discutas sobre “10.6‑ish.”

Task 2: Check SQL mode drift

cr0x@server:~$ mysql -h db.example.internal -u app -p -e "SELECT @@GLOBAL.sql_mode, @@SESSION.sql_mode\G"
Enter password:
*************************** 1. row ***************************
@@GLOBAL.sql_mode: STRICT_TRANS_TABLES,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION
@@SESSION.sql_mode: STRICT_TRANS_TABLES,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION

Significado: El modo estricto está activado globalmente y en la sesión. Si dev difiere, obtendrás inserts que “funcionan en dev”.

Decisión: Alinea dev/test/prod sql_mode; trata las discrepancias como un bloqueador de release.

Task 3: Check default charset/collation (silent correctness bugs live here)

cr0x@server:~$ mysql -h db.example.internal -u app -p -e "SHOW VARIABLES LIKE 'character_set_%'; SHOW VARIABLES LIKE 'collation_%';"
Enter password:
+--------------------------+---------+
| Variable_name            | Value   |
+--------------------------+---------+
| character_set_client     | utf8mb4 |
| character_set_connection | utf8mb4 |
| character_set_database   | utf8mb4 |
| character_set_results    | utf8mb4 |
| character_set_server     | utf8mb4 |
| character_set_system     | utf8    |
+--------------------------+---------+
+----------------------+--------------------+
| Variable_name        | Value              |
+----------------------+--------------------+
| collation_connection | utf8mb4_general_ci |
| collation_database   | utf8mb4_general_ci |
| collation_server     | utf8mb4_general_ci |
+----------------------+--------------------+

Significado: Estás en utf8mb4 con una collation específica. Ordenación y comparaciones pueden diferir entre collations.

Decisión: Fija charset/collation a nivel de esquema y conexión; no confíes en los valores por defecto del servidor.

Task 4: Detect restricted privileges (common on RDS)

cr0x@server:~$ mysql -h db.example.internal -u admin -p -e "SHOW GRANTS FOR CURRENT_USER();"
Enter password:
+--------------------------------------------------------------------------------------------------+
| Grants for admin@%                                                                                |
+--------------------------------------------------------------------------------------------------+
| GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, RELOAD, PROCESS, REFERENCES, INDEX, ALTER... |
+--------------------------------------------------------------------------------------------------+

Significado: Puedes ver lo que realmente tienes, no lo que asumes tener. La ausencia de poderes tipo SUPER importa.

Decisión: Si tu runbook requiere SUPER, reescríbelo para flujos RDS (grupos de parámetros, procedimientos, API).

Task 5: Confirm binlog format and replication-critical settings

cr0x@server:~$ mysql -h db.example.internal -u admin -p -e "SHOW VARIABLES LIKE 'log_bin'; SHOW VARIABLES LIKE 'binlog_format'; SHOW VARIABLES LIKE 'server_id';"
Enter password:
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| log_bin       | ON    |
+---------------+-------+
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| binlog_format | ROW   |
+---------------+-------+
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| server_id     | 12345 |
+---------------+-------+

Significado: Binlog activado, formato ROW (generalmente más seguro para compatibilidad) y server_id configurado.

Decisión: Si migras topologías de replicación, estandariza en ROW a menos que haya una razón fuerte para no hacerlo.

Task 6: Identify long transactions and lock contention

cr0x@server:~$ mysql -h db.example.internal -u admin -p -e "SHOW FULL PROCESSLIST;"
Enter password:
+----+------+-------------------+------+---------+------+----------------------+-------------------------------------------+
| Id | User | Host              | db   | Command | Time | State                | Info                                      |
+----+------+-------------------+------+---------+------+----------------------+-------------------------------------------+
| 88 | app  | 10.0.1.22:51344   | prod | Query   | 312  | Waiting for metadata | ALTER TABLE orders ADD COLUMN foo INT     |
| 91 | app  | 10.0.2.18:60112   | prod | Query   | 305  | Sending data         | SELECT ... FROM orders JOIN ...           |
+----+------+-------------------+------+---------+------+----------------------+-------------------------------------------+

Significado: DDL esperando locks de metadatos mientras consultas largas corren. Esto parece “migración atascada.”

Decisión: Mata el blocker o reprograma migraciones; implementa herramientas de cambio de esquema online para tablas grandes.

Task 7: Check InnoDB engine status for deadlocks and flush pressure

cr0x@server:~$ mysql -h db.example.internal -u admin -p -e "SHOW ENGINE INNODB STATUS\G" | sed -n '1,120p'
Enter password:
*************************** 1. row ***************************
Type: InnoDB
Name:
Status:
=====================================
2025-12-30 10:12:41 0x7f8c1c1
LATEST DETECTED DEADLOCK
------------------------
...snip...
LOG
---
Log sequence number          8876543210
Log flushed up to            8876543210
Last checkpoint at           8876400000
0 pending log flushes, 0 pending chkp writes

Significado: Deadlocks y estado de checkpoints te dicen si estás limitado por I/O o por locks.

Decisión: Si los checkpoints van retrasados y crecen los flushes pendientes, enfócate en almacenamiento/IOPS y patrones de escritura—no solo en tunear consultas.

Task 8: Find top waits and statements (Performance Schema)

cr0x@server:~$ mysql -h db.example.internal -u admin -p -e "SELECT EVENT_NAME, COUNT_STAR, SUM_TIMER_WAIT/1000000000000 AS seconds_waited FROM performance_schema.events_waits_summary_global_by_event_name ORDER BY SUM_TIMER_WAIT DESC LIMIT 5;"
Enter password:
+----------------------------------------+------------+----------------+
| EVENT_NAME                             | COUNT_STAR | seconds_waited |
+----------------------------------------+------------+----------------+
| wait/io/file/innodb/innodb_data_file   |   18233412 |          913.2 |
| wait/io/file/innodb/innodb_log_file    |    8234411 |          402.7 |
| wait/synch/mutex/innodb/buf_pool_mutex |    2234410 |          188.5 |
| wait/lock/table/sql/handler            |     834411 |           72.1 |
| wait/synch/mutex/sql/LOCK_open         |     244110 |           41.0 |
+----------------------------------------+------------+----------------+

Significado: Esperas intensas en I/O de archivos sugieren cuellos de botella de I/O; esperas de mutex sugieren contenido interno.

Decisión: Si I/O domina, deja de cambiar índices a ciegas; aumenta IOPS o reduce la amplificación de escrituras primero.

Task 9: Validate parameter values that often differ between environments

cr0x@server:~$ mysql -h db.example.internal -u admin -p -e "SHOW VARIABLES WHERE Variable_name IN ('innodb_flush_log_at_trx_commit','sync_binlog','innodb_buffer_pool_size','max_connections','tmp_table_size','max_heap_table_size');"
Enter password:
+--------------------------------+------------+
| Variable_name                  | Value      |
+--------------------------------+------------+
| innodb_buffer_pool_size        | 17179869184|
| innodb_flush_log_at_trx_commit | 1          |
| max_connections                | 2000       |
| max_heap_table_size            | 67108864   |
| sync_binlog                    | 1          |
| tmp_table_size                 | 67108864   |
+--------------------------------+------------+

Significado: Ajustes de durabilidad en 1/1 son más seguros pero pueden ser más lentos en I/O limitado. Tamaños de tmp afectan derrames a disco.

Decisión: No “optimices” la durabilidad por rendimiento a menos que estés dispuesto a explicar pérdida de datos a la dirección.

Task 10: Spot temp table spills (query plans that behave differently)

cr0x@server:~$ mysql -h db.example.internal -u admin -p -e "SHOW GLOBAL STATUS LIKE 'Created_tmp%tables';"
Enter password:
+-------------------------+--------+
| Variable_name           | Value  |
+-------------------------+--------+
| Created_tmp_disk_tables | 123456 |
| Created_tmp_files       | 8421   |
| Created_tmp_tables      | 987654 |
+-------------------------+--------+

Significado: Muchas tablas temporales en disco significa que las consultas están derramando a disco—a menudo por ordenamientos/agrupar y tamaños tmp insuficientes.

Decisión: Afina consultas e índices; aumenta tamaños de tablas temporales con cuidado; verifica que el almacenamiento soporte patrones de spill en RDS.

Task 11: Check slow query logging status (catch regressions)

cr0x@server:~$ mysql -h db.example.internal -u admin -p -e "SHOW VARIABLES LIKE 'slow_query_log%'; SHOW VARIABLES LIKE 'long_query_time';"
Enter password:
+---------------------+-------+
| Variable_name       | Value |
+---------------------+-------+
| slow_query_log      | ON    |
| slow_query_log_file | /rdsdbdata/log/slowquery/mysql-slowquery.log |
+---------------------+-------+
+-----------------+-------+
| Variable_name   | Value |
+-----------------+-------+
| long_query_time | 1.000 |
+-----------------+-------+

Significado: El slow query log está ON, el umbral es 1s, la ruta del archivo indica ubicación de almacenamiento gestionado en RDS.

Decisión: Si estás volando a ciegas, habilita slow logging en ventanas no pico y muestrea; no adivines.

Task 12: Verify connection behavior and aborted connections

cr0x@server:~$ mysql -h db.example.internal -u admin -p -e "SHOW GLOBAL STATUS LIKE 'Aborted_connects'; SHOW GLOBAL STATUS LIKE 'Threads_connected'; SHOW GLOBAL STATUS LIKE 'Max_used_connections';"
Enter password:
+------------------+-------+
| Variable_name    | Value |
+------------------+-------+
| Aborted_connects | 4821  |
+------------------+-------+
+-------------------+-------+
| Variable_name     | Value |
+-------------------+-------+
| Threads_connected | 412   |
+-------------------+-------+
+----------------------+-------+
| Variable_name        | Value |
+----------------------+-------+
| Max_used_connections | 1987  |
+----------------------+-------+

Significado: Muchos Aborted_connects pueden significar deriva de credenciales, incompatibilidades TLS, tormentas de conexión durante failover o presión de max connections.

Decisión: Si las conexiones se disparan durante deploys o failovers, implementa pooling y backoff; no escales max_connections como primera reacción.

Task 13: Confirm time zone tables and server time zone

cr0x@server:~$ mysql -h db.example.internal -u admin -p -e "SHOW VARIABLES LIKE 'time_zone'; SELECT CONVERT_TZ('2025-12-30 12:00:00','UTC','America/Los_Angeles') AS converted;"
Enter password:
+---------------+--------+
| Variable_name | Value  |
+---------------+--------+
| time_zone     | SYSTEM |
+---------------+--------+
+---------------------+
| converted            |
+---------------------+
| 2025-12-30 04:00:00 |
+---------------------+

Significado: La conversión de zona horaria funciona; las tablas están cargadas. Si CONVERT_TZ devuelve NULL, no tienes cargadas las tablas de zona horaria.

Decisión: Corrige la carga de las tablas tz en autogestionado; en RDS usa procedimientos/rutas soportadas y prueba la aritmética de tiempo explícitamente.

Task 14: Compare schema object DEFINERs (migration surprise generator)

cr0x@server:~$ mysql -h db.example.internal -u admin -p -e "SELECT ROUTINE_SCHEMA, ROUTINE_NAME, DEFINER FROM information_schema.ROUTINES WHERE ROUTINE_SCHEMA='prod' LIMIT 5;"
Enter password:
+---------------+-------------------+----------------+
| ROUTINE_SCHEMA| ROUTINE_NAME      | DEFINER        |
+---------------+-------------------+----------------+
| prod          | refresh_rollups   | root@localhost |
| prod          | prune_sessions    | root@localhost |
| prod          | calc_tax          | app@%          |
| prod          | rebuild_summary   | root@localhost |
| prod          | rotate_partitions | dba@%          |
+---------------+-------------------+----------------+

Significado: Rutinas definidas por root@localhost serán un problema en RDS y en cualquier entorno donde ese usuario no exista.

Decisión: Estandariza usuarios DEFINER y reconstruye objetos durante la migración; no importes un volcado a ciegas esperando que funcione.

Guía rápida de diagnóstico: qué comprobar primero/segundo/tercero

Cuando la queja es “sorpresa de compatibilidad”, la gente a menudo persigue al conejo equivocado. Esta guía te lleva al cuello de botella rápido.

Primero: confirma que es realmente la misma carga y las mismas semánticas

1. Deriva de versión y ajustes: compara VERSION(), sql_mode, charset/collation y variables InnoDB clave.
   Si difieren, para. Estás depurando dos bases de datos distintas.
2. Comprobaciones de privilegios y DEFINER: ejecuta SHOW GRANTS y busca discrepancias de DEFINER. Si privilegios faltantes causan fallos en herramientas, perderás horas culpando la “rareza de RDS.”
3. Comportamiento del cliente: revisa errores de conexión y ajustes TLS. Los failovers exponen clientes frágiles más que bugs de la BD.

Segundo: decide si está ligado a CPU, I/O o locks

1. Lock-bound: processlist muestra “Waiting for metadata lock,” “Waiting for table lock,” o deadlocks en InnoDB status.
2. I/O-bound: Performance Schema muestra esperas de archivo dominando; InnoDB status muestra lag en checkpoints o presión de flush; crecen tablas temporales en disco.
3. CPU-bound: consultas son rápidas individualmente pero la concurrencia colapsa; aumenta la contención de mutex; métricas de CPU (fuera de la BD) están saturadas.

Tercero: aisla si la diferencia es envoltura RDS vs núcleo MariaDB

1. Limitaciones de la envoltura: ausencia de SUPER, plugins no soportados, restricciones de filesystem, limitaciones de parameter group.
2. Comportamiento del núcleo: cambios de planificador, semántica de collation, rigor, diferencias en formato de replicación.
3. Infraestructura: throughput/IOPS del almacenamiento, créditos de ráfaga, vecinos ruidosos, eventos de mantenimiento, failover.

Si puedes nombrar en cuál de esos tres buckets estás en 20 minutos, ya vas por delante de la mayoría de las “war rooms.”

Errores comunes: síntomas → causa raíz → solución

1) “Funcionaba en autogestionado, RDS lo rechaza”

Síntomas: errores mencionando SUPER, privilegio FILE, fallos al instalar plugins o incapacidad para leer/escribir archivos locales.

Causa raíz: asumir que RDS es una VM con acceso root y privilegios completos.

Solución: rediseña flujos para evitar dependencia del filesystem; usa patrones de import/export soportados; reemplaza operaciones privilegiadas por grupos de parámetros y mecanismos provistos por AWS.

2) “Misma consulta, orden de resultados distinto”

Síntomas: paginación inconsistente, empates ORDER BY inestables, distinto comportamiento de ordenación de texto.

Causa raíz: diferencias de collation o confiar en orden no definido sin ORDER BY explícito.

Solución: fija collations explícitamente; añade columnas deterministas a ORDER BY; haz la paginación estable.

3) “La replicación falló durante la migración”

Síntomas: el replica se detiene con errores sobre GTID, binlog format o claves duplicadas que “no deberían pasar.”

Causa raíz: mismatch en binlog_format (STATEMENT/MIXED vs ROW), diferentes ajustes GTID o sentencias no deterministas.

Solución: estandariza en ROW; alinea la configuración GTID; audita funciones y triggers no deterministas.

4) “Las migraciones DDL se quedan colgadas para siempre”

Síntomas: ALTER TABLE atascado, cola de apps, timeouts repentinos.

Causa raíz: locks de metadatos bloqueados por consultas largas o transacciones; tooling de migración no es online‑safe.

Solución: implementa enfoques de cambio de esquema online; reduce duración de transacciones; programa ventanas de DDL; detecta blockers vía processlist.

5) “El rendimiento regresó tras una ‘minor’ upgrade”

Síntomas: mayor latencia, cambios en planes de consulta, aumento de tablas temporales en disco.

Causa raíz: cambios del optimizador, diferencias en estadísticas o deriva de parámetros.

Solución: compara EXPLAIN pre/post; refresca estadísticas; añade índices dirigidos; controla upgrades con tests de diferencias de plan.

6) “Las conexiones se disparan en failover y la app colapsa”

Síntomas: Aborted_connects altos, tormentas de conexión, timeouts tras failover o mantenimiento en RDS.

Causa raíz: clientes que no se reconectan con gracia; ausencia de pooling; loops de reintento agresivos.

Solución: añade pooling de conexiones; backoff exponencial; reduce churn de conexiones; valida el comportamiento de failover en drills.

Listas de verificación / plan paso a paso

Checklist A: Elegir entre MariaDB autogestionado y RDS MariaDB (compatibilidad primero)

1. Lista tus dependencias: plugins, UDFs, cargas basadas en filesystem, autenticación personalizada, scripts OS.
2. Clasifica cada dependencia: “imprescindible,” “agradable de tener,” “legacy que deberíamos eliminar.”
3. Revisa requisitos de privilegios: cualquier cosa que requiera SUPER/FILE/acceso OS es un ítem de rediseño para RDS.
4. Fija el comportamiento SQL: sql_mode, charset, collation, comportamiento de zona horaria.
5. Define el plan de replicación: formato binlog, modo GTID, enfoque de cutover, estrategia de rollback.
6. Define la estrategia de upgrades: quién aprueba, cómo pruebas diferencias de plan y cuáles son tus métricas “no-go”.

Checklist B: Plan de migración para minimizar sorpresas de compatibilidad (funciona en ambas direcciones)

1. Inventaria variables del servidor en origen y destino; difféalas y resuelve diferencias intencionales.
2. Exporta solo esquema y revisa DEFINER y SQL SECURITY; normaliza usuarios/definers.
3. Ejecuta una reproducción representativa de consultas y compara resultados y tiempos, no solo “sin errores.”
4. Valida conjuntos de caracteres y collations a nivel de tabla y columna; corrige drift antes de mover datos.
5. Valida comportamiento de zona horaria usando CONVERT_TZ y fechas límite.
6. Prueba failover/reconexión con la aplicación real y la configuración del pooler.
7. Practica restaurar desde un snapshot/cadena de logs en un entorno de prueba; mide RTO y verifica corrección.
8. Corte con rollback: escrituras duales si es posible, o cutover basado en replicación con un plan claro de reversión.

Checklist C: Operaciones Day‑2 que reducen la frecuencia de sorpresas

• Ejecuta diffs periódicos de variables críticas entre entornos (dev/stage/prod).
• Automatiza checks de “regresión de plan” para las consultas más importantes tras upgrades.
• Mantén el slow query log y Performance Schema utilizables (muestreo es mejor que ceguera).
• Prueba regularmente la restauración y un failover controlado, aunque sea incómodo.

Preguntas frecuentes

1) ¿Cuál tiene, en general, menos sorpresas de compatibilidad?

Si tu app espera control total (plugins, filesystem, operaciones privilegiadas), MariaDB autogestionado te sorprende menos.
Si tu app es portable y disciplinada, RDS te sorprende menos operativamente—pero debes aceptar las restricciones gestionadas.

2) ¿RDS MariaDB es “MariaDB real”?

Es el motor MariaDB envuelto en un modelo de servicio gestionado. El motor SQL es real; el entorno no es tu servidor.
Los problemas de compatibilidad suelen venir de la envoltura: privilegios, parámetros, plugins y comportamiento del almacenamiento.

3) ¿Cuál es el error #1 al migrar a RDS MariaDB?

Flujos que asumen acceso a nivel OS: importaciones/exportaciones basadas en archivos, scripts personalizados en el host BD, instalación de plugins o operaciones que requieren SUPER.
Rediseña eso temprano, antes de tocar datos.

4) ¿Puedo confiar en que las actualizaciones menores son seguras en cualquiera de las plataformas?

No. Las actualizaciones menores pueden cambiar elecciones del optimizador, valores por defecto y comportamientos límite. Normalmente son más seguras que las mayores,
pero “normalmente” no es un contrato. Controla las actualizaciones con diffs de plan y pruebas de reproducción de consultas.

5) ¿De verdad importan tanto los modos SQL?

Sí. Los modos SQL deciden si los datos malos se rechazan ruidosamente o se aceptan silenciosamente y quedan almacenados mal.
Las sorpresas de compatibilidad a menudo parecen “la BD cambió,” pero en realidad solo fue una aplicación de reglas de corrección más estrictas.

6) ¿Por qué el rendimiento se siente distinto en RDS aun con el mismo tamaño de instancia?

Porque las semánticas de almacenamiento y I/O son distintas. El almacenamiento gestionado tiene límites, comportamiento de ráfagas y efectos de vecinos ruidosos.
Además, restricciones de parámetros y mantenimiento en background pueden cambiar la distribución de latencias.

7) ¿Cómo prevengo fallos relacionados con DEFINER en migraciones?

Estandariza definers a una cuenta de servicio real que exista en todos los entornos, y recrea rutinas/vistas/triggers con ese definer.
No importes un dump repleto de objetos root@localhost en un entorno donde esa identidad no tiene sentido.

8) ¿Debo usar binlog formato ROW?

En la mayoría de sistemas de producción, sí. ROW reduce la no‑determinación y hace la replicación más predecible.
Puede aumentar el volumen de binlog, así que planifica almacenamiento en consecuencia, pero suele ser la apuesta de compatibilidad más segura.

9) ¿Autogestionado es siempre más “compatible” porque controlas todo?

Controlas todo, incluyendo la capacidad de crear configuraciones snowflake que solo funcionan en un host. Autogestionado reduce las “restricciones del servicio gestionado”,
pero aumenta la “deriva operativa propia” a menos que estandarices y automatices.

10) ¿Cuál es la mejor forma de probar compatibilidad antes de cambiar?

Construye un arnés que valide: variables del servidor, definers de esquema, corrección representativa de consultas, planes de consulta,
y una prueba de carga que incluya concurrencia y jobs en background. Luego prueba el failover con clientes reales.

Conclusión: pasos prácticos siguientes

Si decides únicamente por “sorpresas raras de compatibilidad”, MariaDB autogestionado es la apuesta más segura cuando necesitas paridad total de características
con un setup on‑prem o a medida. Puedes recrear el entorno con precisión. También puedes recrear los mismos errores con precisión,
lo cual es una clase de consistencia.

RDS MariaDB es la apuesta más segura cuando el problema real es la entropía operativa: backups, parcheo, fallos de almacenamiento y mantenimiento rutinario.
Cambias algo de control por menos desastres caseros y aceptas una superficie de compatibilidad distinta: parámetros, privilegios y almacenamiento gestionado.

Pasos siguientes que realmente reducen sorpresas:

1. Haz diff de tus variables de servidor (sql_mode, charset/collation, ajustes de binlog, knobs de durabilidad de InnoDB) entre origen y destino.
2. Escanea el esquema por minas DEFINER y normalízalas antes de migrar datos.
3. Elige una historia de replicación (ROW + estrategia GTID alineada) y ensaya cutover y rollback.
4. Ejecuta un arnés de plan y corrección antes de upgrades y antes de mover de plataforma. Hazlo aburrido. Aburrido es la meta.
5. Practica el fallo: prueba restauración y failover con la app real. Si la reconexión del cliente es frágil, RDS te lo va a exponer.

La mejor forma de reducir sorpresas no es elegir la plataforma “perfecta”. Es dejar de permitir que valores por defecto y suposiciones dirijan tu comportamiento en producción.
Las bases de datos no premian la ingeniería basada en la fe.