Analizar e interpretar correctamente el registro de errores de MariaDB

Función y límites del registro de errores

El Registro de errores de MariaDB Es el registro de funcionamiento del proceso del servidor. En él se registran, en particular, los procesos de inicio y parada, los eventos críticos del servidor, así como indicaciones que puedan apuntar, por ejemplo, a problemas con las tablas o con el motor de almacenamiento. El registro está siempre activo, aunque su canal de salida puede configurarse de diversas formas.

En él aparecen, por ejemplo, inicializaciones fallidas de complementos, archivos ilegibles, denegaciones de acceso o mensajes relacionados con las conexiones. Sin embargo, una línea con el mensaje „Access denied“ solo demuestra, en un primer momento, que no se ha aceptado un inicio de sesión con los datos enviados. Solo el contexto permite determinar si la causa es la contraseña, la asignación de usuario-host, el método de autenticación o la aplicación que realiza la llamada.

Además, el registro de errores no es un archivo completo de todos los errores SQL de una aplicación. Para eso existe el archivo independiente Complemento SQL_ERROR_LOG; puede registrar los errores SQL que se produzcan en un archivo propio y tiene en cuenta también los errores que procesa un «Condition Handler» antes de que lleguen al cliente. El complemento no viene instalado de serie. Sus entradas pueden contener información sobre usuarios, hosts, bases de datos y SQL, por lo que, antes de su uso, deben establecerse medidas de protección del acceso y de minimización de datos.

Para Solución de problemas de MySQL Por lo tanto, la secuencia temporal es más importante que una línea final aislada. En primer lugar, guarda un fragmento coherente antes y después del suceso. Si a un mensaje de error concreto le siguen varias entradas posteriores y, finalmente, una interrupción, la primera anomalía relevante suele estar más cerca de la causa que el último error visible. También deben tenerse en cuenta en la evaluación el momento en que se produjo, el síntoma observado y los cambios simultáneos en la aplicación o el sistema.

Determinar con seguridad las ubicaciones de almacenamiento

Un archivo que falta con la extensión .err no significa que MariaDB no haya registrado nada. El registro de errores puede escribirse en un archivo, en la salida de error predeterminada o, a través de Syslog, en el diario de systemd; en Windows, también se incluye el Visor de eventos. La opción que esté activa depende de las opciones del servidor, el paquete y el mecanismo de inicio de la instalación concreta.

La opción log_error En el caso de la salida basada en archivos, determina la ubicación de destino. Un nombre de archivo relativo se interpreta en relación con el directorio de datos, mientras que una ruta absoluta es independiente de este. Si no se especifica ningún nombre, la documentación describe un archivo siguiendo el patrón «nombre de host más» .err en el directorio de datos. Sin embargo, no debes deducir de ello una ruta fija: comprueba siempre la configuración realmente vigente.

Los siguientes comandos solo leen las opciones de los archivos de opciones. Por lo tanto, son un buen punto de partida para log_error, pero no reflejan necesariamente la configuración completa del proceso en ejecución. Los parámetros de inicio adicionales, así como las modificaciones de unidades de systemd o las sustituciones «drop-in», pueden complementar o modificar los valores y deben comprobarse por separado.

En la documentación actual de MariaDB, el proceso del servidor se denomina mariadbd; mysqld Puede seguir apareciendo como nombre de compatibilidad, dependiendo de la instalación. Por lo tanto, no se deben equiparar ambos nombres sin tener en cuenta el contexto de la versión y la instalación. Los comandos no modifican ni el servicio ni los datos.

mariadbd --print-defaults
my_print_defaults --mariadbd | grep log-error
my_print_defaults --mysqld | grep log-error

Según la documentación, el segundo comando está previsto a partir de MariaDB 10.11; el tercero es relevante para instalaciones con la denominación anterior del programa. Si no encuentras ninguna indicación clara en los archivos de opciones, comprueba el diario o el syslog, así como los parámetros del servicio que se ha iniciado realmente, en lugar de crear una ruta de registro hipotética. Esto evita que el diagnóstico y la configuración en tiempo de ejecución no coincidan.

Interpretar correctamente el formato de las líneas y el contexto

En los registros de errores basados en archivos de las versiones modernas de MariaDB a partir de la 10.1.5, cada línea sigue siempre el patrón: marca de tiempo, ID de hilo, nivel y mensaje. El Marca de tiempo clasifica el evento; el ID del hilo permite relacionarlo con otras entradas de la misma conexión al servidor, y el nivel describe el tipo de mensaje. El mensaje solo ofrece un enfoque fiable para el diagnóstico cuando se analiza junto con estos campos.

