MariaDB: cómo identificar tablas y esquemas desde archivos físicos

Cuando una instancia de MariaDB que sirve de origen a nuestros modelos de Power BI o procesos de integración en Microsoft Fabric deja de arrancar, el consultor de BI se enfrenta a un problema de infraestructura que trasciende el DAX o el Power Query. Si el motor de base de datos no inicia debido a errores en las tablas de privilegios o del sistema, la prioridad absoluta es determinar qué datos siguen ahí y si la estructura de tablas (el esquema) es recuperable desde los archivos físicos del sistema operativo.

En proyectos de retail o industria, donde a veces heredamos sistemas MariaDB gestionados de forma externa o con poco mantenimiento, encontrarse con un servidor que lanza errores críticos de Table 'mysql.plugin' doesn't exist es más común de lo que parece. En este escenario, no podemos ejecutar un simple SHOW TABLES. Tenemos que bajar al nivel del sistema de archivos, entender cómo InnoDB almacena la información y tomar decisiones basadas en la integridad de los archivos .frm, .ibd y el espacio de tablas del sistema.

Este artículo no es una guía de administración de sistemas, sino un análisis desde la consultoría de datos sobre qué implica esta situación para tus modelos en producción y cómo puedes auditar el contenido de una base de datos MariaDB directamente desde sus archivos cuando el motor ha caído.

La anatomía de los datos en MariaDB: ¿Dónde están mis tablas?

Para un analista acostumbrado a SQL Server, la estructura de archivos de MariaDB puede parecer fragmentada. Mientras que en SQL Server solemos manejar un archivo .mdf para datos y un .ldf para logs, MariaDB (utilizando el motor InnoDB, que es el estándar) distribuye la información de forma distinta según la versión y la configuración de innodb_file_per_table.

Si navegas por el directorio de datos (usualmente /var/lib/mysql/ en Linux), verás carpetas con los nombres de tus bases de datos. Dentro de ellas, los archivos clave son:

• Archivos .frm: Almacenan la definición de la estructura de la tabla (metadatos). Nota importante: a partir de MariaDB 10.3, este formato empezó a quedar obsoletos en favor del Diccionario de Datos, pero siguen apareciendo en muchas instalaciones legacy.
• Archivos .ibd: Contienen los datos y los índices de una tabla específica si la opción innodb_file_per_table estaba activa.
• ibdata1: Es el espacio de tablas del sistema. Si no se usaban archivos por tabla, todos tus datos están aquí dentro, lo cual complica enormemente la recuperación selectiva.

El problema práctico ocurre cuando el servidor no arranca porque las tablas internas de MySQL/MariaDB (donde se guardan los permisos) están corruptas. En ese momento, perdemos el «mapa» que el motor usa para presentarnos las tablas.

Cómo inspeccionar el contenido sin el motor activo

Si te encuentras en la situación de tener que validar qué tablas existen en un backup de archivos planos o en un servidor caído, la primera herramienta no es SQL, sino el explorador de archivos o la línea de comandos. Listar los archivos .ibd te dará una lista casi exacta de las tablas de datos, pero no te garantiza que los datos sean legibles.

Para recuperar la estructura (el DDL) desde un archivo .frm o .ibd sin el servidor funcionando, los consultores técnicos solemos recurrir a herramientas de terceros como MySQLUtils o utilidades de recuperación de InnoDB. Sin embargo, antes de llegar a eso, hay un paso crítico: intentar arrancar el motor en modo de recuperación.

-- En el archivo de configuración (my.cnf o my.ini)
-- Forzamos la recuperación para saltar comprobaciones de integridad
[mysqld]
innodb_force_recovery = 1

Este parámetro puede ir del 1 al 6. A partir del nivel 4, corres un riesgo real de corrupción de datos permanente. Como consultor, mi recomendación es empezar siempre en 1, realizar un volcado de los datos (dump) y nunca, bajo ningún concepto, intentar trabajar de forma definitiva sobre una base de datos que está corriendo en modo force_recovery. Esto es similar a lo que discutimos sobre el Ajuste automático en SQL Server: FORCE_LAST_GOOD_PLAN en la práctica, donde la estabilidad del sistema debe primar sobre la urgencia de la consulta.

Impacto en el linaje de datos y Power BI

¿Qué ocurre con tus informes de Power BI cuando la estructura física de la base de datos de origen está comprometida? Aquí es donde la Gestión proactiva de errores en Power Query: el patrón de la tabla de control se vuelve vital. Si tu proceso de ETL simplemente falla, pierdes la visibilidad de cuándo fue la última carga válida.

