Come evitare la riparazione con Keycache?

Question

Ho avuto qualche esperienza con l'ottimizzazione del file my.cnf ma il mio database ha circa 4 milioni di record (MyISAM). Sto cercando di ripristinare da un mysqldump, ma ogni volta che ottengo finalmente il temuto "Repair With Keycache", potrebbero essere necessari giorni. C'è un modo per superare questo e lasciarlo rotolare come "Repair By Sorting"?

Ho 2 GB di RAM, Dual Core, molto spazio extra su disco rigido.

Snip fuori my.cnf:

set-variable = max_connections=650 
set-variable = key_buffer=256M 
set-variable = myisam_sort_buffer_size=64M 
set-variable = join_buffer=1M 
set-variable = record_buffer=1M 
set-variable = sort_buffer_size=2M 
set-variable = read_buffer_size=2M 
set-variable = query_cache_size=32M 
set-variable = table_cache=1024 
set-variable = thread_cache_size=256 
set-variable = wait_timeout=7200 
set-variable = connect_timeout=10 
set-variable = max_allowed_packet=16M 
set-variable = max_connect_errors=10 
set-variable = thread_concurrency=8 

Answer 1

"Riparazione di classificare" utilizza la routine FileSort, che a sua volta crea diversi file temporanei (di solito) nella vostra tmpdir.

Se il tuo tmpdir non ha spazio sufficiente per loro, verrà ripristinato "Ripara dal keycache". Questo è estremamente negativo in quanto è molto più lento e crea indici meno ottimali.

Ci sono altre condizioni ma non le ho identificate.

L'elaborazione della dimensione di tmpdir necessaria per filesort() è non banale; i dati di formato sono memorizzati nel buffer filesort non è lo stesso dei file MYD, in genere utilizza molto più spazio.

Quindi se il tuo tmpdir punta a un piccolo/tmp (o tmpfs), potresti volerlo cambiare in un/var/tmp più grande - se esiste.

Answer 2

Grazie Mark, Sì, è esattamente quello che ho provato a provare e sto vedendo dai registri che quello è il motivo per cui è passato a "Ripara con keycache", era un errore di spazio insufficiente.

Questo è quello che ho fatto per ottenere la mia soluzione sul posto in quanto non passerò attraverso il fatto che stava puntando a /tmp/mysqltmp/, che aveva solo un massimo di 2 MB.

Quindi ho fatto questo:

mkdir /home/mysqltmp 

chown mysql:mysql /home/mysqltmp 

cambiato la mia tmp dir in my.conf pertmpdir=/home/mysqltmp/

Ora, se io uso df -h /home/mysqltmp, quello che vedo è che dir ha 285 GB , quindi è stato davvero bello vedere, aveva molto spazio libero, inoltre ho potuto vedere che mysql voleva 20GB facilmente. Quindi quello che mi ci è voluto 12 ore prima è ora completato in 20 minuti, cioè oltre 3 milioni di record inseriti per indicizzare.

Answer 3

MySQL utilizzerà la riparazione da keycache per le tabelle MyISAM ogni volta che la dimensione massima possibile degli indici delle tabelle è maggiore del valore per la variabile myisam_max_sort_file_size.

È possibile calcolare la dimensione massima dell'indice sommando i valori della dimensione in byte per tutte le chiavi in ​​tutti gli indici e moltiplicando quello per il numero di righe nella tabella.

Aumentare il myisam_max_sort_file_size e l'indice verrà ricostruito utilizzando l'ordinamento su disco, anziché con il metodo del keycache lento.

Answer 4

Ho accidentalmente eseguito una tabella di riparazione rapidamente su un nuovo database che non avevo impostato per essere veloce reg. myisam_max_sort_file_size che era troppo piccolo rispetto al file .MID (che è 88279393280 grande, circa 88 GB). Il file di dati è 85 GB. La tabella è di 1,2 miliardi di record, composta da un ID, due date, un tinytext, alcuni bigints e un double.Il mio server (2GB di Linux virtuale in esecuzione in una casella sotto windows7) ha solo un core dei 4 sul server Windows, ma è in esecuzione 3+ GHZ. Temevo che questo evento "riparazione da keycache" sarebbe durato per sempre - date storie dell'orrore con tavoli molto più piccoli.

Fortunatamente "solo" sono stati necessari 1 giorno, 10 ore e 20,72 secondi per completare l'operazione rapida della tabella di riparazione.

Quello che mi manca di più è un modo per sapere fino a che punto l'operazione è mysql e quanto presto potrebbe essere finita. Questo è ancora sconosciuto per me.

Ora ho cambiato il mio file my.ini e ho ricontrollato con df che ho un ampio spazio su disco per quei file temporanei di grandi dimensioni.

In ogni caso .. il mio punto principale, che potrebbe essere una conoscenza molto utile per il prossimo ragazzo che cade in questa trappola .. è in effetti ... non fatevi prendere dal panico! potrebbe essere lento, ma è possibile su hardware piuttosto sub-par per ottenere 1+ miliardi di record risolti entro un giorno o due. Ottenuto tre indici, uno su un campo data, uno su un campo bigint e uno primario sul campo ID.

Avrei postato questo come commento a una delle soluzioni, ma non riesco a capire come farlo, con l'interfaccia utente qui, quindi lo lascerò cadere come soluzione. Non mi invitare, è solo una nota che avrei voluto avere qui, stavo quasi per uccidere il mio thread "ordina per keycache" come pensavo potesse richiedere una settimana o più. 2 giorni per miliardo di record è gestibile ..

Modifica: E ora, una tabella di riparazione sullo stesso database, ma con un'impostazione mysiam_max_sort_file_size abbastanza grande ha impiegato 10 ore e 20 minuti utilizzando la riparazione ordinando. La maggior parte dello spazio su disco utilizzato era di circa 250 GB, ma avevo impostato myisam_max_sort_file_size molto più in alto, riflettendo la quantità di spazio su disco effettivamente disponibile sul server.

Il monitoraggio è difficile. Lo spazio su disco è andato su e giù mentre i singoli indici sono stati costruiti, ma ci sono state pause di un'ora in cui non sono state apportate modifiche. utilizzo dello spazio su disco (come riportato da df).

Answer 5

Secondo il manuale di riferimento MySQL, spazio su disco deve essere disponibile "nel file system che contiene la directory in cui si trova il file indice originale" (http://dev.mysql.com/doc/refman/5.5/en/server-system-variables.html#sysvar_myisam_max_sort_file_size) - questo vale per (almeno) v5.0 e sopra. Ciò contraddice alcune delle risposte di cui sopra, che sostengono che sarebbe utile aumentare lo spazio su disco per la directory tmp.

posso confermare il comportamento descritto nel Manuale di riferimento: spazio su disco temporaneo viene utilizzato in cui sono memorizzati i dati della tabella (*.MYD) & file di indice (*.MYI), ma non in tmpdir.

Answer 6

Nessuna delle soluzioni ha funzionato per me: non importa quanto ho aumentato la variabile myisam_sort_buffer_size o dove ho fatto il punto variabile tmpdir, la tabella è sempre stata riparata con keycache.

Quello che ha funzionato è stato quello di utilizzare l'utilità di comando myisamchk:

myisamchk --sort-recover --sort_buffer_size=14G /path/to/table 

dove:

• /path/to/table è il percorso del file di database, senza la sua estensione (così, senza il .MYI alla fine). Si trova di default nella directory /var/lib/mysql/your_database.

• Modificare la dimensione del buffer da 14G a qualsiasi spazio disponibile disponibile.

Come bonus aggiuntivo, mostra anche il progresso in corso mentre sforna i dati.