Guía de resolución de problemas para los paquetes de ServBay MariaDB/MySQL

Vista general

MariaDB y MySQL son sistemas de gestión de bases de datos relacionales de código abierto líderes en el sector, utilizados ampliamente en todo tipo de aplicaciones web y escenarios empresariales. ServBay integra múltiples versiones de paquetes de MariaDB/MySQL en macOS y Windows, facilitando a los desarrolladores un entorno local de base de datos práctico y eficiente. Aunque estas bases de datos destacan por su estabilidad, pueden surgir problemas como imposibilidad de inicio del paquete, fallos de conexión o caídas de rendimiento durante el desarrollo y la operación.

Esta guía está diseñada para ayudar a los usuarios de ServBay a diagnosticar y solucionar problemas frecuentes de los paquetes MariaDB/MySQL. Cubriremos los problemas típicos, pasos de diagnóstico y soluciones concretas, destacando rutas y comandos específicos del entorno ServBay.

Aviso importante:

¡Antes de realizar cualquier acción que pueda modificar datos o configuraciones, asegúrese de respaldar su base de datos! ServBay ofrece una función de respaldo integrada que recomendamos usar regularmente.
Los ejemplos de comandos y rutas utilizan versiones específicas (como 11.3 o 11.5). Reemplace estos valores por la versión que realmente está usando en ServBay. Puede consultar las versiones instaladas y habilitadas directamente en la interfaz de la aplicación ServBay.
Los ejemplos emplean marcadores como <username>, <database>, <your_backup.sql>. Sustitúyalos por sus valores reales: nombre de usuario, base de datos y archivo de respaldo respectivamente.
Esta guía soporta los sistemas operativos macOS y Windows, proporcionando ejemplos y rutas adaptadas en cada sección.

Pasos generales para diagnóstico inicial

Antes de profundizar en la búsqueda del problema específico, se recomienda realizar las siguientes verificaciones básicas:

Verificar el estado del paquete ServBay: Abra la interfaz de ServBay y confirme que la versión de MariaDB/MySQL que desea usar está habilitada y marcada como “En ejecución”. También puede comprobarlo desde la línea de comandos:
bash
```
servbayctl status mariadb <version>
# Ejemplo para revisar el estado de MariaDB 11.3:
servbayctl status mariadb 11.3
```
1
2
3
Revisar los registros de la aplicación ServBay: ServBay puede registrar errores durante el arranque o la gestión de paquetes. Consulte la sección de registro en la aplicación, o revise el archivo de log principal de ServBay.

Leer el registro de errores de MariaDB/MySQL: Este es el paso más importante para identificar problemas de arranque o errores de ejecución en el paquete de base de datos. Las rutas del registro suelen ser:

macOS:

bash

/Applications/ServBay/logs/mariadb/<version>/<version>.err
# Por ejemplo, para ver las últimas 50 líneas del registro de errores de MariaDB 11.3:
tail -n 50 /Applications/ServBay/logs/mariadb/11.3/11.3.err

Windows:

cmd

C:\ServBay\logs\mariadb\<version>\<version>.err
# Por ejemplo, ver las últimas 50 líneas del registro de errores de MariaDB 11.3:
powershell "Get-Content -Path 'C:\ServBay\logs\mariadb\11.3\11.3.err' -Tail 50"

Preste especial atención a los mensajes de error al final del archivo, ya que suelen indicar directamente la causa del problema.

Problemas comunes y soluciones

1. Error de conexión: `SQLSTATE[HY000] [2002] No such file or directory`

Este error significa que el cliente no puede conectarse al servidor MariaDB/MySQL a través del archivo Unix socket. En macOS, el Unix socket es un mecanismo para comunicación local entre procesos, normalmente preferido por su bajo coste frente a conexiones TCP/IP. Cuando una aplicación o cliente no encuentra el archivo socket en la ruta especificada, se muestra este error.

Posibles causas y soluciones:

El paquete MariaDB/MySQL no está ejecutándose:
- Verifique en la interfaz de ServBay o con el comando servbayctl status mariadb <version> que el servicio está activo.
- Si no se está ejecutando, use: servbayctl start mariadb <version> y revise el registro de errores (.err) para comprender por qué falló el arranque.
Ruta incorrecta del archivo socket (solo macOS/Linux):
- La ruta del archivo socket usada por el cliente no coincide con la configurada en el servidor (my.cnf).
- macOS: Revise el parámetro socket en el archivo de configuración /Applications/ServBay/etc/mariadb/<version>/my.cnf.
- Windows: En Windows no se emplean sockets Unix, sino canalizaciones nombradas o conexiones TCP/IP.
- macOS: Asegúrese de que la aplicación o cliente emplea la ruta correcta de socket, o que usa la ruta por defecto de ServBay (usualmente /Applications/ServBay/tmp/ o /tmp/, según versión y configuración, por ejemplo /Applications/ServBay/tmp/mysql.sock).
Problema de configuración por defecto en ServBay:
- En "Configuración" -> "Servidor SQL predeterminado" de ServBay, confirme que la versión de MariaDB/MySQL elegida corresponde al paquete predeterminado. Algunos clientes (como el comando mysql sin parámetros -S ni -h) intentan conectar al socket por defecto.
Problemas de permisos:
- macOS: El usuario que ejecuta el proceso MariaDB/MySQL quizás no tenga permisos de escritura en la carpeta del socket, o el usuario cliente no tenga permisos de lectura. ServBay suele administrar adecuadamente los permisos, pero si modificó manualmente los privilegios de /Applications/ServBay/tmp/ o /tmp/, pueden surgir errores.
- Windows: Verifique que el usuario que ejecuta ServBay tiene permisos para escuchar en el puerto designado y crear canalizaciones nombradas.

Alternativa (forzar conexión por red):

Intente conectarse usando la IP 127.0.0.1 en vez de localhost. Así el cliente usará TCP/IP en vez de socket Unix. Si funciona, probablemente el problema esté en la ruta del socket.
bash
```
mysql -u <username> -p -h 127.0.0.1 -P 3306
```
1

2. Error de conexión: relacionados con la red (`Connection refused`, `Can't connect to MySQL server`)

Estos errores significan que el cliente no logra conectarse al servidor MariaDB/MySQL por medio de TCP/IP.

Posibles causas y soluciones:

El paquete MariaDB/MySQL no está ejecutándose: (Como arriba, verifique estado y revise el log .err)
Puerto en uso:
- Asegúrese de que el puerto de escucha (3306 por defecto) no esté ocupado por otro proceso.
macOS:
bash
```
lsof -i :3306
# O bien
netstat -anv | grep LISTEN | grep 3306
```
1
2
3
Windows:
cmd
```
netstat -an | findstr :3306
# O use PowerShell:
Get-NetTCPConnection -LocalPort 3306
```
1
2
3
Si el puerto está siendo usado, detenga el proceso/os que lo ocupan o modifique el parámetro port en my.cnf y reinicie el paquete.
- macOS: /Applications/ServBay/etc/mariadb/<version>/my.cnf
- Windows: C:\ServBay\etc\mariadb\<version>\my.cnf

El firewall bloquea la conexión:

macOS:

Revise preferencias de macOS > Red > Firewall.

Puede permitir temporalmente el proceso mysqld por medio del firewall:

bash

# Ejemplo, ajuste rutas según versión
sudo /usr/libexec/ApplicationFirewall/socketfilterfw --add /Applications/ServBay/bin/mariadb/<version>/bin/mysqld
sudo /usr/libexec/ApplicationFirewall/socketfilterfw --unblockapp /Applications/ServBay/bin/mariadb/<version>/bin/mysqld

Windows:

Verifique la configuración de Windows Defender Firewall o firewalls de terceros.

Puede agregar una regla de permiso por aplicación o puerto:

cmd

# Permitir programa específico por el firewall
netsh advfirewall firewall add rule name="ServBay MariaDB" dir=in action=allow program="C:\ServBay\bin\mariadb\<version>\bin\mysqld.exe"

