I have a problem with my database/schema.
I wanted to change the raid configuration on my server. To do so, I first shutdown the mysql server, which is actually percona5.6, and then moved all the files to another location.
I then restarted the server and configured the raid.
Then I let it boot, unfortunately the mysql server started as well and of course couldn't find the moved databases.
When I then moved the files back to the reconfigured drive and started the server, the databases where gone.
All databases have the right owner and group (percona:percona) and are innodb tables (file_per_table=1).
My question now is, how can I reinitialize the databases, if possible?
Thanks for the help.
You do not have to reinitialise the databases if they are in the correct directories and if all directories have the correct permissions for the database user. Also check if the directories have the correct owner.
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.
last week we were doing a big site migration, dumped around 1200 mysql db and restored them. But in the process, we restored the "mysql" database, and then we lose all the privileges and users that were already created on the new server.
Is there a way to regenerate the mysql database? I dont mind about loosing the users and privileges, but i dont want to bring the old users to this new server.
Thanks in advance for your help.
Sorry to hear that you clobbered your data! Most experienced DBA's do a backup before they do imports like the one you did, because we've all made the mistake you describe at least once.
If you have restarted your MySQL Server since you overwrote the mysql database, then no, you're out of luck. You have overwritten the data and after a restart it is now the official set of users, passwords, and privileges used by that server.
In that case, your only chance is if you have another backup of your old data from before it was overwritten.
If you only overwrote the data, but did not issue FLUSH PRIVILEGES yet, and also if you have not restarted the MySQL Server, then the old grants are still in memory. You can recover them with a tool like pt-show-grants.
Note if you use MySQL 5.7, this temporarily broke pt-show-grants, so you need to use at least version 2.2.20 of Percona Toolkit for the fix (see https://bugs.launchpad.net/percona-toolkit/+bug/1435370 for details).
After a computer crash (Mac OSX Update), I was able to recover my files from a back up. In order to make things easier on me in the future, I decided to move to XAMPP instead of using the native PHPMyAdmin and MySQL. I know where PHPMyAdmin was pointing before - how do I move the files so XAMPP can see them?
It's not a recommended means of backing up and restoring, but as long as there's nothing in the XAMPP databases you might just be able to replace the XAMPP data directory with the backup from your old MySQL one. Note that XAMPP may have "important stuff" in the database by default; I don't use it so I have no idea. You can also just drop in specific databases (which are represented on disk by files or folders of similar name), but will have to recreate permissions and users for those.
It's better to do SQL exports and imports for backing up your 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).
I've got a database (all MyISAM tables) and the machine where MySQL was running is no longer bootable. However, we have all the MySQL data files from the data directory. How can I restore the data from the MYD and FRM files, or whatever other files I should be looking at in the data directory?
I've been doing some searching on this and it sounds like for MyISAM I should just be able to copy the database subdirectory from the old MySQL data directory to the new MySQL data directory. However, that's not working for me. A database with the name of the database I'm trying to recover shows up in the list of databases in phpMyAdmin, but all the tables show "in use" and have no information (e.g., number of rows, number of bytes, column information, etc.). Any operation on those tables (e.g., SELECT * FROM {table}, REPAIR {table}, CHECK {table}) returns a "no such table" error.
One of the tools I ran across in my search is DBACentral by MicroOLAP. It's got component that's supposed to restore data from FRM/MYD files, but when I tried to run it, it didn't list any tables that it could recover from my FRM/MYD files.
This is on a developer workstation that's running Vista Business 32bit. MySQL version is 5.0.27. After fixing the machine, I went and got the exact same version of MySQL (v5.0.27), thinking that if I'm just going to drop in the binary data files I should do it with the same version of MySQL. It still didn't work.
Any insights would be greatly appreciated... thanks!
-Josh
Install the same version of mysql.
Remove mysql directory from data directory of the server and copy it from the crashed server. This is the key element
copy directory of database you want to recover into data directory of new server
start mysql.
switch to mysql database: USE mysql; and run REPAIR TABLE <table name> on every table.
Do the same with database you want to recover
tip: make sure the 2 directories have the same permissions like data directory
If you did not save mysql database (mysql directory in your old server's data dir, then you can try to:
create database with the same name as database you want to recover.
Then you can create each table (it would be good to use the same structure - you'd have bigger chance of recovery).
then stop mysql server and delete files from database directory and overwrite them with files from old server
start mysql and repair each table.
I wound up giving up. I think the answer is that, with my particular version of MySQL, this doesn't work. Hopefully things have improved since then.