Il server MySQL è andato via ostacolando l'importazione di grandi dump

Sto cercando di importare un dump sql di grandi dimensioni (2 GB) nel mio mysql locale sul mio mac. Sono stato in grado di farlo in passato (stavo usando MAMP), ma ora ricevo un ERRORE 2006 (HY000) alla linea 7758: il server MySQL è andato via ogni volta che provo a importare il dump. Il database contiene tabelle innodb.

Ho provato a copiare il file my-innodb-heavy-4G.cnf sul mio my.cnf per vedere se quelle impostazioni avrebbero aiutato, ma senza fortuna.

Qualche idea su cosa modificare?

Sto usando "Mac OS X ver. 10.6 (x86, 64-bit), Archivio DMG" da qui: http://dev.mysql.com/downloads/mysql/

Uno dei killer silenziosi di MySQL Connections è il pacchetto MySQL. Anche il thread I / O di MySQL Replication può essere vittima di questo.

Secondo la documentazione di MySQL

• È inoltre possibile ottenere questi errori se si invia una query al server errata o troppo grande. Se mysqld riceve un pacchetto che è troppo grande o fuori servizio, presuppone che qualcosa sia andato storto con il client e chiude la connessione. Se sono necessarie query di grandi dimensioni (ad esempio, se si utilizzano colonne BLOB di grandi dimensioni), è possibile aumentare il limite di query impostando la variabile max_allowed_packet del server, che ha un valore predefinito di 1 MB. Potrebbe inoltre essere necessario aumentare la dimensione massima del pacchetto sul lato client. Ulteriori informazioni sull'impostazione della dimensione del pacchetto sono fornite nella Sezione C.5.2.10, "Pacchetto troppo grande".

• Un'istruzione INSERT o REPLACE che inserisce molte righe può anche causare questo tipo di errori. Una di queste affermazioni invia una singola richiesta al server indipendentemente dal numero di righe da inserire; pertanto, è spesso possibile evitare l'errore riducendo il numero di righe inviate per INSERT o REPLACE.

Per lo meno, è necessario assicurarsi che le dimensioni dei pacchetti sia per la macchina da cui si è verificato il mysqldump sia per la macchina che si sta caricando siano identiche.

È possibile adottare due (2) approcci:

APPROCCIO # 1: esegui mysqldump usando --skip-extended-insert

Ciò assicurerà che il pacchetto MySQL non sia inondato da più BLOB, campi TEXT. In questo modo gli INSERTI SQL vengono eseguiti uno alla volta. I principali svantaggi sono

1. il mysqldump è molto più grande
2. ricaricare una tale discarica richiede molto più tempo.

APPROCCIO # 2: Aumenta max_allowed_packet

Questo potrebbe essere l'approccio preferito perché l'implementazione di questo è solo un riavvio mysql. Comprendere che cos'è il pacchetto MySQL può chiarire questo.

Secondo la pagina 99 di "Comprensione di MySQL Internals" (ISBN 0-596-00957-7) , ecco i paragrafi 1-3 che lo spiegano:

Il codice di comunicazione della rete MySQL è stato scritto partendo dal presupposto che le query sono sempre ragionevolmente brevi e pertanto possono essere inviate ed elaborate dal server in un unico blocco, che viene chiamato pacchetto nella terminologia MySQL. Il server alloca la memoria per un buffer temporaneo per archiviare il pacchetto e richiede abbastanza per adattarlo interamente. Questa architettura richiede una precauzione per evitare che il server esaurisca la memoria, ovvero un limite alla dimensione del pacchetto, che questa opzione consente.

Il codice di interesse in relazione a questa opzione si trova in sql / net_serv.cc . Dai un'occhiata a my_net_read () , quindi segui la chiamata a my_real_read () e presta particolare attenzione a net_realloc () .

Questa variabile limita anche la lunghezza di un risultato di molte funzioni stringa. Vedi sql / field.cc e sql / intem_strfunc.cc per i dettagli.

Data questa spiegazione, la creazione di INSERT in blocco caricherà / scaricherà un pacchetto MySQL piuttosto rapidamente. Ciò è particolarmente vero quando max_allowed_packet è troppo piccolo per il dato carico di dati che lo arrivano.

CONCLUSIONE

Nella maggior parte delle installazioni di MySQL, di solito lo imposto su 256M o 512M. Dovresti sperimentare valori più grandi quando i carichi di dati generano errori "MySQL è andato via".

Quanto dura questo tempo prima del timeout? Il primo passo sarebbe scommettere per controllare le impostazioni wait_timeoute interactive_timeoutper assicurarsi che siano abbastanza grandi per la tua importazione:

SHOW VARIABLES LIKE '%_timeout';
SET SESSION wait_timeout=28800;

L'impostazione predefinita è 8 ore (28800), quindi potenzialmente non è questo il problema. Altre indicazioni di questo problema sono disponibili qui . Uno che si distingue è questo:

Un'applicazione client in esecuzione su un host diverso non dispone dei privilegi necessari per connettersi al server MySQL da quell'host.

Verifica prima le autorizzazioni, ma poi consulta l'elenco di potenziali problemi.

Sì, di solito giocare con wait_timeout e max_allowed_packets mi permette di aggirare anche il messaggio di errore.

Potrebbe non essere la cosa "corretta" da fare, ma potrebbe funzionare (fai ', vero?):

Prova a suddividere il tuo dump di grandi dimensioni in più file ed eseguirli uno alla volta in sequenza. Il mio approccio sarebbe di romperlo a metà e testarlo. Quindi spezzare ogni metà a metà, ripetere il test e così via.

Sono un po 'curioso se la quantità di RAM che hai sulla tua scatola potrebbe avere qualcosa a che fare con questo. MySQL carica l'intero dump in memoria quando viene eseguito? Non lo so ... ma se hai solo 2 GB di RAM e alcuni di essi sono in uso con il tuo sistema operativo e altre app, allora questo potrebbe essere il problema.

Coloro che non hanno avuto successo con gli altri suggerimenti potrebbero considerare di dare un'occhiata allo script dell'importatore di dump MySQL sfalsato di BigDump PHP .

È una soluzione alternativa per l'importazione di grandi dump di database in MySQL. L'ho usato con successo per importare un dump MySQL di grandi dimensioni nel mio ambiente di sviluppo locale (in questo caso sto usando MAMP).