Si logras identificar las tablas mediante los archivos físicos pero el motor sigue inestable, la decisión técnica más sensata es migrar esos datos a un entorno controlado. En proyectos de BI, no necesitamos que la base de datos transaccional sea perfecta, necesitamos que los datos para el modelo en estrella sean consistentes. Si puedes extraer los archivos .ibd, podrías intentar montarlos en una instancia limpia de MariaDB utilizando el comando ALTER TABLE ... IMPORT TABLESPACE.

Errores comunes al auditar archivos de MariaDB

A lo largo de los años en consultoría de datos, he visto patrones de error recurrentes cuando los equipos técnicos intentan «arreglar» bases de datos mirando los archivos:

1. Copiar archivos con el servidor encendido: Los archivos .ibd están en constante escritura. Una copia física mientras el proceso mysqld está activo suele resultar en un archivo corrupto e inutilizable.
2. Inconsistencia entre .frm e InnoDB: Intentar mover un archivo de tabla a otra base de datos sin haber exportado el tablespace correctamente. MariaDB no solo mira el archivo, mira las IDs internas dentro del espacio de tablas del sistema.
3. Ignorar el Case Sensitivity: En Linux, los nombres de los archivos son case-sensitive. Si buscas la tabla «Ventas» y el archivo es «ventas.ibd», muchas herramientas de recuperación fallarán o duplicarán metadatos.

Si el problema es que necesitas extraer datos rápidamente y el motor SQL solo te permite lecturas parciales, recuerda que existen métodos ligeros de exportación que pueden salvar la jornada antes de que el servidor colapse definitivamente.

Estrategia de recuperación para el consultor de BI

Si el servidor MariaDB no arranca y tienes que validar el contenido para informar al negocio sobre el impacto en los dashboards, sigue este flujo:

1. Identifica el directorio de datos y lista los subdirectorios. Cada subdirectorio es un esquema (base de datos).
2. Busca archivos con extensión .ibd. El nombre del archivo coincide con el nombre de la tabla. Si ves una tabla FactVentas.ibd de 50GB, ya sabes dónde está el grueso de tu información.
3. Comprueba las fechas de modificación. Si los archivos no se han tocado desde hace días y esperabas datos frescos, el problema de tu modelo de Power BI empezó mucho antes del crash del servidor.
4. Si el motor arranca en innodb_force_recovery, usa el comando CHECK TABLE para validar qué tablas están legibles antes de intentar un refresh en Power BI.

-- Comprobar integridad de tablas críticas una vez el motor inicia en modo recovery
CHECK TABLE Ventas, Clientes, Productos EXTENDED;
-- Si el resultado es 'OK', procede a un dump inmediato

Este tipo de intervenciones refuerza la necesidad de tener arquitecturas desacopladas. Si los datos de MariaDB se hubieran volcado periódicamente a un Data Lake o Eventhouse, como vemos en la integración real en Microsoft Fabric, el fallo del origen no detendría el consumo de datos históricos por parte de la empresa.

Checklist de actuación ante caída de origen MariaDB

• Copia de seguridad en frío: Detén cualquier intento de arranque y copia todo el directorio /var/lib/mysql a otra ubicación segura.
• Mapeo de archivos: Crea un inventario de tablas basado en los archivos .ibd presentes para evaluar el alcance de la pérdida.
• Prueba de consistencia: Intenta iniciar en innodb_force_recovery = 1 y aumenta gradualmente solo si es estrictamente necesario.
• Extracción selectiva: Prioriza las tablas maestras (Clientes, Productos) antes que las históricas de gran volumen.
• Validación de modelo: Una vez recuperados los datos, recalcula medidas clave en DAX para asegurar que no hay saltos en las series temporales por pérdida de registros.

Preguntas frecuentes

¿Puedo abrir un archivo .ibd directamente con un editor de texto?

No de forma útil. Son archivos binarios. Podrías ver algunos strings de texto plano usando el comando strings en Linux, pero la estructura de datos está paginada y comprimida por el motor InnoDB.

¿Qué hago si solo tengo los archivos .ibd pero no los .frm?

Es un escenario difícil pero recuperable en versiones modernas. Necesitarás crear una tabla con la misma estructura exacta en otra instancia y luego intercambiar los tablespaces, aunque es un proceso técnico propenso a errores de ID de tabla.

¿La corrupción de archivos físicos afecta igual a MyISAM que a InnoDB?

No, MyISAM es mucho más simple (archivos .MYD y .MYI) y fácil de reparar con myisamchk, pero carece de la robustez transaccional de InnoDB, por lo que casi no se usa en entornos empresariales modernos.

¿Cómo afecta esto al rendimiento de mis consultas una vez recuperado?

Tras una recuperación forzada, es vital reconstruir los índices. Un archivo recuperado puede tener fragmentación interna masiva, lo que penalizaría los planes de ejecución si el motor no se optimiza correctamente después del desastre.