Guida alla risoluzione dei problemi del pacchetto ServBay MariaDB/MySQL

Introduzione

MariaDB e MySQL sono tra i sistemi di gestione di database relazionali open source più utilizzati al mondo, impiegati in numerose applicazioni web e scenari business. ServBay integra diverse versioni di MariaDB/MySQL su macOS e Windows, offrendo agli sviluppatori un ambiente locale per database facile da gestire e ad alte prestazioni. Pur essendo noti per la loro stabilità, durante lo sviluppo o l’esecuzione possono comunque presentarsi problemi come l’impossibilità di avviare il pacchetto, errori di connessione o cali di prestazioni.

Questa guida aiuta gli utenti ServBay a diagnosticare e risolvere le problematiche più frequenti con i pacchetti MariaDB/MySQL. Verranno presentati possibili cause, passaggi diagnostici e soluzioni pratiche, con percorsi e comandi specifici per l’ambiente ServBay.

Avviso importante:

Prima di eseguire qualsiasi operazione che possa modificare dati o configurazioni, è indispensabile eseguire il backup del database! ServBay include una funzione di backup integrata: il consiglio è di utilizzarla regolarmente.
Comandi e percorsi negli esempi fanno riferimento a versioni specifiche (es. 11.3 o 11.5). Sostituisci la versione indicata con quella realmente usata in ServBay. Puoi verificarla facilmente dall’interfaccia di ServBay, dove sono elencate le versioni installate.
Nei comandi di esempio, <username>, <database>, <your_backup.sql> e simili sono segnaposto da sostituire con tuoi dati reali (nome utente, database, file di backup, ecc.).
La guida è valida per macOS e Windows; le sezioni specifiche contengono percorsi e comandi mirati per ciascun sistema operativo.

Passaggi diagnostici generali

Prima di approfondire la ricerca della causa del problema, segue una checklist di base:

Verifica lo stato del pacchetto ServBay: Apri l’interfaccia ServBay e assicurati che la versione MariaDB/MySQL che vuoi usare sia attiva e “in esecuzione”. Puoi anche controllare da terminale:
bash
```
servbayctl status mariadb <version>
# Esempio, controllare MariaDB 11.3:
servbayctl status mariadb 11.3
```
1
2
3
Consulta i log dell’applicazione ServBay: Spesso ServBay registra errori quando avvia o gestisce i pacchetti. Trovali nell’area log dell’applicazione o nel file log principale di ServBay.

Consulta i log degli errori MariaDB/MySQL: Sono fondamentali per diagnosticare errori di avvio o di runtime del database. Percorsi tipici:

macOS:

bash

/Applications/ServBay/logs/mariadb/<version>/<version>.err
# Esempio, mostrare le ultime 50 righe del log errori di MariaDB 11.3:
tail -n 50 /Applications/ServBay/logs/mariadb/11.3/11.3.err

Windows:

cmd

C:\ServBay\logs\mariadb\<version>\<version>.err
# Esempio, mostrare le ultime 50 righe del log errori di MariaDB 11.3:
powershell "Get-Content -Path 'C:\ServBay\logs\mariadb\11.3\11.3.err' -Tail 50"

Esamina attentamente i messaggi di errore recenti: spesso indicano direttamente la natura del problema.

Problemi comuni e soluzioni

1. Errore di connessione: `SQLSTATE[HY000] [2002] No such file or directory`

Questo errore indica che il client non riesce a connettersi a MariaDB/MySQL tramite il file socket Unix. Su macOS, il socket Unix è usato per la comunicazione locale: è più efficiente del collegamento TCP/IP. Quando uno strumento cerca il file socket in una posizione sbagliata, si verifica questo errore.

Cause possibili e soluzioni:

Pacchetto MariaDB/MySQL non attivo:
- Verifica nell’interfaccia ServBay o con servbayctl status mariadb <version> che il pacchetto sia in esecuzione.
- Se non lo è, avvialo con: servbayctl start mariadb <version>, e controlla i log errori (.err) per dettagli sull’eventuale fallimento.
Percorso del file socket non corretto (solo macOS/Linux):
- Il percorso usato dal client potrebbe non corrispondere a quello configurato nel server (my.cnf).
- macOS: Controlla il parametro socket nel file di configurazione MariaDB/MySQL (/Applications/ServBay/etc/mariadb/<version>/my.cnf).
- Windows: Su Windows non si usa il socket Unix, ma named pipe o connessione TCP/IP.
- macOS: Verifica che l’app o client usi il percorso socket giusto, oppure il path predefinito ServBay: tipicamente /Applications/ServBay/tmp/ o /tmp/ (es. /Applications/ServBay/tmp/mysql.sock o /tmp/mysql.sock).
Configurazione ServBay non corretta:
- In “Impostazioni” -> “SQL Server predefinito” in ServBay, verifica che la versione corretta sia impostata. Alcuni strumenti (come la CLI mysql senza specifica -S o -h) cercheranno il socket della versione predefinita.
Problemi di permessi:
- macOS: L’utente che esegue MariaDB/MySQL deve poter scrivere nella cartella del socket e il client deve poter leggere il file. ServBay gestisce di default i permessi, ma se hai modificato manualmente /Applications/ServBay/tmp/ o /tmp/, potresti dover ripristinare permessi adeguati.
- Windows: L’account che esegue ServBay deve poter ascoltare sulla porta specificata e creare named pipe.

