parallel - how to repair a table in mysql
MySQL, Error 126: archivo de clave incorrecto para la tabla (5)
Leí la siguiente pregunta que tiene relevancia, pero las respuestas no me satisficieron: MySQL: # 126 - Archivo de clave incorrecto para la tabla
El problema
Al ejecutar una consulta me sale este error
ERROR 126 (HY000): Archivo de clave incorrecto para la tabla
La pregunta
Cuando trato de encontrar el problema, no puedo encontrar uno, así que no sé cómo solucionarlo con el comando de reparación. ¿Hay alguna indicación de cómo puedo encontrar el problema que causa este problema de alguna otra manera que ya lo he intentado?
La consulta
mysql> SELECT
-> Process.processId,
-> Domain.id AS domainId,
-> Domain.host,
-> Process.started,
-> COUNT(DISTINCT Joppli.id) AS countedObjects,
-> COUNT(DISTINCT Page.id) AS countedPages,
-> COUNT(DISTINCT Rule.id) AS countedRules
-> FROM Domain
-> JOIN CustomScrapingRule
-> AS Rule
-> ON Rule.Domain_id = Domain.id
-> LEFT JOIN StructuredData_Joppli
-> AS Joppli
-> ON Joppli.CustomScrapingRule_id = Rule.id
-> LEFT JOIN Domain_Page
-> AS Page
-> ON Page.Domain_id = Domain.id
-> LEFT JOIN Domain_Process
-> AS Process
-> ON Process.Domain_id = Domain.id
-> WHERE Rule.CustomScrapingRule_id IS NULL
-> GROUP BY Domain.id
-> ORDER BY Domain.host;
ERROR 126 (HY000): Incorrect key file for table ''/tmp/#sql_2b5_4.MYI''; try to repair it
mysqlcheck
root@scraper:~# mysqlcheck -p scraper
Enter password:
scraper.CustomScrapingRule OK
scraper.Domain OK
scraper.Domain_Page OK
scraper.Domain_Page_Rank OK
scraper.Domain_Process OK
scraper.Log OK
scraper.StructuredData_Joppli OK
scraper.StructuredData_Joppli_Product OK
filas contadas
mysql> select count(*) from CustomScrapingRule;
+----------+
| count(*) |
+----------+
| 26 |
+----------+
1 row in set (0.04 sec)
mysql> select count(*) from Domain;
+----------+
| count(*) |
+----------+
| 2 |
+----------+
1 row in set (0.01 sec)
mysql> select count(*) from Domain_Page;
+----------+
| count(*) |
+----------+
| 134288 |
+----------+
1 row in set (0.17 sec)
mysql> select count(*) from Domain_Page_Rank;
+----------+
| count(*) |
+----------+
| 4671111 |
+----------+
1 row in set (11.69 sec)
mysql> select count(*) from Domain_Process;
+----------+
| count(*) |
+----------+
| 2 |
+----------+
1 row in set (0.02 sec)
mysql> select count(*) from Log;
+----------+
| count(*) |
+----------+
| 41 |
+----------+
1 row in set (0.00 sec)
mysql> select count(*) from StructuredData_Joppli;
+----------+
| count(*) |
+----------+
| 11433 |
+----------+
1 row in set (0.16 sec)
mysql> select count(*) from StructuredData_Joppli_Product;
+----------+
| count(*) |
+----------+
| 130784 |
+----------+
1 row in set (0.20 sec)
Actualizar
Uso del disco
root@scraper:/tmp# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/xvda1 20G 4.7G 15G 26% /
none 4.0K 0 4.0K 0% /sys/fs/cgroup
udev 237M 4.0K 237M 1% /dev
tmpfs 49M 188K 49M 1% /run
none 5.0M 0 5.0M 0% /run/lock
none 245M 0 245M 0% /run/shm
none 100M 0 100M 0% /run/user
Dividir una consulta compleja en varias puede ser más rápido sin necesidad de aumentar el tamaño de la tabla temporal
En mi caso, simplemente borré los archivos temporales de la ubicación temporal:
mi.ini
tmpdir = "D: / xampp / tmp"
Y funcionó para mí.
Parece que su consulta está devolviendo un gran conjunto de resultados intermedios que requieren la creación de una tabla temporal y que la ubicación configurada para las tablas de disco temporal mysql (/ tmp) no es lo suficientemente grande para la tabla temporal resultante.
Puedes intentar aumentar el tamaño de la partición tmpfs remontándola:
mount -t tmpfs -o remount,size=1G tmpfs /tmp
Puede hacer que este cambio sea permanente editando / etc / fstab
Si no puede hacer esto, puede intentar cambiar la ubicación de las tablas temporales del disco editando la entrada "tmpdir" en su archivo my.cnf (o agregarla si aún no está allí). Recuerde que el directorio que elija debe ser escribible por el usuario mysql
También puede intentar evitar la creación de una tabla temporal en disco aumentando los valores de las opciones de configuración de mysql:
tmp_table_size
max_heap_table_size
a valores mayores. Tendrá que aumentar los dos parámetros anteriores
Ejemplo:
set global tmp_table_size = 1G;
set global max_heap_table_size = 1G;
Si su montaje /tmp en un sistema de archivos linux se monta como un desbordamiento, a menudo tiene un tamaño de 1 MB, es decir,
$ df -h
Filesystem Size Used Avail Use% Mounted on
udev 7.9G 12K 7.9G 1% /dev
tmpfs 1.6G 348K 1.6G 1% /run
/dev/xvda1 493G 6.9G 466G 2% /
none 4.0K 0 4.0K 0% /sys/fs/cgroup
none 5.0M 0 5.0M 0% /run/lock
none 7.9G 0 7.9G 0% /run/shm
none 100M 0 100M 0% /run/user
overflow 1.0M 4.0K 1020K 1% /tmp <------
esto probablemente se deba a que no especificó /tmp como su propia partición y su sistema de archivos raíz se llenó y /tmp se volvió a montar como una alternativa.
Me encontré con este problema después de quedarme sin espacio en un volumen EC2. Una vez que redimensioné el volumen, me encontré con la partición de desbordamiento /tmp llenaba mientras ejecutaba una vista complicada.
sudo umount -l /tmp
Nota: -Lo desmontará perezosamente el disco.
Solo necesitas reparar tu tabla que usas en la consulta de búsqueda. este problema generalmente ocurre en la consulta de búsqueda.
vaya a " table_name " -> operación -> efecto de reparación (solo un clic) puede tardar un poco en aplicarse