Archivos Frm perdidos recuperando datos de ibdata

Archivos Frm perdidos recuperando datos de ibdata

Estaba trabajando con una base de datos mysql innodb. Cuando estaba trabajando con mysqlworkbench, accidentalmente todos los archivos .frm se eliminaron de la carpeta de datos de mysql, pero todavía tengo el archivo ibdata en la carpeta de datos. No estaba usando innodb_file_per_table, lo que significa que todos los datos de mis tablas innodb estaban en un único archivo ibdata.

Desafortunadamente no tengo una copia de seguridad para restaurar. ¿Alguien podría sugerirme cómo recuperar los datos del archivo ibdata?

Respuesta1

Tu pregunta parece idéntica aeste en Stack Overflow.
He reproducido parte de la respuesta aceptada aquí.


La solución simple es encontrar su copia guardada del CREATE TABLE SQL, ejecutarla en undesarrolloinstancia de MySQL, luego copie el archivo FRM generado a la instancia restaurada.

Si no tiene acceso a los CREATE TABLEextractos, puede intentar lo siguiente:

  1. En su base de datos restaurada, ejecutecreate table innodb_table_monitor (a int) ENGINE=InnoDB
  2. Observe el archivo de error del servidor MySQL hasta que se hayan volcado los datos del monitor de la tabla (normalmente alrededor de un minuto)
  3. Correrdrop table innodb_table_monitor
  4. Detener la base de datos restaurada

  5. Escriba SQL para que coincida con la salida del monitor de tabla, por ejemplo:

    TABLE: name db/mylosttable, id 0 7872, flags 1, columns 5, indexes 1, appr.rows 1828
    COLUMNS: id: DATA_MYSQL DATA_NOT_NULL len 12; name: type 12 DATA_NOT_NULL len 45;     
    DB_ROW_ID: DATA_SYS prtype 256 len 6; DB_TRX_ID: DATA_SYS prtype 257 len 6; 
    DB_ROLL_PTR: DATA_SYS prtype 258 len 7;
    INDEX: name GEN_CLUST_INDEX, id 0 17508, fields 0/5, uniq 1, type 1
    root page 3, appr.key vals 1828, leaf pages 9, size pages 10
    FIELDS:  DB_ROW_ID DB_TRX_ID DB_ROLL_PTR id name
    

    se puede expresar como:

    drop table if exists mylosttable;
    create table mylosttable (
        id char(12) NOT NULL,
        name varchar(45) NOT NULL
    );
    

    Si está confundido acerca del resultado del monitor de tabla, consulte el resultado de las tablas con un esquema conocido.

  6. Ejecute el SQL anterior en undesarrolloinstancia de MySQL

  7. Copie los archivos FRM creados en el servidor de desarrollo a la base de datos restaurada. Los encontrará en el directorio de datos de MySQL dentro del subdirectorio de la base de datos correspondiente.

  8. Reinicie la base de datos restaurada

    Tenga en cuenta que puede copiar los archivos FRM de su sistema de desarrollo a una instancia de base de datos activa. La razón para detener el servidor anterior es que si bloquea la base de datos después de crear la tabla innodb_table_monitor, dejará el archivo ibdata en un estado inconsistente y tendrá que comenzar de nuevo desde una copia de seguridad.

  9. Pruebe que las tablas funcionan mediante select *declaraciones. Si te equivocas verás:

    ERROR 2013 (HY000): Lost connection to MySQL server during query
    

lo que significa que la base de datos ha fallado. Si esto ocurre, hágalo create table innodb_table_monitor...en la instancia de desarrollo y compare el resultado con el resultado original de la instancia restaurada. Probablemente verás que te perdiste un NOT NULL o algo pequeño como eso.

información relacionada