Alternativa (forzare la connessione via rete):

Prova a collegarti con l’IP 127.0.0.1 anziché localhost: in questo modo il client userà TCP/IP invece del socket. Se la connessione con 127.0.0.1 funziona, il problema è quasi sicuramente legato al file socket.
bash
```
mysql -u <username> -p -h 127.0.0.1 -P 3306
```
1

2. Errore di connessione: problemi di rete (`Connection refused`, `Can't connect to MySQL server`, ecc.)

Questo tipo di errore indica che il client non riesce a collegarsi a MariaDB/MySQL tramite TCP/IP.

Cause possibili e soluzioni:

Pacchetto MariaDB/MySQL non attivo: (vedi sopra, verifica stato e log errori)
Porta occupata:
- Verifica che la porta di ascolto (di default 3306) non sia già usata da altri processi.
macOS:
bash
```
lsof -i :3306
# oppure
netstat -anv | grep LISTEN | grep 3306
```
1
2
3
Windows:
cmd
```
netstat -an | findstr :3306
# oppure PowerShell
Get-NetTCPConnection -LocalPort 3306
```
1
2
3
Se la porta è occupata, termina il processo che la usa, oppure modifica port nel file di configurazione MariaDB/MySQL, e riavvia il servizio.
- macOS: /Applications/ServBay/etc/mariadb/<version>/my.cnf
- Windows: C:\ServBay\etc\mariadb\<version>\my.cnf

Firewall blocca la connessione:

macOS:

Controlla in Impostazioni di sistema -> Rete -> Firewall.

Per consentire a mysqld di passare il firewall (modifica il percorso secondo la tua installazione):

bash

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:

Verifica le regole di Windows Defender Firewall o altri firewall installati.

Puoi aggiungere una regola per consentire il programma o la porta:

cmd

netsh advfirewall firewall add rule name="ServBay MariaDB" dir=in action=allow program="C:\ServBay\bin\mariadb\<version>\bin\mysqld.exe"

Problemi di configurazione (bind-address):
- Controlla il parametro bind-address in my.cnf. Se impostato su 127.0.0.1 o localhost, solo le connessioni locali saranno accettate. Per accedere da altre macchine o VM, imposta su 0.0.0.0 o un IP specifico e assicurati che il firewall permetta le connessioni.
Problemi di risoluzione di rete (localhost):
- Assicurati che localhost sia correttamente risolto in 127.0.0.1 (IPv4) e ::1 (IPv6).
macOS:
bash
```
ping localhost
cat /etc/hosts
```
1
2
Windows:
cmd
```
ping localhost
type C:\Windows\System32\drivers\etc\hosts
```
1
2
Il file hosts deve avere la giusta voce per localhost. Disattiva eventuali software proxy che potrebbero interferire con la rete locale.

3. Impossibilità di avviare il pacchetto MariaDB/MySQL

Cause possibili e soluzioni:

Consulta il log errori (fondamentale!): Come sopra, cerca dettagli precisi nel file di log errori.
- macOS: /Applications/ServBay/logs/mariadb/<version>/<version>.err
- Windows: C:\ServBay\logs\mariadb\<version>\<version>.err

Errore nel file di configurazione: Possibili errori di sintassi, parametri non validi o percorsi sbagliati.

Percorso file configurazione:

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

Validazione della sintassi:

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

