how to prevent an attachment of .frm files to another server - mysql

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.

Related

Export table from Xampp MySQL from file directory

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.

Service did not respond in a timely fashion - Very large database

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.

Restore MySQL from files (without dump)

Is it possible to duplicate a MySQL database from their files? [I know mysqldump would be the best method to duplicate a db, but that's not possible as all we have is the backed up files from the mysql folder].
We have the ibdata1 file, the ib_log* files, and the full directories for the three db's we want to restore from the backed up files (folders seem to contain all needed frm and par files). Obviously already tried just to copy all the files into /var/lib/mysql and though it appeared the structure was intact attempts to access the data were unsuccessful.
i.e. show databases will show the db's, use dbname works, and show tables properly displays the tables, but when trying to access the data from [any] table (via query) it says ERROR 1146 (42S02): Table 'dbname.dbtable' doesn't exist - despite mysql having happily showed us the table does exist when we did show tables.
Should also point out the service was stopped prior to copying files and all files chown'ed to have mysql as owner and then the service restarted prior to attempting to access the data.
To answer your question indirectly, there is some information here regarding setting up replication using a raw file copy. So I guess the answer is possibly yes, but it may depend.
http://dev.mysql.com/doc/refman/5.0/en/replication-howto-rawdata.html
Not wishing to add to your current pain, but were you relying on a backup that you have never tried / don't know how to restore?

mysql - how do I load data from a different configuration

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.

Restore mysql server from myd myi files - windows

I have a recovery disc image which contains the datafiles for mysql server.
The original server is unavailable - all I have is the datafiles (programdata, program files etc).
I am not able to make a mysqldump file.
On the new server, I've installed the exact copy of mysql server, and copied the files/folders (all the myd myi files) from the disc image to the new server.
After restarting the mysql service, I can see the list of my databases in mysql administrator.
However, when I try to view a table, I get an error:
"1146 The table {dbname}.{tablename} does not exist."
I tried running myisamchk but this says there is n problem (at least no error is displayed)
Can anyone help?
Bob
You will need a copy of the corresponding .frm files, which contain the format information MySQL needs to read the raw row data from .myd/.myi or ibdata files. Without the .frm files, MySQL does not know the tables are even supposed to exist (which is why they're not found, and myisamchk doesn't see any broken tables).
If you don't have these files, you may be in trouble. You should be able to reconstruct the .frm by re-CREATEing the tables from scratch, then stopping the server and dropping the .myd/.myis over the empty versions. But you will need to know the exact datatypes and indexes that were originally used in the schema. (“Very difficult repair”)