Modificato max_allowed_packet e continua a ricevere l'errore "Pacchetto troppo grande"

8

Uso mysqldump per creare un file flat a scopo di backup. Ho usato questo file per ricreare il database su un server alternativo. Ho eseguito il processo di importazione tramite ssh sulla riga di comando e ho ricevuto più Packet too Largeerrori.

Ho riavviato mysql con un max_allowed_packet molto più grande (ovvero 1000M) e ho ancora ricevuto l'errore. Ho anche tentato di impostare max_allowed_packet nel file di importazione, ma ho ancora ricevuto l'errore.

C'è un modo per assicurarsi che max_allowed_packet sia impostato e / o utilizzare mysqldump che creerà un file che non causa questo problema?

Per riferimento:

il file mysqldump non compresso è ~ 2 GB

il tipo di database è INNODB

— Patrick
fonte

5

Il primo a cui ho pensato è quello che controlla max_allowed_packet . Ecco cosa ho trovato:

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, 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 la memoria del server rimanga esaurita, ovvero un limite alla dimensione del pacchetto, che questa opzione realizza.

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 quella definizione di max_allowed_packet, ho scoperto qualcos'altro da ServerFault: innodb_log_file_size e innodb_log_buffer_size combinati devono essere più grandi di dieci volte il tuo oggetto BLOB più grande se ne hai molti di grandi

Tenendo presente queste due cose, aumenterei innodb_log_file_size in /etc/my.cnf alla dimensione massima consentita, 2047M. Questo ovviamente richiede quanto segue

service mysql stop
rm -f /var/lib/mysql/ib_logfile*
service mysql start

Ciò consentirà di ospitare qualsiasi grande blob che potresti avere nei tuoi dati.

— RolandoMySQLDBA
fonte

Curioso da dove provenga quel 10x: è solo una regola empirica o c'è un codice in MySQL che dice che alloca 10 buffer fissi, quindi ne hai bisogno per assicurarti che 1 di essi sia abbastanza grande?

— Gaius,

Questo libro è autorevole?

— Pacerier

2

MySQL max_allowed_packetdeve ancora rientrare nei limiti della shell che l'ha avviata - ulimit -amostra che data seg sizeè illimitato?

— Caio
fonte

2

Per qualche motivo, max_allowed_packetviene ignorato da mysqldump- in base alla progettazione ? Il complemento reale è net_buffer_length. Quindi invece prova

mysqldump --net_buffer_length=100k -u root -p databasename > dump.sql

— Leopd
fonte

È molto illuminante !!! Dato che la segnalazione di bug discute l'inserimento esteso insieme a questo problema, forse fare --skip-extended-insert può compensare alcuni ma genererà sicuramente un mysqldump più grande. +1 per te trovare questo diamante grezzo che Oracle lascerà per morto !!!

— RolandoMySQLDBA,

--skip-extended-insert funziona sicuramente, ma sul mio database ha rallentato il ripristino di 100 volte rendendolo inutilizzabile.

— Leopd,

Mi dispiace, le mie condoglianze. Forse fai in modo che mysqldump crei i file CSV e provi a ricaricarli utilizzando LOAD DATA INFILE e aumentando bulk_insert_buffer_size a 1G o 2G. Ehi, non lo sai mai !!!

— RolandoMySQLDBA