Porta occupata: (vedi sopra, usa lsof o netstat)
Spazio su disco insufficiente: La directory dati o la directory log potrebbero trovarsi su una partizione piena. Il database necessita di spazio per scrivere dati, log e file temporanei.
Percorsi:
- macOS: dati /Applications/ServBay/db/mariadb/<version>/, log /Applications/ServBay/logs/mariadb/<version>/
- Windows: dati C:\ServBay\db\mariadb\<version>\, log C:\ServBay\logs\mariadb\<version>\
Permessi insufficienti: L’utente che esegue MariaDB/MySQL deve poter leggere il file di configurazione, scrivere nella cartella dati e log. ServBay di solito gestisce i permessi, ma eventuali cambiamenti manuali possono generare problemi.
macOS - verifica permessi:
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
Verifica che l’utente del database (tipicamente _mysql) abbia i diritti necessari.
Windows - verifica permessi: Usa Esplora risorse per controllare proprietà e permessi delle cartelle/file; l’account ServBay deve avere lettura/scrittura dove necessario.
File dati danneggiati: (vedi sezione successiva). Un arresto improvviso o problemi hardware potrebbero aver corrotto i dati, impedendo l’avvio.

Dopo la risoluzione:

Prova a riavviare il pacchetto: servbayctl restart mariadb <version>

4. Problemi di autorizzazione o autenticazione utente

Anche a connessione avvenuta, errori come Access denied possono derivare da credenziali o permessi errati.

Cause possibili e soluzioni:

Errore di username o password: Verifica che le credenziali usate siano corrette. ServBay permette di reimpostare facilmente la password dell’utente root.
Restrizione sul parametro host: Un utente può essere autorizzato solo da determinati host (es. 'utente'@'localhost'); la connessione da 'utente'@'127.0.0.1' può non essere permessa. Usa '%' per consentire accessi da qualsiasi host.
Permessi insufficienti: Un utente potrebbe non avere privilegi di accesso al database desiderato, o per eseguire operazioni come SELECT, INSERT, ecc.

Controlla i permessi utente:

Accedi con un utente amministratore (es. root):
bash
```
mysql -u root -p
```
1

Visualizza i permessi di uno specifico utente:

sql

SHOW GRANTS FOR '<username>'@'<hostname>';
-- Esempio, per 'webapp' da 'localhost':
SHOW GRANTS FOR 'webapp'@'localhost';
-- Esempio, per 'admin' da qualsiasi host:
SHOW GRANTS FOR 'admin'@'%';

Se necessario, modifica permessi con GRANT e REVOKE, o crea nuovi utenti.

5. Problemi di prestazioni

Prestazioni scarse del database rallentano l’app o l’intero ambiente.

Cause possibili e soluzioni:

Query lente: Query inefficienti, mancanza di indici, cattiva strategia di esecuzione.
- Abilita il log delle query lente: Imposta nel file my.cnf i parametri slow_query_log = 1 e long_query_time = 1 (per registrare le query che impiegano più di 1 secondo), e indica un file log apposito. Dopo il riavvio, analizza il file log per trovare le query problematiche.
- Usa EXPLAIN: Preponi EXPLAIN a una query sospetta per vedere l’esecuzione (uso indici, righe analizzate, colli di bottiglia).
  sql
```
EXPLAIN SELECT * FROM your_table_name WHERE column_name = 'value';
```
  1
- Ottimizza la query: Modifica la consulta secondo le risultanze di EXPLAIN; evita SELECT *, funzioni su colonne nel WHERE, verifica l’uso corretto degli indici.
Mancanza/errata configurazione indici: L’assenza di indici su colonne usate in WHERE, ORDER BY, GROUP BY provoca scansioni totali delle tabelle.
- Analizza struttura e query tipiche: Decidi dove creare indici.
- Crea un indice:
  sql
```
CREATE INDEX idx_column_name ON your_table_name(column_name);
```
  1
  Attenzione: gli indici aumentano i costi di scrittura e occupano spazio disco; valuta pro e contro.
Configurazione cache non ottimale: Valori troppo piccoli o troppo grandi per parametri come innodb_buffer_pool_size, key_buffer_size (MyISAM) nel file my.cnf.
- Modifica la configurazione: Adatta cache e buffer alle risorse disponibili (RAM, uso dei dati, ecc.). Per InnoDB, imposta innodb_buffer_pool_size al 50-70% della RAM se il server è usato solo dal database; dopo le modifiche, riavvia MariaDB/MySQL.
  ini
```
[mysqld]
innodb_buffer_pool_size = 2G
# Se usi molti tavoli MyISAM:
# key_buffer_size = 256M
```
  1
  2
  3
  4
Limiti hardware: Uso elevato di CPU, poca RAM (swap frequenti), disco I/O lento. Usa Activity Monitor (macOS) o top/htop per monitorare CPU, RAM, disco, rete e identificare il collo di bottiglia.

6. Database in crash o corruzione dei dati

Se il database non si avvia, crasha spesso, o riscontri errori/dati illegibili, potresti avere i file dati corrotti.