Configuración de bind-address:
- Verifique el parámetro bind-address en my.cnf. Si está en 127.0.0.1 o localhost, solo permite conexiones desde la máquina local. Para aceptar conexiones externas, cambie a 0.0.0.0 o su IP específica y asegúrese que el firewall lo permita.
Problemas de resolución de localhost:
- Verifique que localhost se resuelve correctamente a 127.0.0.1 (IPv4) y/o ::1 (IPv6).
macOS:
bash
```
ping localhost
# Ver hosts file
cat /etc/hosts
```
1
2
3
Windows:
cmd
```
ping localhost
# Ver archivo hosts
type C:\Windows\System32\drivers\etc\hosts
```
1
2
3
El archivo hosts debe tener la entrada para localhost. Además, desactive proxies: algunos programas pueden interferir con el tráfico local.

3. El paquete MariaDB/MySQL no inicia

Posibles causas y soluciones:

Verifique el registro de errores (¡clave!): Ya descrito antes, revise el archivo de log de errores y busque el mensaje específico de fallo de inicio.
- macOS: /Applications/ServBay/logs/mariadb/<version>/<version>.err
- Windows: C:\ServBay\logs\mariadb\<version>\<version>.err

Errores en el archivo de configuración: El archivo my.cnf puede tener errores de sintaxis, parámetros inválidos o rutas mal escritas.

Ubicación del archivo:

macOS: /Applications/ServBay/etc/mariadb/<version>/my.cnf
Windows: C:\ServBay\etc\mariadb\<version>\my.cnf

Validar sintaxis:

bash

# macOS
/Applications/ServBay/bin/mariadb/<version>/bin/mysqld --defaults-file=/Applications/ServBay/etc/mariadb/<version>/my.cnf --validate-config

# Windows
C:\ServBay\bin\mariadb\<version>\bin\mysqld.exe --defaults-file=C:\ServBay\etc\mariadb\<version>\my.cnf --validate-config

Puerto en uso: (Verificar como en la sección anterior con lsof -i :<port> o netstat)
Falta de espacio en disco: La partición donde se ubica el directorio de datos o logs no tiene suficiente espacio.
Ubicación de directorios:
- macOS: Datos en /Applications/ServBay/db/mariadb/<version>/, logs en /Applications/ServBay/logs/mariadb/<version>/
- Windows: Datos en C:\ServBay\db\mariadb\<version>\, logs en C:\ServBay\logs\mariadb\<version>\
Problemas de permisos: El usuario que ejecuta el proceso MariaDB/MySQL no posee permiso de lectura o escritura en los archivos/directorios necesarios. ServBay configura estos permisos automáticamente, pero si se modificaron manualmente pueden surgir problemas.
macOS - revisar permisos:
bash
```
ls -ld /Applications/ServBay/db/mariadb/<version>
ls -l /Applications/ServBay/etc/mariadb/<version>/my.cnf
ls -ld /Applications/ServBay/logs/mariadb/<version>
```
1
2
3
El usuario (_mysql) debe tener permisos adecuados.
Windows - revisar permisos: Utilice el explorador de archivos para comprobar los permisos sobre carpetas y archivos, asegurando que la cuenta de servicio de ServBay tiene derechos suficientes.
Corrupción de archivos de datos: (Consulte la sección sobre "Fallo o corrupción de datos en la base de datos" más abajo) Si se produjo un apagón abrupto o algún error, los archivos pueden corromperse, impidiendo el arranque.

Luego de resolver:

Intente reiniciar el paquete con: servbayctl restart mariadb <version>

4. Problemas de usuario o autenticación

Tras conectar exitosamente, podría encontrar errores relacionados con usuario, contraseña o privilegios (por ejemplo, Access denied).

Posibles causas y soluciones:

Usuario o contraseña incorrectos: Verifique que el nombre de usuario y la clave son exactamente correctos. ServBay permite restablecer fácilmente la clave del usuario root. Si olvida la contraseña root, utilice esa función.
Restricción de host para el usuario: Un usuario puede estar limitado para conectar solo desde ciertos hosts, como 'usuario'@'localhost'. Si conecta desde 'usuario'@'127.0.0.1' puede fallar. El símbolo '%' permite conexión desde cualquier host.
Falta de privilegios: El usuario puede no tener permisos para acceder a la base de datos deseada o ejecutar ciertas operaciones (SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, etc.).
Verificar privilegios de usuario:
- Entre con un usuario "root" o privilegiado en MariaDB/MySQL:
  bash