En MariaDB hasta la versión 10.1.4 inclusive, el formato de fecha y hora es más corto y la representación difiere del esquema más reciente. Por ello, un analizador o una búsqueda que espere posiciones fijas de los campos del formato actual puede analizar incorrectamente los registros más antiguos. Además, los scripts SST externos en entornos Galera pueden escribir líneas en las que falten el ID del hilo y el nivel. Estas líneas especiales no son necesariamente datos de registro dañados.

El siguiente fragmento es solo un ejemplo esquemático de la secuencia de lectura de una secuencia de inicio fallida. No utiliza ningún caso real y no sustituye ni a la salida completa del inicio ni a la comprobación de las opciones activas. Lo fundamental es que la discrepancia en la configuración se produce antes del mensaje final de interrupción.

2026-09-23 08:14:02 0 [Note] Starting MariaDB
2026-09-23 08:14:02 0 [ERROR] unknown variable 'example_option=1'
2026-09-23 08:14:02 0 [ERROR] Aborting

Aquí está unknown variable El primer aspecto que hay que investigar: la opción puede estar mal escrita, no estar disponible en esta versión o estar ubicada en el archivo de configuración incorrecto. Aborting por el contrario, describe el punto final de la secuencia inicial. Por lo tanto, busca hacia atrás hasta el primer mensaje relevante y, a continuación, anota las líneas siguientes. Así es como se distinguen la causa probable, la reacción del servidor y los efectos visibles de la errores en la base de datos bien separados unos de otros.

Primera recepción sin modificaciones que supongan un riesgo

Antes de interpretar un mensaje o modificar la configuración, haz una copia de seguridad del Contexto operativo: la versión completa de MariaDB, incluyendo cualquier complemento del paquete o de la distribución, el sistema operativo, el mecanismo de inicio, la hora y el síntoma observable. Un reinicio, un intento fallido de inicio de sesión o una interrupción de la replicación son eventos distintos. Sin estos datos, no es posible evaluar de forma fiable la misma línea del registro.

Además, no copies un único resultado, sino un fragmento coherente que incluya el momento anterior y posterior al primer evento destacable. Anota cuándo comenzó el problema para los usuarios o las aplicaciones y si se produjeron cambios paralelos en la configuración, la implementación o la red. De este modo, se pueden diferenciar en el tiempo los factores desencadenantes, los errores subsiguientes y la secuencia normal de inicio o parada.

Los siguientes comandos solo leen la información de los archivos de opciones y no modifican ni el servicio ni los datos. Son especialmente útiles para consultar una opción configurada en dichos archivos log_error . Sin embargo, no muestran automáticamente todos los valores con los que se inició realmente el servicio: los parámetros de inicio adicionales, los archivos de unidad de systemd y los «drop-ins» deben comprobarse por separado.

mariadbd --print-defaults
my_print_defaults --mariadbd | grep log-error
my_print_defaults --mysqld | grep log-error

A partir de MariaDB 10.11, MariaDB documenta my_print_defaults --mariadbd para esta consulta. El nombre mariadbd se refiere al proceso del servidor actual; mysqld En muchas instalaciones se mantiene como denominación antigua o como indicación de compatibilidad. Por lo tanto, no consideres que ambos nombres se refieran a la misma versión concreta del servidor o al mismo nombre de servicio.

Si el registro se encuentra en el diario de systemd, delimita el intervalo de tiempo utilizando el nombre de la unidad comprobado en el sistema. Si es necesario, comprueba también el archivo de la unidad y los «drop-ins» existentes, para asegurarte de que no se pasen por alto parámetros de inicio adicionales. A continuación, añade al fragmento el registro de la aplicación correspondiente al mismo periodo, en caso de que el síntoma se manifieste en una aplicación.

journalctl -u <geprüfte-mariadb-unit> --since "2026-09-23 08:00" --until "2026-09-23 09:00"

Clasificar los niveles y los errores iniciales

Las etiquetas estructuran el registro de errores de MariaDB, pero no sustituyen al análisis de las causas. Una Gravedad describe la clasificación de una línea, no necesariamente el daño ni la urgencia. Precisamente en el caso de un problema de arranque, el orden es decisivo: un mensaje de error concreto que aparezca antes suele explicar uno posterior Aborting, mientras que las notas que aparecen antes también pueden referirse a la inicialización habitual.

