elhacker.net cabecera Bienvenido(a), Visitante. Por favor Ingresar o Registrarse
¿Perdiste tu email de activación?.

 

 


Tema destacado: ¿Eres nuevo? ¿Tienes dudas acerca del funcionamiento de la comunidad? Lee las Reglas Generales


+  Foro de elhacker.net
|-+  Programación
| |-+  Desarrollo Web
| | |-+  Bases de Datos (Moderador: Carloswaldo)
| | | |-+  Repair de tabla myisam de 130GB
0 Usuarios y 1 Visitante están viendo este tema.
Páginas: [1] 2 3 4 5 Ir Abajo Respuesta Imprimir
Autor Tema: Repair de tabla myisam de 130GB  (Leído 15,732 veces)
moikano→@


Desconectado Desconectado

Mensajes: 572


Cultiva tu mente y cuerpo, son tu única propiedad


Ver Perfil WWW
Repair de tabla myisam de 130GB
« en: 15 Enero 2015, 11:08 am »

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

el-brujo
ehn
***
Desconectado Desconectado

Mensajes: 20.344


La libertad no se suplica, se conquista


Ver Perfil WWW
Re: Repair de tabla myisam de 130GB
« Respuesta #1 en: 15 Enero 2015, 16:47 pm »

Teniendo una tabla tan grande deberías usar el motor InnoDB.

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

En el fichero my.cnf te recomiendo añadir:

Código:
# Auto-creates a backup when running the recover operation.
# http://dev.mysql.com/doc/refman/5.1/en/server-options.html#option_mysqld_myisam-recover
# myisam-recover           = BACKUP
myisam-recover-options = BACKUP,FORCE

Reinicia el servidor mysql y se debería reparar la tabla dañada automáticamente.


Citar
xxx is marked as crashed and should be repaired

http://wiki.elhacker.net/bases-de-datos/mysql/optimizacion

En MySQL 5.1 era la variable:

http://dev.mysql.com/doc/refman/5.1/en/server-options.html#option_mysqld_myisam-recover

myisam-recover  

Y en MySQL 5.5 es:

http://dev.mysql.com/doc/refman/5.5/en/server-options.html#option_mysqld_myisam-recover-options

myisam-recover-options

En teoría con un repair nombre_tabla se debería solucionar, pero...

Puedes usar la herrmaienta mysqlcheck y myisamchk

http://www.databasejournal.com/features/mysql/article.php/3300511/Repairing-Database-Corruption-in-MySQL.htm

http://www.thegeekstuff.com/2008/09/how-to-repair-corrupted-mysql-tables-using-myisamchk/

 myisamchk puede tardar muchas horas en una tabla grande, así que es buena idea añadirle más RAM al proceso:

Código:
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


« Última modificación: 15 Enero 2015, 17:06 pm por el-brujo » En línea

moikano→@


Desconectado Desconectado

Mensajes: 572


Cultiva tu mente y cuerpo, son tu única propiedad


Ver Perfil WWW
Re: Repair de tabla myisam de 130GB
« Respuesta #2 en: 15 Enero 2015, 16:56 pm »

Citar
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.

Citar
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.

Citar
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.

Citar
Código:
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
Moderador Global
***
Desconectado Desconectado

Mensajes: 5.104


I'm fourth.


Ver Perfil WWW
Re: Repair de tabla myisam de 130GB
« Respuesta #3 en: 16 Enero 2015, 04:26 am »

¿Que clase de errores detecto myisamchk con el check o el medium check?
En línea

moikano→@


Desconectado Desconectado

Mensajes: 572


Cultiva tu mente y cuerpo, son tu única propiedad


Ver Perfil WWW
Re: Repair de tabla myisam de 130GB
« Respuesta #4 en: 16 Enero 2015, 10:56 am »

Citar
¿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
Moderador Global
***
Desconectado Desconectado

Mensajes: 5.104


I'm fourth.


Ver Perfil WWW
Re: Repair de tabla myisam de 130GB
« Respuesta #5 en: 16 Enero 2015, 18:27 pm »

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:

Código
  1. REPAIR TABLE tbl_name QUICK

Y si todo falla:

Código
  1. REPAIR TABLE tbl_name USE_FRM

Aunque:

Citar
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 Desconectado

Mensajes: 572


Cultiva tu mente y cuerpo, son tu única propiedad


Ver Perfil WWW
Re: Repair de tabla myisam de 130GB
« Respuesta #6 en: 16 Enero 2015, 23:42 pm »

Citar
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
Moderador Global
***
Desconectado Desconectado

Mensajes: 5.104


I'm fourth.


Ver Perfil WWW
Re: Repair de tabla myisam de 130GB
« Respuesta #7 en: 16 Enero 2015, 23:57 pm »

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:

Citar
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 Desconectado

Mensajes: 572


Cultiva tu mente y cuerpo, son tu única propiedad


Ver Perfil WWW
Re: Repair de tabla myisam de 130GB
« Respuesta #8 en: 17 Enero 2015, 00:01 am »

Citar
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  ;D

-----

Lo he probado. Me suelta el siguiente error.

Citar
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.

Citar
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
Moderador Global
***
Desconectado Desconectado

Mensajes: 5.104


I'm fourth.


Ver Perfil WWW
Re: Repair de tabla myisam de 130GB
« Respuesta #9 en: 17 Enero 2015, 16:26 pm »

No lo sabia, tendré que leer mas sobre los tipos de tablas. Voy a probarlo a ver que me dice. Gracias  ;D

-----

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:

Citar
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

Páginas: [1] 2 3 4 5 Ir Arriba Respuesta Imprimir 

Ir a:  

Mensajes similares
Asunto Iniciado por Respuestas Vistas Último mensaje
Comprimir tabla MySQL (MyISAM)
Bases de Datos
Skeletron 8 8,382 Último mensaje 30 Marzo 2010, 16:39 pm
por ^Tifa^
Ayuda con Repair 0.6
Ingeniería Inversa
Sabakukyu 7 5,094 Último mensaje 20 Enero 2011, 23:00 pm
por jackgris
myisam control referencial?
Bases de Datos
Kase 2 2,912 Último mensaje 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 1,798 Último mensaje 13 Febrero 2012, 18:32 pm
por wolfbcn
Se puede bloquear una tabla globalmente en MyISAM?
Bases de Datos
Skeletron 2 1,654 Último mensaje 28 Noviembre 2013, 02:10 am
por Skeletron
WAP2 - Aviso Legal - Powered by SMF 1.1.21 | SMF © 2006-2008, Simple Machines