```
mysql -u root -p
```
  1
- Desde el prompt SQL, revise las concesiones para el usuario:
  sql
```
SHOW GRANTS FOR '<username>'@'<hostname>';
-- Ejemplo para usuario 'webapp'@'localhost':
SHOW GRANTS FOR 'webapp'@'localhost';
-- Para 'admin' desde cualquier host:
SHOW GRANTS FOR 'admin'@'%';
```
  1
  2
  3
  4
  5
- Si es necesario, modifique permisos con GRANT y REVOKE, o cree usuarios nuevos asignándole privilegios requeridos.

5. Problemas de rendimiento

La caída en el rendimiento de la base de datos afecta la velocidad de respuesta de toda la aplicación.

Posibles causas y soluciones:

Consultas lentas: Sentencias poco eficientes, ausencia de índices o planes de ejecución deficientes.
- Activar log de consultas lentas: En el archivo my.cnf, configure slow_query_log = 1, long_query_time = 1 (log de consultas que toman más de 1 segundo) y defina slow_query_log_file. Reinicie el paquete y analice el archivo de log para identificar consultas problemáticas.
- Usar EXPLAIN: Ante consultas lentas, anteponga EXPLAIN para analizar el plan de ejecución, ver uso de índices, filas escaneadas, etc.
  sql
```
EXPLAIN SELECT * FROM your_table_name WHERE column_name = 'value';
```
  1
- Optimizar las sentencias: Ajustar según el análisis de EXPLAIN, evitar operaciones costosas (como SELECT *, funciones en el WHERE), y asegurarse que las condiciones de búsqueda y JOIN aprovechan los índices.
Falta o mala configuración de índices: Las columnas usadas en búsquedas, ORDER BY, GROUP BY, deben tener índices adecuados para evitar escaneos completos.
- Analizar esquema y consultas habituales: Identificar columnas a indexar.
- Crear índices:
  sql
```
CREATE INDEX idx_column_name ON your_table_name(column_name);
```
  1
  Nota: Crear índices aumenta el coste de escritura y el uso de disco, hay que ponderar pros y contras.
Configuración inadecuada de la caché: Parámetros relacionados en my.cnf como innodb_buffer_pool_size, key_buffer_size (MyISAM), pueden estar demasiado altos o bajos.
- Ajustar configuración según la RAM disponible y propósito del equipo: innodb_buffer_pool_size para InnoDB suele ser el parámetro crucial; para servidores dedicados puede asignar el 50–70% de memoria RAM. Recuerde reiniciar el servicio tras el cambio.
  ini
```
[mysqld]
# Ejemplo, ajuste según necesidad. Unidad suele ser bytes o K/M/G.
innodb_buffer_pool_size = 2G
# Si hay muchas tablas MyISAM:
# key_buffer_size = 256M
```
  1
  2
  3
  4
  5
Cuellos de botella de hardware: Uso excesivo de CPU, memoria insuficiente (provoca swapping), o disco lento. Emplee el Monitor de actividad de macOS o comandos como top/htop para detectar qué recurso está saturado.

6. Fallos del servidor o corrupción de datos

Si la base de datos no inicia, se detiene abruptamente o se observan anomalías en los datos, es probable que los archivos estén dañados.

Posibles causas y soluciones:

Revisar registro de errores: Paso vital. El log suele registrar la causa (errores InnoDB, problemas de sistema de archivos, fallos de hardware, etc).
- macOS: /Applications/ServBay/logs/mariadb/<version>/<version>.err
- Windows: C:\ServBay\logs\mariadb\<version>\<version>.err
Fallo de hardware: Errores de disco, memoria defectuosa, etc. Revise los logs del sistema (Console.app) o ejecute herramientas de diagnóstico.
Bugs o conflictos de software: Determinadas versiones de MariaDB/MySQL pueden contener bugs o entrar en conflicto con otros programas instalados.
Errores de configuración: Parámetros incorrectos en my.cnf pueden desestabilizar o provocar caídas en la base de datos.
Apagados forzados o interrupciones: Detener el paquete improperamente (cerrar de golpe ServBay o terminar el proceso) puede dejar archivos en estado inconsistente.