Cause possibili e soluzioni:

Leggi il log errori: Come sempre, il log è essenziale; cerca errori InnoDB, problemi del filesystem o segnalazioni hardware.
- macOS: /Applications/ServBay/logs/mariadb/<version>/<version>.err
- Windows: C:\ServBay\logs\mariadb\<version>\<version>.err
Guasti hardware: Errori disco o RAM possono corrompere i dati. Consulta log sistema (Console.app) o usa tool diagnostici.
Bug software o conflitti: Alcune versioni di MariaDB/MySQL possono contenere bug gravi, o possono essere influenzate da altri software.
Configurazione errata: Parametri sbagliati nel file my.cnf possono causare instabilità o crash.
Arresti forzati: Uscire dal programma ServBay o terminare forzatamente i processi MariaDB/MySQL può lasciare dati in stato incoerente.

Soluzioni:

Prova il riavvio sicuro: Dal pannello ServBay o via CLI: servbayctl restart mariadb <version>. Il database potrebbe recuperare lo stato autonomamente.
Usa mysqlcheck per eseguire check e riparazione tabelle: Con questo strumento si verifica l’integrità delle tabelle e si tenta una riparazione (soprattutto per MyISAM).
bash
```
mysqlcheck --defaults-file=/Applications/ServBay/etc/mariadb/<version>/my.cnf -u root -p --check --all-databases
# Per tabelle MyISAM, tenta la riparazione automatica:
# mysqlcheck --defaults-file=/Applications/ServBay/etc/mariadb/<version>/my.cnf -u root -p --auto-repair --check --all-databases
```
1
2
3
Nota: --auto-repair è soprattutto per MyISAM. Per InnoDB, --check individua il problema; la riparazione richiede procedure più avanzate (vedi sotto).
Recupero forzato InnoDB (innodb_force_recovery): Se InnoDB non parte (log con errore InnoDB), puoi tentare il recupero forzato. Attenzione: è rischioso e può causare perdita o incoerenza dei dati! Va usato solo se non puoi avviare il server normalmente e devi esportare i dati per il backup.
1. Esegui comunque prima il backup della directory dati anche se danneggiata: Copia /Applications/ServBay/db/mariadb/<version>/ altrove.
2. Modifica il file my.cnf della versione coinvolta.
3. Sotto [mysqld], aggiungi una riga: innodb_force_recovery = N (dove N va da 1 a 6; prova a salire gradualmente). Riavvia ogni volta e ferma se non parte.
4. Riavvia MariaDB/MySQL: servbayctl start mariadb <version>.
5. Se parte (in modalità limitata/sola lettura), effettua subito backup 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
  Controlla che il file backup sia stato generato e abbia una dimensione adeguata.
6. Dopo il backup, ferma subito MariaDB/MySQL: servbayctl stop mariadb <version>.
7. Rimuovi o commenta la riga innodb_force_recovery = N dal file my.cnf.
8. Procedi alla migrazione dati: Di solito si crea una directory dati nuova e vi si importa il backup appena creato.

Ripristino da backup: Se il database è irrecuperabile o incoerente, la soluzione migliore è ripristinare dall’ultimo backup valido. ServBay genera backup in /Applications/ServBay/backup/mariadb/<version>/ (se usi la funzione integrata).

Esempio comando di ripristino (supponendo backup per <target_database_name>):

bash

# Il database di destinazione deve esistere
# mysql --defaults-file=/Applications/ServBay/etc/mariadb/<version>/my.cnf -u root -p -e "CREATE DATABASE <target_database_name>;"

# Importa il 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: <version> va sostituito con la versione desiderata.

7. Problemi durante backup e ripristino

Sia con la funzione di backup ServBay che manualmente con mysqldump, potresti incontrare errori.

Cause possibili e soluzioni:

File backup incompleto o danneggiato:
- Controlla la dimensione (ls -lh /percorso/del/file.sql); verifica che corrisponda alle aspettative.
- Apri con un editor testuale o less /percorso/del/file.sql per verificarne la validità.
- Controlla messaggi di errore durante il dump; se hai usato ServBay, consulta i log per dettaglio esecuzione backup.
Errore comando di ripristino:
- Username, password, nome database errati.
- Utente senza i permessi necessari.
- Errori di sintassi SQL dovuti a incompatibilità tra versioni/database (es. backup MySQL importato su MariaDB o viceversa).
Problemi con le chiavi esterne: Se l’ordine delle importazioni non rispetta le dipendenze, le foreign key possono generare errori. Si può temporaneamente disattivarle:
sql
```
-- Prima dell’import:
SET foreign_key_checks = 0;
-- Importa il file:
source /path/to/your_backup.sql; -- Da client mysql
-- Oppure: mysql ... < /path/to/your_backup.sql

-- Dopo l’import:
SET foreign_key_checks = 1;
```
1
2
3
4
5
6
7
8
Nota: Disattiva le chiavi solo in fase di import; può causare incoerenza dati se usata impropriamente.
Problemi di charset/collation: Backup creati con charset o regole di ordinamento incompatibili con il database di destinazione: possono generare errori o dati corrotti. Assicurati che tu usi lo stesso charset, ad esempio utf8mb4.

