Cómo evitar la reparación con Keycache?

Question

He tenido cierta experiencia con la optimización del archivo my.cnf pero mi base de datos tiene alrededor de 4 millones de registros (MyISAM). Estoy tratando de restaurar desde un mysqldump, pero cada vez que lo hago, eventualmente recibo el temido "Repair With Keycache", que puede tomar días. ¿Hay alguna forma de superar esto y dejarlo pasar como "Reparar ordenando"?

Tengo 2GB de RAM, Núcleos duales, una gran cantidad de espacio adicional en el disco duro.

Recorte de 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

"reparación por la clasificación" utiliza la rutina filesort, que a su vez crea varios archivos temporales (por lo general) en su tmpdir.

Si su tmpdir no tiene suficiente espacio para ellos, volverá a "Reparar mediante el teclado". Esto es extremadamente malo ya que es mucho más lento Y crea índices menos óptimos.

Existen otras condiciones, pero no las he identificado.

Calcular el tamaño de tmpdir que necesita para filesort() no es trivial; Los datos de formato que se almacenan en el buffer del filesort no son los mismos que los archivos MYD, por lo general usan mucho más espacio.

Así que si su tmpdir apunta a un pequeño/tmp (o tmpfs), es posible que desee cambiarlo a un/var/tmp mayor, si es que existe.

Answer 2

Gracias Marcar, Sí, eso es exactamente lo que terminé intentando y estoy viendo en los registros que esa es la razón por la que cambió a "Reparar con llave de caché", fue un error de falta de espacio.

Esto es lo que hice para obtener mi solución en su lugar, ya que no voy a pasar por el hecho de que estaba apuntando a /tmp/mysqltmp/, que solo tenía un máximo de 2MB.

Así lo hice:

mkdir /home/mysqltmp 

chown mysql:mysql /home/mysqltmp 

cambió mi dir tmp en my.conf atmpdir=/home/mysqltmp/

Ahora si uso df -h /home/mysqltmp, lo que veo es que dir tiene 285 GB disponibles , así que realmente fue un espectáculo agradable de ver, tenía mucho espacio libre, además pude ver que mysql quería 20GB fácilmente. Entonces, lo que me llevaba 12 horas antes ahora está completo en 20 minutos, es decir, más de 3 millones de registros insertados en el índice.

Answer 3

MySQL utilizará la reparación por teclado para tablas MyISAM siempre que el tamaño máximo posible de los índices de tablas sea mayor que el valor de la variable myisam_max_sort_file_size.

Puede calcular el tamaño máximo del índice agregando los valores de tamaño de byte para todas las claves en todos los índices y multiplicándolo por el número de filas en su tabla.

Aumente myisam_max_sort_file_size y su índice se reconstruirá utilizando la clasificación en disco, en lugar de hacerlo con el método lento de la memoria caché.

Answer 4

Accidentalmente ejecuté rápidamente una tabla de reparación en una nueva base de datos que no había configurado para registrarla rápidamente. myisam_max_sort_file_size, que era demasiado pequeño en comparación con el archivo .MID (que es 88279393280 byes large, aproximadamente 88 GB). El archivo de datos es 85GB. La tabla contiene 1.200 millones de registros, que constan de una identificación, dos fechas, un texto minúsculo, algunas letras grandes y un doble.Mi servidor (Linux virtual de 2 GB ejecutándose en un recuadro debajo de Windows 7) solo tiene un núcleo de los 4 en el servidor de Windows, pero está ejecutando 3+ GHZ. Temía que este evento de "reparación por llave" llevaría una eternidad, dado historias de terror con tablas mucho más pequeñas.

Afortunadamente "solo" tomó 1 día, 10 horas y 20.72 segundos para completar la operación rápida de la tabla de reparación.

Lo que más echo de menos es una forma de saber cuán lejos está la operación de mysql, y qué tan pronto podría terminar. Esto todavía es desconocido para mí.

Ahora he cambiado mi archivo my.ini y comprobé dos veces con df que tengo un amplio espacio de disco para esos archivos temporales de gran tamaño.

De todos modos ... mi punto principal, que podría ser un conocimiento muy útil para el siguiente tipo que cae en esta trampa ... es de hecho ... ¡no entres en pánico! puede ser lento, pero es posible en un hardware bastante inferior obtener 1 mil millones de registros resueltos dentro de un día o dos. Tiene tres índices, uno en un campo de fecha, uno en un campo de letra grande y uno principal en el campo ID.

Lo habría publicado como comentario de una de las soluciones, pero parece que no sé cómo hacerlo, con la interfaz de usuario aquí, así que lo dejaré como una solución. No me voten, es solo una nota que me hubiera encantado tener aquí, casi iba a matar mi hilo "ordenar por clave" ya que pensé que podría llevar una semana o más. 2 días por mil millones de registros es manejable.

Editar: Y ahora, una tabla de reparación en la misma base de datos, pero con una configuración lo suficientemente grande mysiam_max_sort_file_size tomó 10 horas, 20 minutos usando reparación por clasificación. La mayor parte del espacio de disco utilizado era de aproximadamente 250 GB, pero había establecido myisam_max_sort_file_size mucho más alto, lo que refleja la cantidad de espacio de disco realmente libre en el servidor.

El progreso del seguimiento es difícil. El espacio en disco subió y bajó mientras se creaban los índices individuales, pero hubo pausas de una hora en las que no se realizaron cambios. Reg. uso del espacio de disco (según lo informado por df).

Answer 5

De acuerdo con el Manual de referencia de MySQL, espacio en disco debe estar disponible "en el sistema de archivos que contiene el directorio donde se encuentra el archivo de índice original" (http://dev.mysql.com/doc/refman/5.5/en/server-system-variables.html#sysvar_myisam_max_sort_file_size) - esto se aplica a (al menos) y v5.0 encima. Esto contradice algunas de las respuestas anteriores, que afirman que aumentar el espacio en disco para el directorio tmp ayudaría.

puedo confirmar el comportamiento descrito en el manual de referencia: espacio de disco temporal se utiliza donde se almacenan los datos de la tabla (*.MYD) & archivos de índice (*.MYI), pero no en tmpdir.

Answer 6

Ninguna de las soluciones aquí funcionó para mí: no importa cuánto aumente la variable myisam_sort_buffer_size o donde hice el punto variable tmpdir, la tabla siempre fue reparada con la llave.

Lo que funcionó fue utilizar la utilidad de línea de comandos myisamchk:

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

donde:

• /path/to/table es la ruta del archivo de base de datos sin su extensión (así, sin la .MYI al final) Está ubicado por defecto en el directorio /var/lib/mysql/your_database.

• Cambie el tamaño del búfer de 14G al espacio libre disponible que tenga.

Como una ventaja adicional, también muestra el progreso continuo a medida que se agita la información.