Mysqldump me hace el backup a medias y PHPMyAdmin también

[pokerman]

Hola amigos,

Lo primero agradecer a los creadores esta gran comunidad. He estado buscando antes de escribir este post pero no encontré la solución, puede que haya buscado mal, de ser así agradecería que me mostraséis el enlace.

Mi problema es que tengo una base de datos de unos 180 MB y al intentar exportarla con PHPMyAdmin se me crea un archivo .sql de unos 77MB, da igual lo que haga, siempre pesa lo mismo. Esto me ocurre desde que cambie de servidor hace poco, antes con las mismas opciones me funcionaba.

Así que pensé que sería una restricción del server en la bajada y pensé en utilizar mysqldump para crear el backup en el servidor y luego descargarlo. Pues bien, cuando lo hago resulta que la base de datos es siempre de unos 67MB...

Es desesperante. He pensado que viendo los logs sabría donde está el problema pero... PHPMyAdmin no tiene (creo), mysqldump no da error y tampoco tiene log y en el de mysqld no viene nada sobre eso y no se que logs más mirar...

No es un problema de espacio, ha suficiente. Y tampoco de la configuración del tiempo de ejecución de los procesos en el server (casi seguro, he modificado alguns archivos sobre eso y nada).

He pensado que podría ser un problema de la propia base de datos, que esté corrupta en algún sitio y ahí se pare pero no se como saber si es eso ni como arreglarlo (aunque he leído de herramientas en el foro pero no me atrevo a pasarlas sin estar seguro).

Espero que alguien pueda ayudarme, muchas gracias por adelantado.

Salu2.

[gnzsoloyo]

Puede que estés confundiendo la longitud del backup de la base, con el tamaño de la base en sí.
Jamás son iguales.
El motivo es simple: Ninguna de las dos herramientas mete los índices en un backup, lo que hace que la longitud del archivo generado sea siempre menor.
¿Por qué no los mete? Bueno, es simple:¿Para qué meter en el backup algo que de todos modos se va reconstruyendo sólo, a medida que los datos de las tablas, que sí están en el backup, se van cargando?
Poner los índices implicaría que luego de cargar nuevamente todo, habría que indicarle que haga un reindexado para eliminar basura... No tendría ninguna utilidad.

[pokerman]

Hola gnzsoloyo, muchas gracias por la ayuda, realmente te lo agradezco mucho.

Realmente no se mucho de esto ya que la base de datos está construida automáticamente ya que es de un foro phpBB.

El caso es que antes cuando funcionaba tenía un tamaño similar al que indica en el panel del PHPMyAdmin. Ahora no y además el problema es que si la exporto comprimida en .zip o en .gz al intentar abrirlo me dice que el archivo está dañado y no me deja.

Un dato, cuando la base de datos ocupaba un poco más de 100 megas hice el backup (en el anterior server y con PHPMyAdmin), en .gz y ocupa 16,8MB y el .sql de su interior ocupa 99MB.

Lo que no entiendo es que hago lo mismo ahora y se descarga un archivo de 77MB comprimido en .gz que no me deja abrir. Hago lo mismo exportandolo como .sql y se descarga de 45mb.... No entiendo nada.

Crees que podría estar corrupta la base de datos? Como puedo averiguar si falla alguna tabla? Es que no encuentro nada en la red...

Muchas gracias de nuevo.

[pokerman]

He estado revisando la base de datos y me he dado cuenta que las tablas son de tipo MyISAM, por lo que he probado con mysqlhotcopy pero esta vez no me deja ni empezar, me salta este error:

DBD::mysql::db do failed: Access denied; you need the RELOAD privilege for this operation at /usr/bin/mysqlhotcopy line 458.

[gnzsoloyo]

No puedes usar mysqlhotcopy porque requiere permisos que no tiene el user que tu utilizas para la conexión. Eso lo tienes que consultar con el soporte técnico del hosting.
Respecto a los archivos de backup, yo primero evitaría usar la compresión y dejaría que se genere directamente el .SQL. Una ves hecho esto vería si se puede usar ese script para crear una copia de la base con otro nombre en una PC local.
Recién luego de hacer esas pruebas, si la recuperación a una base nueva falla, revisaría el script para ver dónde falló y/ o dónd ese cortó, y de haber defectos, consultaría al soporte técnico del host.

[pokerman]

Gracias de nuevo, pero ya hice esos pasos, además como te digo intenté el backup del .sql y me descarga un archivo de 45MB...

El servidor es dedicado así que tengo accso completo a él.

[gnzsoloyo]

Magnífico.
¿Probaste recrear la base en otra PC, en forma local?
Sólo desde el .SQL, no desde los comprimidos.

[pokerman]

Claro que lo hice, desde un hosting que tenía anteriormente, sin comprimir, solo el .SQL.

Pero ahora desde el nuevo servidor no me deja, por eso pienso que puede ser que alguna tabla esté corrupta.

Me podrías indicar como saber si una tabla o una base de datos tiene problemas?

Muchas gracias por la ayuda :)

[pokerman]

Estuve mirando el log de mysqld.log y me acordé que habñia reiniciado el servidor una vez por problemas que tuve y resulta que esto no es bueno, debo primero cerrar el server de mysql pero no lo sabía.

He pasado un CHECK TABLE a todas mis tablas y había unos errores en varias de ellas porque había sesiones abiertas y no cerradas, he vuelto a pasarlo con la opción de EXTENDED y ahora pone todas las tablas OK, excepto una.

Hay una tabla que pone "The storage engine for the table doesn't support ...", que debe ser la que me está fastidiando. He intentado un REPAIR TABLE con esa tabla pero me dice lo mismo: The storage engine for the table doesn't support...

Ahora no se que hacer, si pasar myisamchk o no, porque no tengo experiencia en estos temas...

Para eso debería parar el mysqladmin y por consiguiente el mysqld primero, no? Perdería datos?

Gracias de antemano