Soluciones:

Intentar reinicio seguro: Intente reiniciar normalmente desde ServBay o por línea de comandos: servbayctl restart mariadb <version>. A veces el sistema puede recuperar sus propios archivos.

Usar mysqlcheck para revisar y reparar tablas: Este comando permite verificar la integridad de las tablas y reparar problemas (principalmente en MyISAM).

bash

# Utilice el my.cnf de ServBay y el usuario root para comprobar todas las bases y tablas
mysqlcheck --defaults-file=/Applications/ServBay/etc/mariadb/<version>/my.cnf -u root -p --check --all-databases
# Reparación automática para MyISAM:
# mysqlcheck --defaults-file=/Applications/ServBay/etc/mariadb/<version>/my.cnf -u root -p --auto-repair --check --all-databases

Nota: --auto-repair sirve solo para MyISAM. En InnoDB, --check ayuda a identificar problemas, pero la restauración requiere acciones más avanzadas (como el “Force Recovery” de InnoDB, o restaurar un backup).

Recuperación forzada de InnoDB (innodb_force_recovery): Si InnoDB no inicia, puede intentar esta opción (¡peligrosa! puede causar pérdida de datos/incoherencia). Solo úsela si el objetivo principal es exportar datos como respaldo.
1. Haga una copia de seguridad del directorio de datos, incluso dañados: Copie /Applications/ServBay/db/mariadb/<version>/ a un lugar seguro.
2. Edite el archivo my.cnf problemático (/Applications/ServBay/etc/mariadb/<version>/my.cnf).
3. Añada bajo [mysqld]: innodb_force_recovery = N (empiece por 1, suba hasta 6 si no inicia; nunca pruebe más de un nivel a la vez).
4. Inicie MariaDB/MySQL: servbayctl start mariadb <version>.
5. Si arranca (aunque sea en modo limitado), exporte todos los datos de inmediato con mysqldump.
  bash
```
mysqldump --defaults-file=/Applications/ServBay/etc/mariadb/<version>/my.cnf -u root -p --all-databases --routines --triggers --events > /path/to/your_emergency_backup.sql
```
  1
  Asegúrese que el archivo generado exista y tenga tamaño razonable.
6. Tras el backup, detenga el servicio: servbayctl stop mariadb <version>.
7. Edite my.cnf y retire/comente la línea innodb_force_recovery = N.
8. Proceda a restaurar datos: Usualmente implica inicializar un nuevo directorio de datos, importar el backup realizado.

Restaurar desde un backup confiable: Si el arreglo falla o los datos no son coherentes, la manera más segura es restaurar con un backup reciente. ServBay almacena backups en /Applications/ServBay/backup/mariadb/<version>/ si usa la función integrada.

Ejemplo de restauración (para importar en <target_database_name>):

bash

# Asegúrese que la base destino existe
# mysql --defaults-file=/Applications/ServBay/etc/mariadb/<version>/my.cnf -u root -p -e "CREATE DATABASE <target_database_name>;"

# Importe el backup
mysql --defaults-file=/Applications/ServBay/etc/mariadb/<version>/my.cnf -u <username> -p <target_database_name> < /Applications/ServBay/backup/mariadb/<version>/<your_backup.sql>

Nota: Reemplace <version> por la versión del paquete en uso.

7. Problemas de backup y restauración

Al usar la función de respaldo de ServBay o realizar un backup/restauración con mysqldump, pueden ocurrir inconvenientes.

Posibles causas y soluciones:

Archivo de respaldo incompleto o dañado:
- Verifique el tamaño del archivo (ls -lh /path/to/your_backup.sql) para ver si es acorde al volumen de datos esperado.
- Use un editor de texto o less para comprobar que el archivo contiene sentencias SQL correctas.
- Si realizó el backup con mysqldump, revise si hubo errores durante la ejecución. Con el modo integrado de ServBay, verifique los logs de la aplicación para detalles.
Errores en el comando de restauración:
- Usó credenciales incorrectas, o el nombre de la base de datos destino es erróneo.
- El usuario que realiza la importación no tiene suficientes permisos.
- Errores de sintaxis SQL: Si el respaldo proviene de otra versión de MariaDB/MySQL, o de otro sistema, pueden aparecer incompatibilidades de sintaxis.
Problemas con claves foráneas: Si las tablas se restauran en un orden tal que los datos referenciados aún no existen, pueden fallar las restricciones. Temporalmente puede desactivar la verificación de claves foráneas durante la importación:
sql
```
-- Antes de importación
SET foreign_key_checks = 0;
-- Ejecute el import, ejemplo:
source /path/to/your_backup.sql; -- En el cliente mysql
-- O modo comando: mysql ... < /path/to/your_backup.sql

-- Después de importar
SET foreign_key_checks = 1;
```
1
2
3
4
5
6
7
8
Advertencia: Desactivar chequeo de claves puede llevar a incoherencias; úselo solo en el proceso de importación.
Problemas de charset/collation: El archivo de respaldo puede emplear charset/collation incompatibles con la base destino, generando errores o datos corruptos. Revise que todo use el mismo charset, preferentemente utf8mb4.

Restaurar correctamente una base de datos (ejemplo de comandos):

macOS:

bash

# Si el backup es para una base específica
# Crear la base destino (<target_database_name>) si no existe
# mysql --defaults-file=/Applications/ServBay/etc/mariadb/<version>/my.cnf -u root -p -e "CREATE DATABASE <target_database_name>;"

# Importar usando la configuración, usuario y base correcta
mysql --defaults-file=/Applications/ServBay/etc/mariadb/<version>/my.cnf -u <username> -p <target_database_name> < /Applications/ServBay/backup/mariadb/<version>/<your_backup.sql>

# Si el respaldo incluye todas las bases (--all-databases), no especifique base de datos
# mysql --defaults-file=/Applications/ServBay/etc/mariadb/<version>/my.cnf -u <username> -p < /Applications/ServBay/backup/mariadb/<version>/<your_backup.sql>

Windows:

cmd

REM Si el backup es para una base específica
REM Crear la base destino (<target_database_name>) si no existe
REM C:\ServBay\bin\mariadb\<version>\bin\mysql.exe --defaults-file=C:\ServBay\etc\mariadb\<version>\my.cnf -u root -p -e "CREATE DATABASE <target_database_name>;"

REM Importar usando la configuración, usuario y base correcta
C:\ServBay\bin\mariadb\<version>\bin\mysql.exe --defaults-file=C:\ServBay\etc\mariadb\<version>\my.cnf -u <username> -p <target_database_name> < C:\ServBay\backup\mariadb\<version>\<your_backup.sql>

REM Si el respaldo es para todas las bases (--all-databases), no especifique base de datos
REM C:\ServBay\bin\mariadb\<version>\bin\mysql.exe --defaults-file=C:\ServBay\etc\mariadb\<version>\my.cnf -u <username> -p < C:\ServBay\backup\mariadb\<version>\<your_backup.sql>

Nota: Reemplace <version> por la versión usada. Los respaldos hechos con la herramienta ServBay suelen ser fáciles de restaurar y la aplicación ofrece opciones para ello.

8. Bug específico: El fallo de InnoDB en MariaDB 11.5.1 (`ib_logfile0 was not found` / `Missing FILE_CHECKPOINT`)

Se trata de un bug grave conocido en MariaDB 11.5.1 que puede impedir la inicialización y recuperación del motor InnoDB, provocando que la base de datos no arranque.

Características del error:

En el registro de errores pueden aparecer mensajes similares a:

Ejemplo macOS (/Applications/ServBay/logs/mariadb/11.5/11.5.err):

