Perché l'importazione di un file .sql da 12 GB richiede più di 36 ore?

Sto aspettando da 36 ore che un file .sql da 12 GB venga importato con un semplice type site.sql | mysqlcomando. Vedo che ibdata1sta crescendo ancora, attualmente quasi 40 GB.

Considerando che i trigger e le stored procedure sono alla fine di .sql, penso solo che MySQL debba aggiungere dati e indici chiave.

Site.sql è stato generato utilizzando questo comando da un altro server:

mysqldump -R -e --databases site --add-drop-database --add-create-database --add-drop-table -C --single-transaction --triggers

Cosa ci vuole così tanto?

mysql mysql-5 mariadb

— servermanfail
fonte

quanta CPU sta prendendo mysql? Se è un valore basso, probabilmente significa che sei legato al disco

— Derek Downey,

i file .sql non sono davvero così veloci da importare ... in realtà è più veloce eseguire il dump in delim tab o CSV, quindi creare il database vuoto e utilizzarlo LOAD DATA INFILE. Inoltre, mentre stai spostando un intero database, vedi la mia risposta in merito: spostare i database tra i server se rimani nella stessa versione principale. (specialmente se devi interrompere e riavviare)

— Joe

Risposte:

Prova questo:

$ ps -ef|grep [m]ysql

Identifica quindi l'id processo

$ strace -cp <pid>

Lascialo 10 secondi o un minuto allora ^C. Questo ti dirà dove il processo sta trascorrendo il suo tempo, ad esempio potrebbe essere solo in attesa del disco se lo vedi reade writedomini.

— Caio
fonte

+1 perché ho appena imparato un nuovo comando (strace): P Modifica: ben schifo, non disponibile sul mio mac per impostazione predefinita.

— Derek Downey,

È uno strumento fantastico, insieme a gdb. Non dico più alle persone che la loro app è stata bloccata; Dico loro esattamente su cosa è bloccato o su cui gira, o da un nucleo dire loro la riga di codice e il nome del file sorgente. Ancora più potente è dtrace.

— Gaius,

Strace è Linux: l'equival di Solaris è una capriata. Dtrace è disponibile su Mac.

— Gaius,

così è. continuerò a leggerlo ora.

— Derek Downey,

Attenzione: bel comando da sapere, ma attenzione, questo comando ha provocato l'arresto anomalo della mia istanza di MySQL. Non so perché. Prima che MySQL si arrestasse in modo anomalo, il server non rispondeva per alcuni minuti.

— dabest1,

Hai delle tabelle InnoDB con una chiave primaria?

contenente più colonne?
avendo un ampio VARCHAR?
e molti indici non unici?
uno o più indici non univoci con una chiave ampia?

Una qualsiasi di queste condizioni può probabilmente causare nodi BTREE di grandi dimensioni nei tuoi indici con pochissime foglie in ciascun nodo BTREE. La chiave del cluster nella chiave primaria è inoltre collegata a ciascuna voce della chiave non univoca nelle chiavi non cluster.

Un'altra considerazione: la somma delle pagine di dati di InnoDB è significativamente inferiore rispetto alle pagine di indice di InnoDB?

Puoi scoprirlo con questa query (in MB):

SELECT SUM(data_length)/POWER(1024,2) InnoDBData,
SUM(index_length)/POWER(1024,2) InnoDBIndexes
FROM information_schema.tables WHERE engine='InnoDB';

Ulteriori considerazioni: la registrazione binaria è abilitata nel server DB che si sta caricando? Se lo sei, ti preghiamo di farlo sul server che stai caricando:

mysql -h... -u... -p... -A -e"SET sql_log_bin=0; source site.sql"

Spero che questo possa essere d'aiuto !!!

— RolandoMySQLDBA
fonte

Sei sicuro che le tabelle in cui stai leggendo siano prive di trigger, indici e vincoli? Su quale hardware e sistema operativo stai eseguendo? Come è configurato il tuo spazio di archiviazione?

Ho più familiarità con Oracle, ma l'importazione 12G su tabelle senza trigger, indici e vincoli dovrebbe facilmente andare con 200 GB / h. Un singolo trigger può trasformare il processo in una lumaca, a seconda di cosa fa quel trigger ...

spero che questo possa essere d'aiuto

— ik_zelf
fonte