Member Avatar for Thodoris_1
Thodoris_1 0 Newbie Poster

Hello! I have a problem with a MySQL database that I haven’t been able to solve no matter how much I tried, either with internet guides or with free tools. I really don’t want to pay hundreds of dollars to a company so please, if anyone knows of a solution, help me because I’m desperate.

I was running XAMPP 7.1.22 where I had said database and I decided to install XAMPP 7.2.10 without backing up the database. After that, the site wasn’t working so I figured the problem was the database. And indeed PHPMyAdmin wouldn’t recognize it. I reinstalled the previous version of XAMPP and the database was there but unfortunately I could only see the tables. The tables themselves were empty though. So no dump procedure worked and neither the site. Now all I have left is the folder with the database which contains all the .frm and the .ibd files, an .opt file, a .myd file and a .myi file. I also have the ibdata1 file.

Any ideas or suggestions? Thank you very much for your time.

  • 1 Contributor
  • 0 Replies
  • 376 Views

Dani AI

Generated

Practical recovery checklist for (concise, proven steps and cautions).

Start by making a complete byte-for-byte copy of the entire MySQL/XAMPP data directory (including any ibdata* and all table files). Never work on the originals; all recovery attempts should be done on copies. Stopping the server before copying avoids inconsistent file state. (dev.mysql.com)

Treat engines differently. MyISAM tables (data/index files) are the easiest: place the .MYD/.MYI/.frm into a stopped server’s database folder, fix ownership, restart, then run REPAIR TABLE or myisamchk -r if needed. That usually restores visible rows quickly. (docs.oracle.com)

InnoDB tables require care. Preferred path when the InnoDB system tablespace (ibdata) is available and the server version is the same: recreate the original datadir layout on a matching MySQL/MariaDB build and start the server. If the data dictionary is lost or the server rejects the tables, extract the CREATE TABLE from the .frm and reattach the .ibd using the discard/import workflow: create the same table (same DDL), run ALTER TABLE db.t DISCARD TABLESPACE, copy the original .ibd into the database directory (set file ownership), then ALTER TABLE db.t IMPORT TABLESPACE. An export-generated .cfg/.exp file (if present) helps schema validation but import can still work without it with warnings. (dev.mysql.com)

If the .frm contents are unknown, use mysqlfrm (MySQL Utilities) or similar tools to recover the CREATE statement, then follow the discard/import method above. Always recreate the table with an identical schema before importing. Example sequence:

mysqlfrm --diagnostic /path/to/db/table.frm
# on recovery server:
CREATE TABLE db.table ( ... identical DDL ... ) ENGINE=InnoDB;
ALTER TABLE db.table DISCARD TABLESPACE;
# copy table.ibd into datadir/db/, chown mysql:mysql
ALTER TABLE db.table IMPORT TABLESPACE;

(manpages.debian.org)

Warnings and final notes: mismatched MySQL/MariaDB versions or differing InnoDB settings (file‑per‑table on/off) often block imports; some errors indicate “created with MySQL X now running Y.” Use innodb_force_recovery only as a last resort to enable dumps (start low and increase cautiously — values ≥4 are risky). If these steps fail or data is critical, consider professional recovery (Percona/Oracle) rather than risking destructive operations. (cs.usfca.edu)

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.