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.
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:
# 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,FORCEReinicia el servidor mysql y se debería reparar la tabla dañada automáticamente.
Citarxxx 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
myisamchkhttp://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:
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
CitarTeniendo 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.
CitarEn 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.
CitarReinicia 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 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.
¿Que clase de errores detecto myisamchk con el check o el medium check?
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.
Cita de: moikano→@ en 16 Enero 2015, 10:56 AM
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 QUICKY si todo falla:
REPAIR TABLE tbl_name USE_FRMAunque:
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
CitarThe 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.
Cita de: moikano→@ en 16 Enero 2015, 23:42 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.
CitarLo 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
Cita de: moikano→@ en 17 Enero 2015, 00:01 AM
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:
CitarThe 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.
Cita de: MinusFour en 17 Enero 2015, 16:26 PM
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:
Tambien podrias probar con el --sort-recove pero no estoy seguro si --recover lo haya intentado.
Pues he probado los dos, y hace un rato le he tirado un recover, cuando acabe comento.
¿Pero espera, ya has probado con USE_FRM? ¿Y no funciono?
Cita de: MinusFour en 17 Enero 2015, 22:42 PM
¿Pero espera, ya has probado con USE_FRM? ¿Y no funciono?
Nop, me dijo esto.
Citarerror : Key in wrong position at page 4096
error : Corrupt
He probado varias opciones y con mysqlcheck siempre suelta eso.
Cita de: moikano→@ en 18 Enero 2015, 09:07 AM
Nop, me dijo esto.
He probado varias opciones y con mysqlcheck siempre suelta eso.
¿Es raro que salga ese preciso error, si tienes el .frm ahi verdad? Prueba a mover el .myi fuera de ahí y luego:
mysqlcheck -u tuusuario -p password --repair --use-frm basededatos tabla
Al final hemos restaurado un backup. Pero aún así a tardado 3 dias y con un disco duro SSD por que con uno SATA sigue con ello después de 5 dias.
De todas formas seguiré probando a ver si logro reparar la tabla, solo por saberlo para la próxima.
Citar¿Es raro que salga ese preciso error, si tienes el .frm ahi verdad? Prueba a mover el .myi fuera de ahí y luego:
Oks lo probaré a ver
Citarmysqlcheck -u tuusuario -p password --repair --use-frm basededatos tabla
Parece ser que ese comando ha funcionado bien y solo a tardado 18 horas. Ahora probaré a meterle datos y borrárselos a ver si peta como los otros repairs.
-----
Se están insertando las filas y borrando las duplicadas correctamente, la tabla parece que se ha recuperado con ese comando. Gracias por tu ayuda. ;-)
hola, quizas llego tarde, Se ha podido reparar la tabla de 130GB? tengo el mismo problema una tabla de 90GB que lleva mas de 3 semanas en proceso de reparacion con REPAIR TABLE, todavia no ha dado error!
Alguna sugerencia?
gracias de anetemano.
Cita de: danmaster en 5 Febrero 2015, 14:38 PM
hola, quizas llego tarde, Se ha podido reparar la tabla de 130GB? tengo el mismo problema una tabla de 90GB que lleva mas de 3 semanas en proceso de reparacion con REPAIR TABLE, todavia no ha dado error!
Alguna sugerencia?
gracias de anetemano.
Citarmysqlcheck -u tuusuario -p password --repair --use-frm basededatos tabla
Eso me funcionó bien a mi. Pero todo depende el problema que te haya surgido a ti. Si puedes pasarnos mensajes de error o antecedentes de lo ocurrido a lo mejor podemos hecharte una mano.
Saludos
Hola, gracias por contestar,
basiscamente este es el error:
#144 - Table './basedatos/tabla' is marked as crashed and last (automatic?) repair failed
Como comente llevo esperando 3 semanas, y el proceso continua, no se si detenerlo o esperar mas
Cita de: danmaster en 5 Febrero 2015, 14:55 PM
Hola, gracias por contestar,
basiscamente este es el error:
#144 - Table './basedatos/tabla' is marked as crashed and last (automatic?) repair failed
Como comente llevo esperando 3 semanas, y el proceso continua, no se si detenerlo o esperar mas
Y cual es el comando que usaste y que lleva 3 semanas?
use el Repair Table nombredetabla
Cita de: danmaster en 5 Febrero 2015, 20:37 PM
use el Repair Table nombredetabla
A traves de una consulta SQL cierto? Porque no pruebas por las sugerencias de el-brujo en la primera pagina.
Cita de: danmaster en 5 Febrero 2015, 20:37 PM
use el Repair Table nombredetabla
Lo cierto es que hay bastante información en el hilo. Lo que te recomiendo es que pases los ficheros a otro server en cuanto puedas y pruebes diferentes posibles soluciones a la vez. Sino cada cosa que pruebas y no funciona sumas la siguiente prueba. Ah y otra cosa, si tienes un disco duro ssd o con mas potencia úsalo pasándole una copia.
Suerte.
danmaster, es una tabla MyIsam me imagno ¿?
CitarAl final hemos restaurado un backup. Pero aún así a tardado 3 dias y con un disco duro SSD por que con uno SATA sigue con ello después de 5 dias.
Ya sabes, usa un disco SSD para agilizar el proceso.
Y la próxima vez usa en el my.cnf:
# 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
Gracias por los consejos!
Teniendo en cuenta que es una Myisam, y el proceso de reparacion lleva 3 semanas, lo mejor seria esperar o hacerlo por my.cnf ?
Como seria la forma de detener el proceso correctamente si decido no esperar mas.
Gracias de antemano
Cita de: danmaster en 5 Febrero 2015, 22:12 PM
Gracias por los consejos!
Teniendo en cuenta que es una Myisam, y el proceso de reparacion lleva 3 semanas, lo mejor seria esperar o hacerlo por my.cnf ?
Como seria la forma de detener el proceso correctamente si decido no esperar mas.
Gracias de antemano
Sacas el id de proceso con:
SHOW PROCESSLIST;Y con el id ejecutas esta query:
KILL <ID_QUERY>Tienes copia de seguridad?
no tengo copia!
de todas modas, ayer noche volvio a fallar dando error dice que solo pudo reparar 72GB,lo hare por my.cnf
Hola de nuevo,
anadi,
myisam-recover-options = BACKUP,FORCE
en el my.cnf, y le he dado restart a mysql,
mysql esta corriendo, con las otras tablas, pero como puedo ver que myisam-recover-options = BACKUP,FORCE esta en proceso?
Disculpa tantas preguntas
desaparecio toda la base de datos, no encuestro ningun rastro de ella, estuve borrando unos logs para que no se llenara el disco, y cuando vuelvo a ver, no estaba. eso no pudo haberla borrado correcto? como puedo recuperarla?
Hola chicos, alguna idea? no ecuentro la base se datos, como puedo recuperarla?
¿A que te refieres con que no encuentras tu base de datos? ¿No estan los archivos .myd, .myi, .frm en la carpeta?
Ni siquiera esta la carpeta,
habia intentado con la mline en my.cnf, pero lo resetie y luego le di un repair table nombredelatabla EXTENDED,
se estaba llenando el disco, y estaborrando unos logs,
al hacer el reset vi que la tabla estaba alli aparentemente con los datos, segui borrando algunos los y ya no pude entrar a la base de datos, en unos minutos entre de nuevo, y bannnn
ya no estaba la base de datos, verifico por consola y no esta la carpeta,
no se que hacer, si tienes una idea te la agradezco.
"No tengo backup"
¿Recuperaste 90GB (o lo que haya pesado tu base de datos) en el disco duro? Si la borraste por accidente todavia puedes recuperar la base de datos con TestDisk o PhotoRec.
Realmente debiste haber hecho un backup antes de tocar tus bases de datos.
bueno, no se si recupero, pero si vi la tabla en phpmyandmin con los 90GB, me pongo a investigar sobre TestDisk o PhotoRec.,
claro lo de no tener el backup, es el peor error
La verdad es que no se como se pudo borrar sin utilizar ningun comando!
Sabes si TestDisk o PhotoRec se puede usar con un servidor remoto?
Cita de: danmaster en 6 Febrero 2015, 16:32 PM
La verdad es que no se como se pudo borrar sin utilizar ningun comando!
Sabes si TestDisk o PhotoRec se puede usar con un servidor remoto?
Si se puede asumiendo que tienes una shell, pero primero asegurate que en verdad hayas borrado los archivos (son varios GB menos de los que deberias tener)...
Hola,
Si esta comprado que se ha borrado, antes la particion dev/sd2 estaba al 50% ahora esta en 3%, como te comente la carpeta de la base de datos simplemente se borro, pienso que fue cuando borre unos logs, no se me ocurre otra cosa.
Ahora podria ayudarme a descarcargar y activar el testdisk en gentoo? teniendo en cuenta la particion que se arrglera es dev/sd2 cuales serian los pasos,
Gracias
estoy instanto con esto:
emerge testdisk
Calculating dependencies -!!! A file is not listed in the Manifest: '/usr/local/portage-ovh/dev-db/phpmyadmin/phpmyadmin-3.3.5.1.ebuild' /
!!! All ebuilds that could satisfy "testdisk" have been masked.
!!! One of the following masked packages is required to complete your request:
- app-admin/testdisk-6.5 (masked by: ~amd64 keyword)
- app-admin/testdisk-6.8-r1 (masked by: ~amd64 keyword)
- app-admin/testdisk-6.9 (masked by: ~amd64 keyword)
que debo hacer?
bueno ya lo he descargado como trabajo con el programa?
No outdated packages were found on your system.
* GNU info directory index is up-to-date.
* IMPORTANT: 15 config files in '/etc' need updating.
* IMPORTANT: 1 config files in '/usr/local/apache/conf' need updating.
* See the CONFIGURATION FILES section of the emerge
* man page to learn how to update config files.
ns240083 ~ # ^C
Cita de: danmaster en 7 Febrero 2015, 09:24 AM
bueno ya lo he descargado como trabajo con el programa?
No outdated packages were found on your system.
* GNU info directory index is up-to-date.
* IMPORTANT: 15 config files in '/etc' need updating.
* IMPORTANT: 1 config files in '/usr/local/apache/conf' need updating.
* See the CONFIGURATION FILES section of the emerge
* man page to learn how to update config files.
ns240083 ~ # ^C
Aqui hay un tutorial en ingles:
http://computriks.com/en/recover-file-testdisk
Buneno ahora esta corriendo testdisk, cuanto podia tardar en recuperar el directorio de la base de datos, en total son 93GB ya lleva una 1:30H es normal?
Cita de: danmaster en 7 Febrero 2015, 15:22 PM
Buneno ahora esta corriendo testdisk, cuanto podia tardar en recuperar el directorio de la base de datos, en total son 93GB ya lleva una 1:30H es normal?
Hora y media no es tanto tiempo, dale un par de horas mas.
Bueno despues de tanto esperar fallo el servidor, de todos modos viendo en testdisk, no me aparece la carpeta borrada
drwxr-x--- 60 60 4096 7-Feb-2015 18:47 mysql
abro el la carpeta del mysql y sigue sin aparacer,
Alguna idea?
he usado el deep search y no aparece
Vamos a ver creo que no estoy utilizando bien la herramienta testdisk, esta es la situacion:
El servidor dice esto;
ns240083 ~ # df -h
S.ficheros Tamaño Usado Disp Uso% Montado en
/dev/sda1 20G 2,4G 17G 13% /
devtmpfs 63G 440K 63G 1% /dev
udev 63G 440K 63G 1% /dev
/dev/sda2 202G 514M 191G 1% /home
/dev/sdb1 1,8T 120G 1,6T 7% /data
shm 63G 0 63G 0% /dev/shm
La base datos de 90GB perdida esta en el /home
con testdisck usando quick serarch, sale esto;
Disk /dev/sda - 239 GB / 223 GiB - CHS 29119 255 63
Partition Start End Size in sectors
* Linux 0 65 2 2549 196 15 40957952 [/]
P Linux 2549 196 16 29053 76 15 425779200 [/home]
P Linux Swap 29053 76 16 29118 112 34 1046512
Structure: Ok. Use Up/Down Arrow keys to select partition.
Use Left/Right Arrow keys to CHANGE partition characteristics:
*=Primary bootable P=Primary L=Logical E=Extended D=Deleted
Keys A: add partition, L: load backup, T: change type, P: list files,
Enter: to continue
EXT3 Large file Sparse superblock Recover, 217 GB / 203 GiB
y usando deep search;
Disk /dev/sda - 239 GB / 223 GiB - CHS 29119 255 63
Partition Start End Size in sectors
D Linux 0 65 2 2549 196 15 40957952 [/]
D Linux 1258 225 56 3808 102 6 40957952 [/]
D Linux 1261 143 35 3811 19 48 40957952 [/]
D Linux 1266 136 23 3816 12 36 40957952 [/]
D Linux 1267 11 25 3816 142 38 40957952 [/]
D Linux 1269 54 2 3818 185 15 40957952 [/]
D Linux 1269 184 4 3819 60 17 40957952 [/]
D Linux 1272 0 1 3821 131 14 40957952 [/]
D Linux 1272 36 45 3821 167 58 40957952 [/]
D Linux 2549 196 16 29053 76 15 425779200 [/home]
* Linux Swap 29053 76 16 29118 112 34 1046512
Structure: Ok. Use Up/Down Arrow keys to select partition.
Use Left/Right Arrow keys to CHANGE partition characteristics:
*=Primary bootable P=Primary L=Logical E=Extended D=Deleted
Keys A: add partition, L: load backup, T: change type, P: list files,
Enter: to continue
EXT3 Large file Sparse superblock Recover, 217 GB / 203 GiB
La pregunta seria que hago exactamente? estoy perdido del todo!
Te deje un link con todos los pasos. Inclusive tiene imagenes con todos los pasos. En el paso ese que estas, debiste haber seleccionado la particion donde quieres recuperar el archivo.
El link:
http://computriks.com/en/recover-file-testdisk
Si claro gracias por el link, el problema es que no veo del directorio que necesito
Aquí tienes un tutorial de TestDisk en Español escrito por mí basado en la documentación original.
Tutorial TestDisk para recuperar particiones dañadas
http://blog.elhacker.net/2014/01/manual-tutorial-testdisk-para-recuperar-particiones-danadas.html
TestDisk no sirve para recuperar ficheros borrados o eliminados, sirve para recuperar particiones dañadas.
Si no ves el directorio que quieres recuperar pues es que no está.
Para recuperar ficheros borrados tienes PhotoRec (del mismo creador) u otras herramientas como Recuva, DiskDigger, o R-Linux
[Recopilación] Programas para recuperar fotos datos ficheros borrados eliminados
http://foro.elhacker.net/software/recopilacion_software_para_recuperar_datos-t314826.0.html
Cita de: el-brujo en 9 Febrero 2015, 20:19 PM
Aquí tienes un tutorial de TestDisk en Español escrito por mí basado en la documentación original.
TestDisk no sirve para recuperar ficheros borrados o eliminados, sirve para recuperar particiones dañadas.
No creo que haya sido diseñado para recuperar archivos pero si es posible:
(http://i.imgur.com/eE70IPq.png)
Los archivos en rojo, son mis .torrents y subtitutlos borrados de mi carpeta de descargas.
Gracias por la ayuda!
Con Photorec, se esta recuperando ahora mismo los logs borrados del sistema, var/log.
Se estaran recueperando los del dia 6, que fue cuando desaparecio la base de datos.
Ahora bien, teniendo los logs, cual seria la manera de intentar recuperar la base de datos?