Usa MySQL se il tuo network condivide dati tra più server (Bungee o Velocity) o gestisce dataset che superano ciò che un singolo file SQLite può maneggiare senza intoppi. Per un server singolo con pochi plugin, SQLite resta spesso la scelta più semplice e leggera. In produzione serve comunque un server database accessibile, una stringa di connessione JDBC configurata correttamente e un pool di connessioni dimensionato bene: senza questi tre elementi rischi lag, disconnessioni improvvise e, nei casi peggiori, dati persi.
In breve:
- MySQL è consigliato per network multi-server o dataset di grandi dimensioni, mentre SQLite può risultare più efficiente per server singoli con caricamento in memoria.
- È fondamentale dimensionare correttamente il pool di connessioni HikariCP, considerando il limite di connessioni di MySQL e il numero di server collegati, per evitare blocchi e errori di saturazione.
- La migrazione da SQLite a MySQL può richiedere anche oltre un’ora se si tratta di grandi log, ed è preferibile pianificarla durante finestre di manutenzione.
- Per evitare errori di autenticazione con MySQL 8, bisogna modificare il metodo di autenticazione o aggiornare il driver JDBC, poiché il plugin predefinito è spesso incompatibile.
- Usare un pannello di hosting con gestione automatica di database e backup semplifica moltissimo la configurazione, oltre a permettere di risparmiare tempo e risorse tecniche.
Indice
- Quando preferire MySQL rispetto a SQLite
- Configurare il database: comandi, config.yml e connessione Java
- Connection pooling con HikariCP: come evitare di saturare il database
- Best practice per query sicure e prestazioni stabili
- Migrare da SQLite a MySQL senza sorprese
- Perché un hosting con pannello dedicato semplifica la vita a chi usa MySQL
- Come AtomSync semplifica la gestione del database per il tuo server
- Fonti
- Domande frequenti
Quando preferire MySQL rispetto a SQLite
La domanda giusta non è «MySQL è meglio di SQLite?» ma «il mio caso d’uso ha bisogno di condivisione dati tra processi diversi?». Se gestisci un network Minecraft con più server dietro un proxy Bungee o Velocity, MySQL diventa quasi obbligatorio: è l’unico modo sensato per far leggere e scrivere gli stessi dati economici o di permessi a server diversi contemporaneamente. Le guide della community concordano su questo punto: MySQL è preferibile per network multi-server e per dataset di grandi dimensioni, mentre SQLite è spesso considerata una scelta semplice e leggera adatta a singoli server.
C’è però un rovescio della medaglia che molti trascurano. Se il tuo plugin carica l’intero dataset in memoria all’avvio e non fa query frequenti durante il gioco, aggiungere MySQL può addirittura peggiorare le prestazioni rispetto a un semplice file locale, perché introduce latenza di rete inutile per un problema che non esiste.
Prima di decidere, valuta questi fattori:
- Numero di server che devono leggere gli stessi dati in tempo reale
- Volume previsto di record (player_stats con migliaia di giocatori attivi pesa diversamente da un piccolo whitelist)
- Necessità di backup e replica centralizzati invece di file sparsi su più macchine
- Tipo di plugin: economia, log delle azioni e sistemi di permessi beneficiano quasi sempre di MySQL; plugin di configurazione statica quasi mai
Configurare il database: comandi, config.yml e connessione Java
Il primo passo è creare database e utente sul server MySQL. Se usi un pannello di hosting con gestione database integrata, questi passaggi sono spesso automatizzati, ma vale la pena capire cosa succede dietro le quinte.
I comandi base da eseguire nella console MySQL sono questi:
| Operazione | Comando |
|---|---|
| Creare il database | CREATE DATABASE minecraft_server; |
| Creare l’utente | CREATE USER 'mc_user'@'%' IDENTIFIED BY 'password_sicura'; |
| Assegnare i permessi | GRANT ALL PRIVILEGES ON minecraft_server.* TO 'mc_user'@'%'; |
| Applicare le modifiche | FLUSH PRIVILEGES; |
Questa sequenza segue lo schema descritto nelle guide di migrazione da SQLite a MySQL, dove host, porta, nome database, utente e password vengono poi inseriti nel file di configurazione del plugin.
Un tipico config.yml per un plugin che supporta entrambi i backend somiglia a questo:
storage:
type: mysql
host: 127.0.0.1
port: 3306
database: minecraft_server
username: mc_user
password: password_sicura
pool-settings:
maximum-pool-size: 10
connection-timeout: 5000
Sul lato Java, la connessione parte dalla costruzione dell’URL JDBC e dalla creazione delle tabelle necessarie:
String url = "jdbc:mysql://127.0.0.1:3306/minecraft_server?useSSL=false&serverTimezone=UTC";
Connection conn = DriverManager.getConnection(url, "mc_user", "password_sicura");
String createTable = "CREATE TABLE IF NOT EXISTS player_stats (" +
"uuid VARCHAR(36) PRIMARY KEY, " +
"name VARCHAR(16), " +
"kills INT DEFAULT 0, " +
"deaths INT DEFAULT 0, " +
"coins DOUBLE DEFAULT 0, " +
"playtime BIGINT DEFAULT 0" +
") ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;";
Questo schema per player_stats, con motore InnoDB e carnet utf8mb4, è uno standard consolidato che supporta emoji e caratteri speciali nei viciname senza problemi di codifica. Per il driver, aggiungi la dipendenza MySQL Connector/J tramite Maven o Gradle: senza quella libreria, DriverManager non troverà il driver e la connessione fallirà con un errore poco chiaro.
Connection pooling con HikariCP: come evitare di saturare il database
Aprire una nuova connessione MySQL per ogni singola query è uno degli errori più comuni tra chi inizia a integrare database in un plugin Minecraft. Ogni connessione ha un costo in termini di tempo (handshake TCP, autenticazione) e di risorse sul server database. HikariCP risolve il problema mantenendo un pool di connessioni già aperte e pronte all’uso, riducendo drasticamente la latenza delle query rispetto ad aprire connessioni on demand.
Il parametro più delicato da impostare è maximumPoolSize. MySQL ha un limite predefinito di 151 connessioni simultanee (max_connections), e questo limite è condiviso da tutti i backend che si collegano allo stesso database. Se hai diversi server Spigot dietro un proxy Velocity e ognuno apre un pool con un numero elevato di connessioni, potresti raggiungere il limite massimo di connessioni disponibili al database, lasciando zero margine per altri plugin o strumenti di amministrazione.
Un consiglio: calcola il pool moltiplicando il numero di backend per la dimensione del pool per singolo server, e tieni il totale ben sotto il limite max_connections del tuo database. Un valore moderato per backend è generalmente sufficiente per un plugin Minecraft.
Le indicazioni ufficiali su come dimensionare correttamente i pool di connessione valgono anche fuori dal contesto cloud: il principio è lo stesso, evitare che troppi client saturino le connessioni disponibili sul server database.
Oltre a maximumPoolSize, tieni d’occhio questi parametri:
connection-timeout: quanto aspettare prima di segnalare errore se il pool è esaurito, tipicamente 5.000 millisecondimax-lifetime: la durata massima di una connessione prima che venga riciclata, per evitare connessioni “morte” lasciate aperte troppo a lungoidle-timeout: dopo quanto tempo di inattività una connessione inutilizzata viene chiusa
Segni di saturazione includono errori intermittenti di tipo «too many connections» nei log del server e picchi di lag proprio nei momenti di massimo traffico giocatori, quando più thread richiedono connessioni contemporaneamente.
Best practice per query sicure e prestazioni stabili
Le query lente sul main thread sono la causa numero uno di lag percepito dai giocatori, molto più spesso di quanto si pensi guardando solo l’uso della CPU. Un plugin ben scritto segue alcune regole precise nella gestione del database.
- Esegui le query pesanti in modo asincrono. Usa uno scheduler (come
BukkitSchedulerconrunTaskAsynchronously) per qualsiasi query che non serva il risultato immediato nel tick corrente, poi torna sul thread principale solo per applicare il risultato al mondo di gioco. - Usa sempre PreparedStatement, mai concatenazione di stringhe. Oltre a prevenire SQL injection, un PreparedStatement permette a MySQL di riutilizzare il piano di esecuzione della query, con un guadagno di prestazioni misurabile su query ripetute migliaia di volte al giorno.
- Chiudi le risorse con try-with-resources.
Connection,PreparedStatementeResultSetvanno chiusi sempre, anche in caso di eccezione: il blocco try-with-resources di Java lo garantisce automaticamente senza bisogno di unfinallyesplicito. - Crea indici sulle colonne interrogate spesso. Una colonna
uuidsenza indice su una tabella con centinaia di migliaia di righe trasforma una query da istantanea a percettibilmente lenta, soprattutto durante i picchi di connessione dei giocatori.
Le linee guida su PreparedStatement, gestione asincrona e chiusura delle risorse sono ormai uno standard condiviso in tutta la documentazione tecnica per plugin Spigot e Paper, e valgono indipendentemente dal framework specifico che usi.
Migrare da SQLite a MySQL senza sorprese
La migrazione segue quasi sempre lo stesso schema per i plugin più diffusi: cambi il valore storage.type nel config da sqlite a mysql, inserisci le credenziali del nuovo database, poi riavvii il plugin lasciando che il suo strumento di importazione integrato trasferisca i dati.
Plugin come LuckPerms offrono comandi di export/import dedicati, mentre CoreProtect ha un proprio strumento di migrazione pensato specificamente per gestire i suoi log, spesso enormi dopo mesi di attività. Ecco cosa considerare prima di lanciare la migrazione:
- Su database molto grandi, con decine di milioni di record di log, la migrazione può richiedere un tempo prolungato, specialmente per database molto grandi: pianificala durante una finestra di manutenzione o un reset di mappa, non mentre i giocatori sono online.
- Monitora la console durante il processo: la maggior parte degli strumenti di migrazione riporta un avanzamento percentuale o un conteggio dei record trasferiti.
- Se ricevi errori di autenticazione con MySQL 8, il problema è quasi sempre il plugin
caching_sha2_passworddi default, che rompe la compatibilità con driver JDBC più vecchi: cambia il metodo di autenticazione dell’utente o aggiorna il driver. - Un errore «connection refused» indica quasi sempre porta o host sbagliati nel config, mentre un errore legato a
max_connectionsrichiede di alzare quel limite sul server MySQL o ridurre il pool dei client. - Usa la CLI di MySQL o MySQL Workbench per verificare manualmente che le tabelle siano state popolate correttamente prima di dichiarare la migrazione conclusa.
Perché un hosting con pannello dedicato semplifica la vita a chi usa MySQL
Configurare MySQL a mano è un buon esercizio la prima volta, ma diventa una perdita di tempo ogni volta successiva. Un pannello che crea database, gestisce backup automatici e fornisce già host, porta e credenziali pronte all’uso elimina gran parte degli errori di configurazione che abbiamo visto sopra, dal max_connections sbagliato all’autenticazione MySQL 8.
Il supporto in italiano conta più di quanto sembri: un errore di connessione JDBC alle due di notte si risolve molto più in fretta con qualcuno che capisce esattamente il tuo problema, senza dover tradurre log tecnici in inglese sotto pressione. Prima di scegliere un provider, chiedi sempre tre cose: quanti limiti di connessione impone il piano, con che frequenza fa i backup del database e se garantisce accesso remoto per strumenti come MySQL Workbench.
— Fabio Turi
Come AtomSync semplifica la gestione del database per il tuo server
Configurare da zero database, pool di connessioni e backup richiede tempo che potresti spendere sviluppando il tuo network invece che sistemando file di configurazione. Un pannello Pterodactyl personalizzato permette di creare e gestire il database MySQL del tuo server Minecraft con pochi clic, con backup automatici quotidiani già inclusi senza bisogno di script esterni.
Il supporto tecnico via Discord aiuta a risolvere in tempi rapidi problemi come errori di autenticazione o connessioni rifiutate, gli stessi che abbiamo affrontato in questa guida. L’accesso ai file di configurazione e alla documentazione per i plugin più comuni, da LuckPerms a EssentialsX, è pensato per chi vuole concentrarsi sul game play e sulla community piuttosto che sul tuning di un database. Se stai valutando dove ospitare il tuo prossimo network Minecraft, dai un’occhiata ai piani disponibili su AtomSync e verifica quale configurazione si adatta al numero di server che vuoi collegare.
Fonti
- Database Integration - Documentazione minecraft-modding | Codegrind
- How to Switch from SQLite to MySQL on Your Minecraft Server
- Cloud SQL MySQL sample (connection limits) | Google Cloud Documentation
- Should you use MySQL with a Minecraft plugin? | Minecraft
Domande frequenti
MySQL è sempre meglio di SQLite per Minecraft?
No. MySQL conviene su network multi-server o con dataset grandi, ma per un singolo server con plugin che caricano tutto in memoria all’avvio, SQLite può risultare più efficiente.
Quante connessioni MySQL posso usare senza problemi?
Il limite predefinito di MySQL è di alcune centinaia di connessioni simultanee, solitamente intorno a un centinaio, condiviso da tutti i backend collegati: dimensiona il pool HikariCP di conseguenza, di solito 5-10 connessioni per server.
Quanto dura la migrazione da SQLite a MySQL?
Per database piccoli è questione di secondi; per log molto grandi, come quelli di CoreProtect con milioni di record, può richiedere 30-60 minuti o più, meglio farla durante una manutenzione.
Come evito l’errore di autenticazione con MySQL 8?
L’errore nasce quasi sempre dal plugin di autenticazione caching_sha2_password di MySQL 8, incompatibile con driver JDBC più vecchi: cambia il metodo di autenticazione dell’utente o aggiorna il driver.
AtomSync gestisce già la configurazione MySQL per me?
Sì, il pannello Pterodactyl personalizzato di AtomSync permette di creare e gestire il database direttamente dall’interfaccia, con backup automatici quotidiani già attivi.