Ripristino corretto (esempio da command line):

macOS:

bash

# Supponendo che il backup sia di un singolo database
# Il database deve prima essere creato
# mysql --defaults-file=/Applications/ServBay/etc/mariadb/<version>/my.cnf -u root -p -e "CREATE DATABASE <target_database_name>;"

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

# Se il backup è stato generato con --all-databases, non serve il nome database
# mysql --defaults-file=/Applications/ServBay/etc/mariadb/<version>/my.cnf -u <username> -p < /Applications/ServBay/backup/mariadb/<version>/<your_backup.sql>

Windows:

cmd

REM Supponendo che il backup sia di un singolo database
REM Il database deve essere creato prima
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 Importa il file .sql
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 Se il backup è --all-databases, non serve il nome database
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: <version> va sostituito con la versione desiderata. Il backup ServBay è pensato per essere facilmente ripristinabile tramite questi passaggi.

8. Bug specifico: MariaDB 11.5.1 InnoDB fallisce all'avvio (`ib_logfile0 was not found` / `Missing FILE_CHECKPOINT`)

Questo è un grave bug noto nella versione MariaDB 11.5.1: il motore InnoDB non riesce ad inizializzare o a recuperare i dati dai file di log, causando il mancato avvio del database.

Caratteristiche del log errori:

Nell’errore potrai vedere messaggi come:

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

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

Oppure:

[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

Questi errori indicano che InnoDB non trova o non può gestire il file di log, non riuscendo a inizializzare.

Soluzione (coinvolge la migrazione dati, esegui sempre prima il backup):

Questo bug è noto e difficile da correggere con metodi standard: la soluzione migliore è avviare InnoDB in modalità di recupero per esportare i dati e trasferirli su una versione MariaDB più stabile.

Prova il recupero forzato per esportare i dati (operazione rischiosa!):

Modifica il file di configurazione:

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

Sotto [mysqld], aggiungi: innodb_force_recovery = 6

Avvia il servizio:

bash

servbayctl start mariadb 11.5

Se si avvia, esegui il backup immediatamente:

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

Controlla che il backup sia completo e abbia dimensione adeguata.

Ferma e gestisci la directory dati della versione problematica:
- Ferma MariaDB 11.5: servbayctl stop mariadb 11.5
- Modifica il file my.cnf ed elimina o commenta la riga `innodb_force_recovery

Guida alla risoluzione dei problemi del pacchetto ServBay MariaDB/MySQL ​

Introduzione ​

Passaggi diagnostici generali ​

Problemi comuni e soluzioni ​

1. Errore di connessione: SQLSTATE[HY000] [2002] No such file or directory ​

2. Errore di connessione: problemi di rete (Connection refused, Can't connect to MySQL server, ecc.) ​

3. Impossibilità di avviare il pacchetto MariaDB/MySQL ​

4. Problemi di autorizzazione o autenticazione utente ​

5. Problemi di prestazioni ​

6. Database in crash o corruzione dei dati ​

7. Problemi durante backup e ripristino ​

8. Bug specifico: MariaDB 11.5.1 InnoDB fallisce all'avvio (ib_logfile0 was not found / Missing FILE_CHECKPOINT) ​

Guida alla risoluzione dei problemi del pacchetto ServBay MariaDB/MySQL

Introduzione

Passaggi diagnostici generali

Problemi comuni e soluzioni

1. Errore di connessione: `SQLSTATE[HY000] [2002] No such file or directory`

2. Errore di connessione: problemi di rete (`Connection refused`, `Can't connect to MySQL server`, ecc.)

3. Impossibilità di avviare il pacchetto MariaDB/MySQL

4. Problemi di autorizzazione o autenticazione utente

5. Problemi di prestazioni

6. Database in crash o corruzione dei dati

7. Problemi durante backup e ripristino

8. Bug specifico: MariaDB 11.5.1 InnoDB fallisce all'avvio (`ib_logfile0 was not found` / `Missing FILE_CHECKPOINT`)