Qual è il modo più veloce per scaricare & amp; caricare un database MySQL InnoDB usando mysqldump?

Question

Vorrei creare una copia di un database con circa 40 tabelle InnoDB e circa 1,5 GB di dati con mysqldump e MySQL 5.1.

Quali sono i parametri migliori (es: --single-transazione) che comporteranno il dump e il caricamento più rapidi dei dati?

Inoltre, quando si caricano i dati nel secondo DB, è più veloce:

1) reindirizza i risultati direttamente alla seconda istanza del server MySQL e usa l'opzione --compress

o

2) caricalo da un file di testo (es .: mysql < my_sql_dump.sql)

Answer 1

Effettua il pipe direttamente in un'altra istanza, per evitare il sovraccarico del disco. Non preoccuparti di --compress a meno che non sia in esecuzione su una rete lenta, poiché su una LAN veloce o loopback l'overhead di rete non ha importanza.

Answer 2

Scaricamento rapido di un database sospeso:

Uso di " -T " L'opzione con mysqldump genera molti file .sql e .txt nella directory specificata. Questo è ~ 50% più veloce per il dumping di tabelle di grandi dimensioni rispetto a un singolo file .sql con istruzioni INSERT (richiede 1/3 di tempo in meno di clock).

Inoltre, c'è un enorme vantaggio nel ripristinare se è possibile caricare più tabelle in parallelo e saturare più core. Su una scatola a 8 core, questa potrebbe essere una differenza di 8 volte nel tempo dell'orologio da parete per ripristinare il dump, oltre ai miglioramenti dell'efficienza forniti da "-T". Perché " -T " fa sì che ogni tabella sia memorizzata in un file separato, caricarli in parallelo è più semplice che dividere un enorme file .sql.

Portando le strategie sopra al loro estremo logico, si potrebbe creare uno script per scaricare un database ampiamente in parallelo. Bene, questo è esattamente ciò che Maakit mk-parallel-dump (vedi http: // www .maatkit.org / doc / mk-parallel-dump.html ) e mk-parallel-restore sono strumenti; script perl che effettuano più chiamate al programma mysqldump sottostante. Tuttavia, quando ho provato a usarli, ho avuto difficoltà a completare il ripristino senza errori chiave duplicati che non si sono verificati con i dump della vaniglia, quindi tieni presente che il tuo chilometraggio può variare.

Dump dei dati da un database LIVE (senza interruzione del servizio):

Il parametro --single-transazione è molto utile per eseguire il dump di un database live senza doverlo sospendere o per eseguire il dump di un database slave senza interrompere lo slave.

Purtroppo, -T non è compatibile con --single-transazione, quindi ne ottieni solo una.

Di solito, prendere la discarica è molto più veloce che ripristinarla. C'è ancora spazio per uno strumento che prende il file di dump monolitico in arrivo e lo divide in più pezzi per essere caricato in parallelo. Per quanto ne so, un tale strumento non esiste ancora.

---

Il trasferimento del dump sulla rete è in genere una vittoria

Per ascoltare un dump in arrivo su una corsa host:

nc -l 7878 > mysql-dump.sql

Quindi sul tuo host DB, esegui

mysqldump $OPTS | nc myhost.mydomain.com 7878

Questo riduce la contesa per i mandrini del disco sul master di scrivere il dump su disco accelerando leggermente il dump (supponendo che la rete sia abbastanza veloce da tenere il passo, un presupposto abbastanza sicuro per due host nello stesso datacenter). Inoltre, se stai costruendo un nuovo slave, questo evita il passaggio di dover trasferire il file di dump al termine.

Avvertenze: ovviamente, è necessario disporre di una larghezza di banda di rete sufficiente per non rallentare in modo insopportabile e, se la sessione TCP si interrompe, è necessario ricominciare tutto da capo, ma per la maggior parte dei dump questo non è un grosso problema.

---

Infine, voglio chiarire un punto di confusione comune.

Nonostante la frequenza con cui vedi questi flag negli esempi e nei tutorial di mysqldump, sono superflui perché attivati ??per impostazione predefinita:

• - opz
• - add-drop-table
• - add-serrature
• - creare-options
• - Disable-chiavi
• - extended-insert
• - lock-tavoli
• - rapido
• - set-charset .

Da http://dev.mysql.com/doc/refman /5.1/en/mysqldump.html :

  

L'uso di --opt è lo stesso di specificare --add-drop-table, --add-locks, --create-options, --disable-keys, --extended-insert, --lock-tables , --quick e --set-charset. Tutte le opzioni che --opt rappresenta anche sono attive di default perché --opt è attiva di default.

Di questi comportamenti, " - veloce " è uno dei più importanti (salta la memorizzazione nella cache dell'intero set di risultati in mysqld prima di trasmettere la prima riga) e può essere con " mysql " (che NON attiva --quick per impostazione predefinita) per velocizzare notevolmente le query che restituiscono un set di risultati di grandi dimensioni (ad esempio, il dumping di tutte le righe di una tabella grande).

Answer 3

Penso che sarà molto più veloce e ti farà risparmiare spazio su disco se provassi replica del database invece di usare mysqldump. personalmente uso sqlyog enterprise per il mio sollevamento davvero pesante ma c'è anche un numero di altri strumenti che possono fornire gli stessi servizi. a meno che ovviamente non desideri utilizzare solo mysqldump.

Answer 4

Per innodb, --order-by-primary --extended-insert è di solito la combinazione migliore. Se dopo ogni ultimo bit di prestazioni e la casella di destinazione ha molti core della CPU, potresti voler dividere il dumpfile risultante e fare inserimenti paralleli in molti thread, fino a innodb_thread_concurrency / 2.

Inoltre, modifica innodb_buffer_pool_size sulla destinazione al massimo che puoi permetterti e aumenta innodb_log_file_size a 128 o 256 MB (attenzione a questo, devi rimuovere i vecchi file di registro prima di riavviare il demone mysql altrimenti non si riavvierà)

Answer 5

Usa lo strumento mk-parallel-dump di Maatkit.

Almeno sarebbe probabilmente più veloce. Mi fiderei di più di mysqldump.

Quanto spesso lo fai? È davvero un problema di prestazioni dell'applicazione? Forse dovresti progettare un modo per farlo che non debba scaricare tutti i dati (replica?)

D'altra parte, 1.5G è un database piuttosto piccolo, quindi probabilmente non sarà un grosso problema.