Repair de tabla myisam de 130GB

[moikano→@]

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.

[el-brujo]

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 [Seleccionar] Expandir

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

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 [Seleccionar] Expandir

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

[moikano→@]

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.

Código [Seleccionar] Expandir

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.

[MinusFour]

¿Que clase de errores detecto myisamchk con el check o el medium check?

[moikano→@]

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

[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:

Código (SQL) [Seleccionar] Expandir


REPAIR TABLE tbl_name QUICK

Y si todo falla:

Código (sql) [Seleccionar] Expandir


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

[moikano→@]

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.

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

[moikano→@]

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

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