Scaricare VELOCEMENTE un database sospeso:
Utilizzando l'opzione "-T" con mysqldump si ottengono molti file .sql e .txt nella directory specificata. Questo è circa il 50% più veloce per il dump di tabelle di grandi dimensioni rispetto a un singolo file .sql con istruzioni INSERT (richiede 1/3 di tempo in meno).
Inoltre, c'è un enorme vantaggio durante il ripristino se puoi caricare più tabelle in parallelo e saturare più core. Su una scatola a 8 core, questa potrebbe essere una differenza di 8 volte l'ora dell'orologio da parete per ripristinare il dump, oltre ai miglioramenti di efficienza forniti da "-T". Poiché "-T" fa sì che ogni tabella venga archiviata in un file separato, caricarle in parallelo è più facile che dividere un enorme file .sql.
Portando le strategie di cui sopra al loro estremo logico, si potrebbe creare uno script per eseguire il dump di un database ampiamente in parallelo. Bene, questo è esattamente ciò che il Maakit mk-parallel-dump (vedi http:/ /www.maatkit.org/doc/mk-parallel-dump.html ) e gli strumenti mk-parallel-restore sono; perl script che effettuano più chiamate al programma mysqldump sottostante. Tuttavia, quando ho provato a utilizzarli, ho avuto problemi a completare il ripristino senza errori di chiave duplicati che non si verificavano con i dump vanilla, quindi tieni presente che il tuo chilometraggio potrebbe variare.
Dumping di dati da un database LIVE (senza interruzione del servizio):
L'opzione --single-transaction è molto utile per eseguire un dump di un database live senza doverlo sospendere o eseguire un dump di un database slave senza dover interrompere lo slaving.
Purtroppo, -T non è compatibile con --single-transaction, quindi ne ottieni solo uno.
Di solito, prendere il dump è molto più veloce che ripristinarlo. C'è ancora spazio per uno strumento che prende il file di dump monolitico in arrivo e lo suddivide in più parti da caricare in parallelo. Per quanto ne so, uno strumento del genere non esiste ancora.
Il trasferimento del dump sulla rete è solitamente una vittoria
Per ascoltare un dump in arrivo su un host eseguito:
nc -l 7878 > mysql-dump.sql
Quindi sul tuo host DB, esegui
mysqldump $OPTS | nc myhost.mydomain.com 7878
Ciò riduce la contesa per i perni del disco sul master dalla scrittura del 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 creando un nuovo slave, questo evita il passaggio di dover trasferire il file dump al termine.
Avvertenze:ovviamente, è necessario disporre di una larghezza di banda di rete sufficiente per non rallentare le cose in modo insopportabile e, se la sessione TCP si interrompe, è necessario ricominciare 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é sono attivati per impostazione predefinita:
--opt--add-drop-table--add-locks--create-options--disable-keys--extended-insert--lock-tables--quick--set-charset.
Da http://dev.mysql.com/doc/refman/ 5.1/en/mysqldump.html :
Di questi comportamenti, "--quick" è 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, eseguire il dump di tutte le righe di una grande tabella).
