Creazione di un database IP-to-Country
Mappare un indirizzo IP al suo paese è ancora utile, per servire la lingua giusta, per analytics o per regole di accesso. Ma il modo in cui si costruisce un database IP-to-country è cambiato del tutto: oggi serve gestire IPv6, scegliere una fonte dati affidabile, fare il lookup per range nel modo corretto, e soprattutto sapere che un indirizzo IP è un dato personale sotto GDPR. Vediamo come si fa nel 2026, partendo dalla domanda che conviene farsi: ti serve davvero un database tuo?. Continua a leggere
Ultima modifica:
mysqldump su database da 200GB richiede 4 ore e blocca le query durante l'esecuzione. Con Percona XtraBackup ho configurato backup incrementali ogni ora senza un singolo lock: il database continua a servire richieste, il backup è verificabile, il recovery è testato settimanalmente in automatico. Vi mostro la configurazione completa. 
Lanciare mysqldump su un database in produzione senza fermare i servizi è possibile, ma il modo in cui si fa cambia tutto. La ricetta che gira da anni, basata su --lock-tables=false, evita i blocchi ma produce un dump che può essere internamente incoerente: un dettaglio che non si nota finché non provi a ripristinarlo. La soluzione corretta per le tabelle InnoDB è --single-transaction, che dà uno snapshot consistente senza lock prolungati. 
Il reparto finance di un cliente generava i report mensili esportando 50.000 righe in Excel e filtrando manualmente. Ho costruito una dashboard Laravel con report pre-aggregati: query ottimizzate con indici covering, cache di 4 ore con invalidazione selettiva, export PDF/Excel e grafici interattivi con Chart.js. 
Un portale di notizie Laravel con 50.000 utenti al giorno mandava in ginocchio il database MySQL ogni volta che arrivava un articolo virale. Ho implementato tre livelli di cache: in-process (array driver), Redis per i dati di business, Nginx proxy cache per le risposte HTTP. Il database ora riceve il 3% delle richieste originali. 
Doctrine è potente ma le sue trappole di performance sono subdole. Ho ottimizzato un'applicazione Symfony con 2 milioni di record: lazy loading che generava 8.000 query per pagina, identity map che saturava la memoria nei batch, eager loading mal configurato. Vi mostro le soluzioni sistematiche per ciascun problema. 
Il backup di un server web non è uno script da lanciare e dimenticare: è una strategia che mette insieme due cose diverse, i file e i database, ognuna con le sue regole. Il vecchio approccio "un programma che zippa tutto e te lo manda via email" è pericoloso: password in chiaro, nessuna cifratura, copia sulla stessa macchina. Vediamo come si fa davvero nel 2026, con gli strumenti giusti e la regola che conta più di tutte: un backup non è un backup finché non lo hai ripristinato. 
L'errore "Data truncated for column" durante l'import di un dump MySQL è uno dei più comuni e dei più fraintesi quando si spostano dati fra ambienti configurati in modo diverso. La diagnosi corretta non è quella che suggeriscono molti tutorial: la causa reale è lo strict sql_mode, che promuove a errore bloccante una troncatura che altrove sarebbe un semplice avviso. Vediamo cos'è davvero questo errore, le cinque cause che lo scatenano, e come si risolve e si previene. 
Ho costruito tre SaaS multi-tenant in Laravel negli ultimi tre anni con approcci diversi: database per tenant (massimo isolamento, costo elevato), schema per tenant (buon compromesso), colonna tenant_id (semplice, rischio di data leak tra tenant). Vi racconto i trade-off reali e quando ho cambiato idea. 
Un'API pubblica Laravel per la verifica dei codici fiscali veniva martellata da scraper: 4.000 richieste al minuto da IP singoli. Il throttle di default di Laravel non bastava. Ho implementato un sistema multi-livello: rate limit per IP, per chiave API, per endpoint e un adaptive rate limiter che scala in base al carico.