Stamattina mi è capitato un errore insolito, durante l'importazione di un file di dump di mysql da un server verso un altro server.
Inspiegabilmente, il conteggio delle righe di una tabella sul "server sorgente" era molto più alto rispetto al conteggio delle stesse righe sulla stessa tabella, ma del server di backup.
Quindi, per tentare di capire la ragione del problema, ho creato dapprima un dump della sola tabella "incriminata" dal server sorgente, con
mysqldump -u UTENTE -pPASSWORD --skip-add-locks --compact --quick --lock-tables=false --delayed-insert=true --no-create-info --skip-triggers DATABASE TABELLA | gzip > dump.sql.gz
Una volta effettuato il dump, ho provato ad importarlo sul server di backup, con
gunzip < dump.sql.gz | mysql -u UTENTE -pPASSWORD --force DATABASE
Risultato? Per quella tabella, durante l'importazione, venivano sollevati tantissimi errori da mysql, che recitavano:
ERROR 1265 (01000) at line 683: Data truncated for column 'column_name' at row 10
La ragione del problema? La configurazione del server mysql sul server di backup, in particolare la configurazione del parametro sql-mode su my.cnf, relativa alle impostazioni di safety dell'ambiente mysql.
Ho scoperto che quelle righe nel file di dump erano relative ad un vecchio sottoinsieme di valori che nel server principale erano stati scritti senza la modalità "NO_AUTO_VALUE_ON_ZERO", ovvero la modalità secondo la quale il server mysql non inserirà dei valori NULL di default per le colonne nullabili, se non direttamente specificato.
Per ovviare al problema, quindi, abbiamo 2 soluzioni: la prima è ricostruire la tabella "sorgente" con dei dati corretti, usando il metodo che più vi è comodo. La seconda soluzione è quella di disabilitare alcune impostazioni di safety sul server di backup.
Vi basterà quindi semplicemente rimuovere il token "NO_AUTO_VALUE_ON_ZERO" dalla configurazione di my.cnf per non ricevere più errori nell'importazione.
Ovviamente la soluzione 2 va bene sul server di backup perchè è appunto un server di backup, quindi nessuno vi verrà mai a dire nulla sulla coerenza dei dati o sulla bontà delle configurazioni di safety su quel server mysql. Ad ogni modo, la soluzione più corretta sarebbe quella di correggere le righe con errori di coerenza dei dati all'interno del server di origine e mantenere le impostazioni di safety così come sono per lavorare "allo stato dell'arte".
Nella fattispecie, per correggere la coerenza dei dati, dovrete necessariamente ciclare su tutte le righe della tabella, costruirvi una lista di insert, troncare la tabella, ed eseguire le insert calcolate prima.