[ERROR] InnoDB: File /Applications/ServBay/db/mariadb/11.5/ib_logfile0 was not found
[ERROR] InnoDB: Plugin initialization aborted with error Generic error
[ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
[ERROR] Unknown/unsupported storage engine: InnoDB

Ejemplo Windows (C:\ServBay\logs\mariadb\11.5\11.5.err):

[ERROR] InnoDB: File C:\ServBay\db\mariadb\11.5\ib_logfile0 was not found
[ERROR] InnoDB: Plugin initialization aborted with error Generic error
[ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
[ERROR] Unknown/unsupported storage engine: InnoDB

O bien:

[ERROR] InnoDB: Missing FILE_CHECKPOINT(xxxxx) at xxxxx
[ERROR] InnoDB: Log scan aborted at LSN xxxxx
[ERROR] InnoDB: Plugin initialization aborted with error Generic error
[ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
[ERROR] Unknown/unsupported storage engine: InnoDB

Esto indica que InnoDB no encuentra o no puede manejar el archivo de log necesario, impidiendo su arranque.

Solución (requiere migrar datos, ¡haga siempre respaldo previo!):

Este bug no suele ser reparable por métodos normales. Lo más seguro es intentar forzar el arranque para exportar los datos, y migrarlos a una versión más estable.

Intentar recuperación forzada para hacer backup (¡riesgo!):

Edite el archivo de configuración:

macOS: /Applications/ServBay/etc/mariadb/11.5/my.cnf
Windows: C:\ServBay\etc\mariadb\11.5\my.cnf

Añada bajo [mysqld]: innodb_force_recovery = 6

Intente iniciar el servicio:

bash

servbayctl start mariadb 11.5

Si arranca, exporte datos inmediatamente:

macOS:

bash

mysqldump --defaults-file=/Applications/ServBay/etc/mariadb/11.5/my.cnf -u root -p --all-databases --routines --triggers --events > /Applications/ServBay/backup/mariadb/11.5/mariadb_11.5_emergency_backup.sql

Windows:

cmd

C:\ServBay\bin\mariadb\11.5\bin\mysqldump.exe --defaults-file=C:\ServBay\etc\mariadb\11.5\my.cnf -u root -p --all-databases --routines --triggers --events > C:\ServBay\backup\mariadb\11.5\mariadb_11.5_emergency_backup.sql

Asegúrese de que el archivo exportado esté correctamente creado y con tamaño adecuado.

Detenga el servicio y gestione el directorio de datos dañado:
- Detenga MariaDB 11.5: servbayctl stop mariadb 11.5
- Edite el archivo my.cnf y elimine o comente la línea innodb_force_recovery = 6.

Guía de resolución de problemas para los paquetes de ServBay MariaDB/MySQL ​

Vista general ​

Pasos generales para diagnóstico inicial ​

Problemas comunes y soluciones ​

1. Error de conexión: SQLSTATE[HY000] [2002] No such file or directory ​

2. Error de conexión: relacionados con la red (Connection refused, Can't connect to MySQL server) ​

3. El paquete MariaDB/MySQL no inicia ​

4. Problemas de usuario o autenticación ​

5. Problemas de rendimiento ​

6. Fallos del servidor o corrupción de datos ​

7. Problemas de backup y restauración ​

8. Bug específico: El fallo de InnoDB en MariaDB 11.5.1 (ib_logfile0 was not found / Missing FILE_CHECKPOINT) ​

Guía de resolución de problemas para los paquetes de ServBay MariaDB/MySQL

Vista general

Pasos generales para diagnóstico inicial

Problemas comunes y soluciones

1. Error de conexión: `SQLSTATE[HY000] [2002] No such file or directory`

2. Error de conexión: relacionados con la red (`Connection refused`, `Can't connect to MySQL server`)

3. El paquete MariaDB/MySQL no inicia

4. Problemas de usuario o autenticación

5. Problemas de rendimiento

6. Fallos del servidor o corrupción de datos

7. Problemas de backup y restauración

8. Bug específico: El fallo de InnoDB en MariaDB 11.5.1 (`ib_logfile0 was not found` / `Missing FILE_CHECKPOINT`)