Si MariaDB no se inicia, identifica primero la última secuencia de inicio en el registro y luego léelo hacia atrás. Busca, en particular, unknown variable, archivos que faltan o que no se pueden leer, problemas de permisos y errores en la inicialización de los complementos. MariaDB remite al registro de errores como fuente principal en caso de fallos en el inicio; si el inicio se realiza manualmente, la causa también puede aparecer en la consola.

A Error de configuración Suele deberse a una opción desconocida, a un error ortográfico o a un valor incorrecto en un archivo leído. En ese caso, comprueba primero las opciones activas y la asignación de versiones, en lugar de modificar los datos. Por el contrario, un error al abrir un archivo de datos o un aviso de InnoDB puede estar relacionado con los permisos, las rutas, el almacenamiento o el estado de los datos, y requiere un análisis mucho más cuidadoso.

No modifiques varios parámetros a la vez para forzar el inicio. Guarda el fragmento del registro y anota qué cambio precedió al error. Solo cuando se haya asignado el primer mensaje relevante a un ajuste o recurso comprobado se podrá planificar una corrección específica y trazable.

Evaluar desde el punto de vista diagnóstico los síntomas frecuentes

Las expresiones recurrentes acortan la búsqueda, pero rara vez proporcionan por sí solas un diagnóstico. Asigna cada mensaje a un intervalo de tiempo, al host o hilo afectado y al síntoma observado. La tabla solo incluye, de forma deliberada, los siguientes pasos de diagnóstico: así se evita que, a partir de una referencia a conexiones, archivos o replicación, se deduzca precipitadamente que la causa se encuentra en el servidor de la base de datos.

En Acceso denegado En primer lugar, es fundamental determinar para qué usuario y qué host cliente se ha rechazado el inicio de sesión. Comprueba la configuración de la aplicación utilizada y el momento en que se produjo el error, no solo la contraseña por sí sola. El mensaje puede deberse a datos de acceso incorrectos, a una referencia de host errónea o a una autenticación inadecuada; no indica que la base de datos esté dañada.

A Conexión interrumpida Puede deberse a un tiempo de espera de la aplicación, una conexión de red interrumpida, un proxy o una comunicación de paquetes defectuosa. Compara el host del cliente y el ID del hilo con el registro de la aplicación. Para los contadores, utiliza valores globales en lugar de valores relacionados con la sesión; de lo contrario, una sesión recién establecida puede mostrar valores erróneamente bajos.

SHOW GLOBAL STATUS LIKE 'Aborted%';

La consulta muestra los contadores, pero no la causa completa ni la asignación a un cliente concreto. Por lo tanto, evalúa los cambios a lo largo de un periodo de tiempo adecuado junto con extractos del registro de errores. En caso de avisos relacionados con la replicación o el GTID, documenta además las líneas siguientes y comprueba el estado de la replicación con la información de estado prevista para ello; la línea del registro de errores por sí sola no basta para un diagnóstico completo de la replicación.

Evaluar la recuperación de InnoDB sin riesgo para los datos

Tras una parada no planificada, pueden aparecer mensajes como „Recovering after a crash“, „Starting crash recovery“ y un mensaje de finalización satisfactoria. En un primer momento, describen una recuperación automática tras un fallo al iniciar el servidor. En relación con el registro binario o tc.log Además, pueden contener información sobre la coordinación de transacciones. Estas líneas por sí solas no constituyen una prueba de que las tablas estén dañadas o de que se haya producido una pérdida de datos.

La valoración cambia si, tras la recuperación, se produce un [ERROR] si el inicio se interrumpe o si los mensajes indican que hay archivos ilegibles o dañados. En ese caso, lee toda la secuencia de inicio en orden cronológico y anota la versión, el momento del fallo y el fragmento completo. Una referencia al «Binary Log» o al «tc.log» no supone por sí sola una solicitud de reparación si no hay errores posteriores.

Si se sospecha que hay un problema con los datos, no se deben eliminar archivos ni realizar otras intervenciones cuyo único objetivo sea forzar el arranque. Aclara primero el objetivo de la medida: delimitar el error, leer de forma controlada los datos accesibles o restaurar una instancia productiva. Para ello, registra por separado el extracto del registro, las copias de seguridad disponibles y el estado de la instancia afectada.

Si es posible realizar una lectura controlada, la migración a una instancia de destino limpia debe formar parte de la planificación, en lugar de considerar que el entorno afectado ya está solucionado. Para comprender los mecanismos transaccionales implicados, resulta útil el artículo sobre Registros de deshacer de MariaDB para administradores. En caso de fallos repetidos o errores de archivo poco claros, es más recomendable recurrir a un servicio de recuperación especializado que seguir intentando arrancar el sistema.

