 Autor
|
Tema: Repair de tabla myisam de 130GB (Leído 23,727 veces)
|
moikano→@
 Desconectado
Mensajes: 572
Cultiva tu mente y cuerpo, son tu única propiedad
|
Tenemos un problema importante. Nos ha crasheado una tabla de 130GB de fichero MYD y de 30GB de fichero MYI .
Vamos perdidos porque llevamos 5 dias de recoverys fallidos, ya que todos los parámetros del comando myisamchk que usamos parecen no dar en el clavo. Es decir, he intentado hacerlo rápido, asignandole mas RAM al proceso de myisamchk, también asignandole menos RAM y haciendo el proceso mas lento, ninguna de las dos formas funcionó.
También desde una copia de seguridad que teniamos, 8 horas antes de que petara la tabla, lleva 2 dias pasándose, estancada en la query ALTER TABLE tabla ENABLE KEYS.
Tenemos un proceso de myisamchk con la opción -o que es la opción que mas tarda, de hecho lleva 3 dias.
Y todo ello lo tenemos replicado en otros 2 servidores mas potentes por si en el servidor original petaran los recoverys o procesos de insertado del backup.
Es un problema porque no podemos tardar mucho ya que hay clientes esperando los datos.
La solución obvia era particionar la tabla o pasarlo a mongodb directamente, pero los de arriba no le dieron tiempo al programador para pasarlo y al final petó la tabla.
Mi pregunta es, ha alguien le ha pasado lo mismo con una tabla de un tamaño similar? de 100 o mas gigas.
Y las otras dudas serían, que has hecho? Esperar? Una solución alternativa?
Gracias por la atención.
|
|
|
|
|
En línea
|
|
|
|
|
|
moikano→@
Desconectado
Mensajes: 572
Cultiva tu mente y cuerpo, son tu única propiedad
|
Teniendo una tabla tan grande deberías usar el motor InnoDB. Nadie tenia en cuenta que pesara tanto, si no se habría hecho un particionado de tabla por meses, que suele ser lo mas lógico para estos casos si se necesita myisam. De todas formas, por experiencia propia, cuando sabes que va a crecer tanto una tabla directamente la hacemos en mongodb. En el foro usamos MyISAM porque el ratio de lecturas sigue siendo muy elevado, un 90€ de las consultas son selects. Y la tabla no es tan grande, la de mensajes ocupa 1,2GB myd A nosotros nos pasa mas o menos lo mismo. Los selects se hacen bastante y se vuelven muy pesados. Reinicia el servidor mysql y se debería reparar la tabla dañada automáticamente. Ese recovery no funciona, he hecho recovery con mysqlcheck, que es el automático, creo, con todos sus variantes de parámetros y el myisamchk también. El único que nos queda, que aún está en ello, es el que lleva la opción -o que es el old, el recovery mas viejo, que mas tarda pero que también arregla lo que los otros no arreglan. Hace un rato he podido hacer un cálculo y me ha salido que tardará 7 dias en recuperar solo el fichero MYD, el de indices ni idea. myisamchk --silent --force --fast --update-state \
--key_buffer_size=512M --sort_buffer_size=512M \
--read_buffer_size=4M --write_buffer_size=4M \
/var/lib/mysql/bugs/*.MYI Ese también lo hemos hecho pero no funciona. La opción fast peta. Gracias por el interés.
|
|
|
|
|
En línea
|
|
|
|
|
MinusFour
|
¿Que clase de errores detecto myisamchk con el check o el medium check?
|
|
|
|
|
En línea
|
|
|
|
moikano→@
Desconectado
Mensajes: 572
Cultiva tu mente y cuerpo, son tu única propiedad
|
¿Que clase de errores detecto myisamchk con el check o el medium check? Siempre sobre los indices. Los mensajes no los recuerdo. Pero los busqué por google y siempre decian lo mismo, myisamchk.
|
|
|
|
|
En línea
|
|
|
|
|
MinusFour
|
Siempre sobre los indices.
Los mensajes no los recuerdo. Pero los busqué por google y siempre decian lo mismo, myisamchk.
Prueba a usar la opcion --quick.de myisamchk o lo puedes hacer desde una query: REPAIR TABLE tbl_name QUICK
Y si todo falla: REPAIR TABLE tbl_name USE_FRM
Aunque: The USE_FRM option is available for use if the .MYI index file is missing or if its header is corrupted. This option tells MySQL not to trust the information in the .MYI file header and to re-create it using information from the .frm file. This kind of repair cannot be done with myisamchk.
Note
Use the USE_FRM option only if you cannot use regular REPAIR modes! Telling the server to ignore the .MYI file makes important table metadata stored in the .MYI unavailable to the repair process, which can have deleterious consequences:
The current AUTO_INCREMENT value is lost.
The link to deleted records in the table is lost, which means that free space for deleted records will remain unoccupied thereafter.
The .MYI header indicates whether the table is compressed. If the server ignores this information, it cannot tell that a table is compressed and repair can cause change or loss of table contents. This means that USE_FRM should not be used with compressed tables. That should not be necessary, anyway: Compressed tables are read only, so they should not become corrupt. http://dev.mysql.com/doc/refman/5.1/en/repair-table.html
|
|
|
|
« Última modificación: 16 Enero 2015, 18:30 pm por MinusFour »
|
En línea
|
|
|
|
moikano→@
Desconectado
Mensajes: 572
Cultiva tu mente y cuerpo, son tu única propiedad
|
The link to deleted records in the table is lost, which means that free space for deleted records will remain unoccupied thereafter. Esto me paso en dos recuperaciones. Fui a borrar una row duplicada una vez recuperada y me petó la tabla. Tiene que ver o me estoy liando? De todas formas probaré la opción USE_FRM. Gracias por la respuesta.
|
|
|
|
« Última modificación: 16 Enero 2015, 23:56 pm por moikano→@ »
|
En línea
|
|
|
|
|
MinusFour
|
Esto me paso en dos recuperaciones. Fui a borrar una row duplicada una vez recuperada y me petó la tabla. Tiene que ver o me estoy liando?
De todas formas probaré la opción USE_FRM, la QUICK la use pero con el comando "mysqlcheck", es lo mismo no?
Me pareece que sí, solo trata de arreglar el archivo de indices y no la de data. En cuanto a lo de los registros borrados pasa esto con MyISAM: In MyISAM tables, deleted rows are maintained in a linked list and subsequent INSERT operations reuse old row positions. Lo que significa que una vez utilizado el comando con USE_FRM las hileras que habias borrado con DELETE se borran complemtante y no se reutilizan más.
|
|
|
|
|
En línea
|
|
|
|
moikano→@
Desconectado
Mensajes: 572
Cultiva tu mente y cuerpo, son tu única propiedad
|
Lo que significa que una vez utilizado el comando con USE_FRM las hileras que habias borrado con DELETE se borran complemtante y no se reutilizan más. No lo sabia, tendré que leer mas sobre los tipos de tablas. Voy a probarlo a ver que me dice. Gracias  ----- Lo he probado. Me suelta el siguiente error. error : Key in wrong position at page 4096
error : Corrupt Te sugiere algo?
He probado también el QUICK con myisamchk y me a sacado el siguiente mensaje. myisamchk: error: Keypointers and record positions doesn't match
MyISAM-table 'Table.MYI' is corrupted
Fix it using switch "-r" or "-o" Mod: No hacer doble post
|
|
|
|
« Última modificación: 18 Enero 2015, 09:09 am por #!drvy »
|
En línea
|
|
|
|
|
MinusFour
|
No lo sabia, tendré que leer mas sobre los tipos de tablas. Voy a probarlo a ver que me dice. Gracias ----- Lo he probado. Me suelta el siguiente error. Te sugiere algo? Pues yo creo que lo único que te puede salvar es USE_FRM o quizas el safe-recover. Tu archivo de indices parece corrupto. ¿Ambos errores son con el Quick verdad? ¿O usas USE_FRM y luego hiciste un CHECK TABLE? No deberia usar el archivo de indices USE_FRM: The USE_FRM option is available for use if the .MYI index file is missing or if its header is corrupted. This option tells MySQL not to trust the information in the .MYI file header and to re-create it using information from the .frm file. Tambien podrias probar con el --sort-recove pero no estoy seguro si --recover lo haya intentado.
|
|
|
|
|
En línea
|
|
|
|
|
| Mensajes similares |
|
Asunto |
Iniciado por |
Respuestas |
Vistas |
Último mensaje |
|
|
Comprimir tabla MySQL (MyISAM)
Bases de Datos
|
Skeletron
|
8
|
9,635
|
30 Marzo 2010, 16:39 pm
por ^Tifa^
|
|
|
|
Ayuda con Repair 0.6
Ingeniería Inversa
|
Sabakukyu
|
7
|
6,499
|
20 Enero 2011, 23:00 pm
por jackgris
|
|
|
|
myisam control referencial?
Bases de Datos
|
Kase
|
2
|
3,717
|
17 Mayo 2011, 16:49 pm
por [u]nsigned
|
|
|
|
Windows Repair 1.6.4: Reparar Windows con un click es posible con Windows Repair
Noticias
|
wolfbcn
|
0
|
2,573
|
13 Febrero 2012, 18:32 pm
por wolfbcn
|
|
|
|
Se puede bloquear una tabla globalmente en MyISAM?
Bases de Datos
|
Skeletron
|
2
|
3,128
|
28 Noviembre 2013, 02:10 am
por Skeletron
|
 |
