Using phpMyAdmin, I tried to rename my 6GB database, only to discover that the operation takes a couple of hours. According to this SO question, it sounds like renaming a database requires creating a new database and copying the data over. Why isn't the name just a pointer to some text that can be changed at will?
Edit on 14 March 2016
I originally accepted Gandalf's answer because I could not replicate the DB renaming taking so long. But this long renaming process is happening again. Here is a screenshot of phpMyAdmin hanging:
And here is a screenshot of the results from SHOW PROCESSLIST when connecting directly to the MySQL server:
It looks like the query is spinning on adding a constraint. I'm pretty sure the command that phpMyAdmin ran was:
RENAME TABLE harmonizome_temp TO harmonizome;
This is probably necessary to ensure database integrity if there's an error during the process.
Information about the database is stored in both the filesystem (each database is a directory) and also in the INFORMATION_SCHEMA database. When you rename a database, both have to be updated. If it simply renamed the directory and updated INFORMATION_SCHEMA, there would be a period of time when these are out of sync. And if the process is aborted at this stage, the database will be corrupted.
By copying the data, it can ensure that they're never out of sync. The old directory is not deleted until after everything INFORMATION_SCHEMA is updated to refer to the new database name. If the process is aborted in the middle, you'll have duplicate data in the filesystem, but INFORMATION_SCHEMA will point to one or the other (a transaction can ensure that everything in INFORMATION_SCHEMA is updated atomically).
Related
I accidentally dropped a database which I used for my web application, and it is in MySQL. Browsing through the internet I found out that to recover you need to have binary logs enabled. Read that binary logs records only changes in tables, so what it has to do with recovering a db. Upon executing the command "show binary logs;" console shows me "Error Code: 1381. You are not using binary logging". I am a newbie to MySQL, so is it possible to recover it without my binary logging enabled PLUS I have not made any real backup for the db. Going through the MySQL "my.cnf" file found that InnoDB is default enabled, can it help me recover.
If I cannot recover, please mention the steps to be carried out next time creating a new db to ensure that I could recover even if it has been accidentally deleted.
I think it can't be recovered. In case of this case, you can do the following when creating a new db:
open the binary log by add the following:
log-bin=/data/mysqlbinlog/mysql-bin
binlog-format=mixed (or row)
create a slave db.
Good luck for you.
all,
I use mysqldump to backup mysql cluster data with 10 million lines data daily. Recently, our cluster is crashed after a update, then we restore the .sql file generated by mysqldump. When restoring the database, we got key duplication errors/problem, and then I use "-f" to force the restore process. And finally, the restore process completed and all tables is back. Some tables are smaller, we think that is because the duplicate lines are ignored.
But recently, we find some data is missing, it seems that some duplicated data dose not restored correctly.
May I know whether there is a nice way to avoid this in restore process or how to check whether we have duplication before mysqldump?
Couple of suggestions - take a look at the errors that are generated when not using the force option and see if you can figure out how to fix the root cause. Using the force option allows the restore to continue after the error but the failed rows will still be lost.
Is there a reason why you're using mysqldump rather than the backup command within ndb_mgm - which is an online operation? If using the native Cluster (on-line!) backup then you use the ndb_restore command to restore your data.
I am recovering a missing mysql db with tables and have the frm files and ibdata1.
I have used innodb_file_per_table to make each DB have its own data file and tests show that new DB now use this system when created.
I noticed that when I to view the newly imported frms and data or write any SQL against them, they aren't being found. Several 'views' are available, but no tables.
If I run check table sometablename, I get that the table doesn't exist.
If I try to create a table with the same name, I get that the table already exists.
I have stopped and started the MYSQL service several times, hoping it would pick up the new frms, but nothing.
Any idea?
You can't restore a database by simply loading in the contents of the database directory. InnoDB stores other information in some master files located in the main MySQL data directory.
The only reliable method of recovering all data is to either use a mysqldump and restore procedure, or to FLUSH WITH WRITE LOCK before copying the entire contents of the MySQL data directory. This method is not recommended for production systems as it locks the entire database for the duration of this operation.
Somehow, using MAMP PRO in my macbook certain two tables just disappear after a while. This has just started a couple of weeks a go and I can't find why. I read the logs and it points me to the INNODB troubleshooting the website tells this error
[ERROR] Cannot find or open table dbcobros/seguimiento from the
internal data dictionary of InnoDB though the .frm file for the table
exists. Maybe you have deleted and recreated InnoDB data
files but have forgotten to delete the corresponding .frm files of
InnoDB tables, or you have moved .frm files to another database? or,
the table contains indexes that this version of the engine doesn't
support.
is an example of out-of-sync data dictionary. I followed the advice and deleted the .frm orphaned file but I still couldn't recreate the table, so I deleted the database and created one again, and run an SQL dump I had. After a couple of minutes it happened again!
How this happened? How can I re-sync the data dictionary? Is this a problem with the mysql installation of the MAMP? I'm about to go into production with my application but now with this error I'm not sure if it will replicate in the production servers and they will lose critical data. Please help!
I have a script that needs to add data to a folder created in the mysql data folder and then in some way force the mysql server to reload the data so the database reliably shows up. I am currently using a system call to the /etc/init.d/mysql script to restart the server but this is quite slow, I couldn't find anyhting in mysql that would reload the database through a query of some kind.. I was just wondering if there was a way to do this that was slightly quicker?
This depends on the storage engine you're using.
MyISAM tables will be reloaded automatically as soon as the table is next touched by MySQL (obviously, you need to make sure the .MYI, .MYD and .frm files are consistent).
InnoDB is a bit more complex, and depends on whether it's a traditional configuration with all tables in the same tablespace, or if you're using innodb_file_per_table. With the former, you pretty much have to restart the server. With file-per-table, you can copy individual .ibd files, but then you have to use an ALTER TABLE statement to import that tablespace.
See here for information on working with individual .ibd files without restarting the server.
This page is also useful for seeing how to move InnoDB data from place to place.
What do you mean by 'quite slow'?
You could do a dump/load of the new db in a one named orginal_db_name_temp, rename the original DB, and then rename orginal_db_name_temp to orginal_db_name - then you will have your new DB in place.
However, I don't know which method is faster by your means - because a dump&load roundtrip will be probably slower than a file-copy. But renaming the DBs will probably be faster than restarting the server