One of our servers crashed last week and it wouldn't boot. So I got a full copy of the whole file system, and restored a previous backup. Now it is up and running, but there is a problem: the most recent changes made to a MediaWiki site were lost (the backup is a month old). It's not much, just a couple of modifications to some articles here and there.
I am currently trying to restore the last MySQL tables of the site. The proper way of doing that is with the mysqldump command, but this is not an option because I can't boot the server, I only have the files. So I read that you can do it manually if you copy all files in /var/lib/mysql/[dbname]:
How to recover MySQL database from .myd, .myi, .frm files
Restoring MySQL database from physical files
etc
Well, I tried stopping the MySQL service and moving the files from the copy to the server, and I even granted the database user privileges again just in case, but it won't work. The site keeps showing the month old articles (yes, I have cleared the cache, and rebooted) and I don't understand why, because the files I am restoring clearly have their "last updated" field set to the date when the last changes to the wiki were made (I know that for sure).
Am I missing something here?
Problem solved thanks to user #che. I had to copy the whole /var/lib/mysql directory, not just /var/lib/mysql/[dbname]. Apparently some database information is also contained in those files.
Related
Thanks for looking!
I've tried pretty much every solution I found online, yet nothing recovered a full database.
My client had a crash of MySQL on her XAMPP, and sent over the mysql/data folder along with WP root directory(it's a WordPress website).
-she erased the mysql/backup folder
-I've tried copying ibdata1, .frm and .ibd files into fresh XAMPP, but then I get the "Table doesn't exist in engine" error in PHPMyAdmin
Also tried SysInfo MySQL Database Recovery tool, which extracts the database when pointed to database folder, and without loading ibdata1. If I load ibdata1, tables are empty. If I point the software to the database directory, I get a full database, but with a few weird issues. Some are in wp_posts table(,, instead of ,'',) which brakes the element count, but I hopefully patched it. However, some other things are not showing well, all IDs are like "-9223372036854775555", and slugs have weird characters, like "a-lepsi-jutri��u癮u�".
Post statuses look messed up as well(like "itclosedclosedsta").
On WP side, this manifests as a 404 homepage error. You can access wp-login.php, but after entering the details and trying to login you get redirected to the homepage 404.
When I replace the entire mysql folder in fresh XAMPP with a backup from my client, MySQL won't start.
Have also tried starting it with repair level 1-6, but MySQL still won't start.
Have tried creating a fresh database, adding tables and fields with .frm files, discarding TABLESPACE then copying over only .ibd files and importing TABLESPACE. This works only for empty tables.
Also some other things, but nothing worked so far.
Any WP or DB thoughts - please let me know :)
I have an error with Xampp where it will not connect to my database. I have had this error several times in the past and no solutions have helped. I find that uninstalling and reinstalling ends up being the fastest method, however, by doing so I lose my database tables. As I have no access to the default export and import functions, I was wondering how I transfer the tables across.
Last time, I copied and pasted these files into the same directory when I reinstalled Xampp and the tables transferred but the data within did not. The tables had also lost some functionality as well.
If anyone has any methods to do this I will greatly appreciate it.
The best way to backup and restore your data is to dump the database to an SQL file. You can use the provided mysqldump tool for that, which is the best tool for the job.
Copying the entire MySQL "datadir" (which is probably one level up from the screenshot you've posted) and completely replacing one of your new stopped MySQL instance will probably work, but is not reliable and is not supported. Since there are other files (such as ibdata1) that handle the overall health and functioning of the entire MySQL instance, you can't only copy over individual database directories. Furthermore, you should only do this when the original and replacement MySQL servers/daemons/services are completely stopped because otherwise there are file corruption or concurrency issues.
Since you're running the server on your own computer, you should grant yourself sufficient access to be able to use mysqldump and use that regularly as a backup, since file-level backups of the data directory are not reliable.
I'm using Appserv for local MySQL hosting. I had to reset my computer. I forgot to make backup for MySQL database and used Win 10 reset feature. So it removed all the applications but not personal files. After resetting my pc, I set up the Appserv again. I got into phpMyAdmin. On the left side, I can see all of the tables. But when i click on them, I'm having an error message "#1146 - Table 'database.table' doesn't exist". So i only have the MySQL data files which has database's .frm and .ibd files.
My question is, can i recover tables with these .frm and .ibd files?
Note: ib_logfile and ibdata files are overwrited after setup.
A quick search on Google I found an article that may help you but bear that in mind that once you erase something permanently by mistake or otherwise and if you haven't made the appropriate backups then I am sorry to say that whatever you do to try and resurrect it won't work.
Nevertheless, try out the link below and let me know of your progress:
http://www.voxteneo.com/restoring-tables-mysql-database-frm-ibd-files-available/
Today when trying to start mysql service, I got this error :
"mysql: job failed to start"
I needed to work with mysql, so I made a backup of my data directory (/var/lib/mysql) and reinstalled the server (mysql-server-5.6), note that I couldn't have used mysqldump because mysql wouldn't start, even with innodb_force_recovery>0
Now mysql starts just fine, but if I put back the old data directory, it shows the error mentioned before. I concluded that the problem comes from corrupted data
Now all I have is this data folder (containing ibdata1, ib_logfile* and such) and I want to restore all the data (not only the structure).
Thank you
"Old" and "new" are the same version 5.6? Try to check privilege of files, folders too.
Good luck.
I hope you tried all innodb_force_recovery values including 6. If MySQL still doesn't start follow instructions in my post https://twindb.com/recover-corrupt-mysql-database/ . There is a web interface to the data recovery toolkit on https://recovery.twindb.com/, you can upload and recover the database there if you are ok uploading the data.
Currently, I am syncing a WordPress project database between myself and my team via Dropbox. I notice that Dropbox never syncs the database after I make changes to it until after I have stop the servers in MAMP. This is causing conflicts occasionally if more than one member of my team edits the same database entry on their local machine and then each person closes their respective MAMP servers at different times.
I'm assuming this is because MAMP is locking the database folder while it is in use. Is there any way to prevent MAMP from locking this folder or to give Dropbox privileges that extend past MAMP's file locking?
I would greatly appreciate any help!
File locks are there for a reason. Attempting to bypass the file locking mechanism just seems to be asking for a corrupted database.
Although not at all practical nor safe, your team members can copy the file from their dropbox directory a non-synced directory make changes and overwrite the database file in dropbox. But this opens the door to overwriting others work if the version copied isn't the most up to date version (obviously).
A practical and safe solution is to connect to 1 database server and team members will be able to safely make changes on the server (and obviously everyone will have access to the most up to date version).