Separar la replicación y los errores de SQL

En el registro de errores pueden aparecer hilos, posiciones, GTID o registros de retransmisión durante los procesos de replicación. Estos datos proporcionan, en un primer momento, contexto sobre el periodo en cuestión, pero aún no constituyen un diagnóstico completo del error. Guarda las líneas anteriores y posteriores a la entrada y comprueba por separado el estado de la replicación. A partir de una sola línea del registro, no es posible determinar de forma fiable si un hilo se ha finalizado correctamente o si se ha producido una interrupción.

Noticias sobre transacciones preparadas Por el contrario, tras un fallo hay que actuar con especial precaución. Una recuperación heurística toma una decisión de «commit» o «rollback» en función de la opción elegida, ignorando la información de la coordinación de transacciones. No se trata de un paso para la resolución general de problemas de MySQL, sino de un caso especial cuyas consecuencias para las réplicas y los datos empresariales deben evaluarse de antemano.

El registro de errores recoge los eventos del servidor, pero no es un registro exhaustivo de todas las sentencias SQL que han dado error. Los registros binarios sirven principalmente para registrar cambios y para la replicación; su función se explica en el artículo sobre Los registros binarios de MariaDB y su lógica de rendimiento. El registro de consultas lentas (Slow Query Log) resulta útil en caso de consultas lentas; el registro general de consultas (General Query Log) sirve para la supervisión exhaustiva de las conexiones y las consultas, y el registro de auditoría (Audit Log) tiene otra finalidad de control.

Para los errores SQL que puedan surgir, existe el archivo independiente Complemento SQL_ERROR_LOG. También puede registrar errores que procesa un gestor de condiciones y que, por lo tanto, técnicamente no se transmiten al cliente. El complemento no se instala automáticamente; a partir de MariaDB 10.11.5, si se configura adecuadamente, también se pueden registrar las advertencias. Sus entradas pueden contener datos de usuario y de host, nombres de bases de datos y texto SQL. Por lo tanto, planifica derechos de acceso restrictivos, la conservación y la rotación de los registros antes de activar el registro adicional en un entorno de producción.

Funcionamiento, escalado y próximos pasos

Detén a quienes llamen la atención errores en la base de datos En primer lugar, un fragmento de registro coherente con marcas de tiempo, no solo la última línea. Anota la versión de MariaDB junto con el identificador del paquete, el mecanismo de inicio, el síntoma observado y la correlación temporal con implementaciones, reinicios o eventos de infraestructura. Estos datos permiten diferenciar una posible causa de sus consecuencias y comparar conjuntamente las pistas procedentes de la aplicación, el sistema operativo y la base de datos.

A continuación, compara las opciones que se han cargado efectivamente con la configuración prevista, en lugar de modificar los valores predeterminados que supones que hay. Esto es especialmente importante porque el empaquetado, la versión de MariaDB y los nombres de compatibilidad pueden afectar de forma diferente a las opciones. Si se produce un error de configuración, este se puede planificar de forma diferente a un posible daño en la memoria o en InnoDB.

Antes de realizar reinicios, intentos de recuperación o cambios en la configuración, es una medida de seguridad recomendable comprobar las copias de seguridad disponibles y su viabilidad. Además, documenta el cambio previsto y un plan de contingencia. Esto no sustituye a un análisis de las causas, pero reduce el riesgo de que una medida de diagnóstico oculte el estado inicial o dificulte la recuperación.

Un único caso de denegación de acceso o de conexión interrumpida puede considerarse, en un primer momento, como algo normal si no se repite y tanto la aplicación como el servicio se mantienen estables. Si estos incidentes se repiten con frecuencia, hay que tener en cuenta el host del cliente, la aplicación, el proxy y la red. Por el contrario, los fallos repetidos en el inicio, los archivos de datos ilegibles, las recuperaciones tras fallos que no se han completado con éxito o los indicios de transacciones en curso son casos que requieren una escalación inmediata con los datos originales guardados.

Incluso un registro que funcione correctamente necesita unas normas de funcionamiento. Supervisa Rotación de troncos y el consumo de memoria, ya que un mayor nivel de verbosidad o los registros de errores SQL adicionales pueden hacer que los archivos aumenten rápidamente de tamaño. Limita el acceso a los registros, ya que contienen detalles técnicos y, en su caso, contenidos confidenciales de las consultas. Los cambios permanentes solo son aceptables tras haber documentado la causa, haber elaborado un plan de contingencia y haber evaluado el impacto en la protección de datos y la capacidad.