I have a very large sql database that I was trying to switch over to a different computer. When starting sql on that other computer I got the error of
"service did not respond in a timely fashion".
So I switched the database back to my original computer, got the same error, deleted the ibdata and ib log files and .frm files. Same error.
I assume it's not waiting long enough to read the tables but don't know how to correct this. I read the fixes about VIA protocol but this is not a networked drive, its just connected via usb.
My main concern is that my database will be lost. Please reassure me that if i have the ibd file that my database is still safe.
I'm thinking I should reimport my ibd file using this method.
https://dev.mysql.com/doc/refman/5.6/en/innodb-migration.html#copy-tables-cold-backup
Correct?
Edit. I was able to reimport my data using this method. Just had to remake my schema similar enough to the original.
Related
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 have a database file (that I have current backups of) fail to open with error 3022. All of the tables used are remote, SQL Server or access. My backup database file can open with no issues and we have no data lost. I tried to do a compact and repair on the file remotely using application.CompactRepair but that fails giving me error 31523. I tried using the command line and opening the file with the /compact switch, but that also failed.
Why would I be getting the 3022 error just opening the database file?
It seems that there was a network error while accessing the database file on a network share. That caused internal corruption in a way that I don't really understand, and can not repair with a compact and repair. The good news is, a query that specifies the database file as a source CAN access data from any tables said database has, the bad news is, if there are any objects like forms, reports, or code modules that you do not have a backup of, you are out of luck.
The moral of the story? Keep good backups and don't use local tables.
As title says, I had an unfortunate failure which resulted in me only being able to recover my MySQL data folder (IBD, FRM, and OPT files). I built a new server and installed MySQL 5.6 (old one used 5.5). I copied over the data folder hoping I would get lucky, and I do see my old schemas in MySQL workbench, but when trying to look at any table in them I get an error like this:
https://www.dropbox.com/s/q2eui8eyu621f3c/sqlerror.jpg?dl=0
I don't remember seeing any .data files on the recovered data and am wondering if it's possible for me to recover my old tables. I'm not sure whether or not the old or new is InnoDB or myisam and am not exactly sure how to tell.
Any tips appreciated.
In case someone else who doesn't know how to restore their databases runs into a similar issue, I was able to recover my data. Instead of copying and pasting everything in which did not work, I stopped the MySQL service, pasted all the database folders in, and only the "ibdata1" file. Then I restarted the service and loaded up workbench and all my data as restored in 5.6.
if you copy .frm files of mysql database to another server, you will be able to get the table structure. This means if someone get access to my server and copy .frm files the person will see my table structure when it is attached to his server. this obviously makes it unsecure. How do you prevent that from happening?
hiding the path does not solve the problem because the .frm file can be searched.
Is there a mechanism that will generate an error when the file is attached to a different server?
Your schema is not that important for security. Getting the table structure is only a security threat if you have other security problems in your code. What you should be really worried about is how someone got to your .frm files in the first place because that means they have access to your database server, and hence possibly all your database data. The schema is the least of your problems.
When people have access to files on your server the battle is already lost. They should not get that far in the first place. Therefore make sure you secure your SSH server, file servers etc.
I'm not sure if this will make sense, but I'll give it a shot.
My hard drive went down and I had to reinstall the os along with all my webserver configuration,etc. I kept a backup of the mysql database, but it doesn't contain all the tables...I added a couple tables after my last backup.
I have access to the hard drive and the directory where the mysql data files are stored from the failed hard drive, but I don't know how to retrieve the data into my new mysql database. Is it even possible to get the raw data files from mysql and load them into a different instance? I'd even be happy if there was some way for phpmyadmin to show the data files, then I could dump out to a backup txt file, and reload them into my new configuration.
Any help will be appreciated. thanks.
well, bad news...I can't access the drive anymore. As I tried to copy the files the drive went totally down. So, I'll just redo the couple tables. Thanks for your help anyway.
Although not recommended or reliable, it is possible to simply copy the data without using mysqldump. It might help if MySQL was shut down in a controlled manner (which does not appear to be the case) and the source and target environments are as similar as possible in terms of lib and MySQL versions.
The datafiles should be compatible - you can copy the data directory to ubuntu, and edit the /etc/mysql/my.cnf to point to the new directory.
The only catch might be where ubuntu being case sensitive effects the tables.