September 3, 2014

Renaming database schema in MySQL

One of the routine tasks for a DBA is renaming database schemas, and as such MySQL added a command to carry out that purpose called “RENAME DATABASE <database_name>”. However this command just made it through a few minor releases before being discontinued (from MySQL 5.1.7 to 5.1.23). Here’s a link to the reference manual regarding the command Vadim wrote a MySQL Performance Blog post about this a few years ago where he mentions the dangerous nature of this command – that post was appropriately headlined, “Dangerous Command.” Today we will see what are the ways in which a database schema can be renamed and which of them is the quickest.

Method 1: A well-known method for renaming database schema is by dumping the schema using Mysqldump and restoring it in another schema, and then dropping the old schema (if needed).

Although the above method is easy, it is time and space consuming. What if the schema is more than a 100GB? There are methods where you can pipe the above commands together to save on space, however it will not save time.

To remedy such situations, there is another quick method to rename schemas, however, some care must be taken while doing it.

Method 2: MySQL has a very good feature for renaming tables that even works across different schemas. This rename operation is atomic and no one else can access the table while its being renamed. This takes a short time to complete since changing a table’s name or its schema is only a metadata change. Here is procedural approach at doing the rename:

  • a) Create the new database schema with the desired name.
  • b) Rename the tables from old schema to new schema, using MySQL’s “RENAME TABLE” command.
  • c) Drop the old database schema.

If there are views, triggers, functions, stored procedures in the schema, those will need to be recreated too. MySQL’s “RENAME TABLE” fails if there are triggers exists on the tables. To remedy this we can do the following things :

1) Dump the triggers, events and stored routines in a separate file. This done using -E, -R flags (in addition to -t -d which dumps the triggers) to the mysqldump command. Once triggers are dumped, we will need to drop them from the schema, for RENAME TABLE command to work.

2) Generate a list of  only “BASE” tables. These can be found using a query on information_schema.TABLES table.

3) Dump the views in an out file. Views can be found using a query on the same information_schema.TABLES table.

4) Drop the triggers on the current tables in the old_schema.

5) Restore the above dump files once all the “Base” tables found in step #2 are renamed.


Intricacies with above methods :

  • We may need to update the GRANTS for users such that they match the correct schema_name. These could fixed with a simple UPDATE on mysql.columns_priv, mysql.procs_priv, mysql.tables_priv, mysql.db tables updating the old_schema name to new_schema and calling “Flush privileges;”.

Although “method 2″ seems a bit more complicated than the “method 1″, this is totally scriptable. A simple bash script to carry out the above steps in proper sequence, can help you save space and time while renaming database schemas next time.

We on the Percona Remote DBA team have written a script called “rename_db” that works in the following way :

To demonstrate the use of this script, we used a sample schema “emp”, created test triggers, stored routines on that schema. We will try to rename the database schema using the script, which takes some seconds to complete as opposed to time consuming dump/restore method.

As you can see in the above output the database schema “emp” was renamed to “emp_test” in less than a second.

Lastly, we are happy to share the script we used above for “method 2″.



  1. Neeraj Khandelwal says:

    Very helpful.

  2. Fernando Mattera says:

    Good trick for method 2.
    Method 1 is for very small schemas.

  3. Kiran.M.K. says:

    Its really the best way. Also it saves lot of time in doing.

  4. Prem says:


  5. Very useful script. And that toolbar above the script that allows easy copy – paste is useful as well :)

  6. zhujzhuo says:

    if some user’s privileges related to this database,i can use the follow bash to flush his privileges


    DATE=date +%Y%m%d
    if [ -f "/tmp/grants$DATE.sql" ];then
    rm -fr /tmp/grants$DATE.sql;

    for i in mysql -N -s -e "select concat(\"show grants for '\",user,\"'@'\",host,\"';\") from mysql.user"|grep -w 'show grants'| mysql -N |grep -w 'GRANT'| sed 's/$/;/g' | grep $1 | awk -F'TO' '{print $2}';do mysql -N -s -e “show grants for $i”|grep -w ‘GRANT’| sed ‘s/$/;/g’ >> /tmp/grants$DATE.sql;done
    if [ -f "/tmp/grants$DATE.sql" ];then
    sed -i “s/$1/$2/g” /tmp/grants$DATE.sql;

    for i in mysql -N -s -e "select concat(\"show grants for '\",user,\"'@'\",host,\"';\") from mysql.user"|grep -w 'show grants'| mysql -N |grep -w 'GRANT'| sed 's/$/;/g' | grep $1 | awk -F'TO' '{print $2}';do mysql -N -s -e “drop user $i” ;done

    mysql < /tmp/grants$DATE.sql

  7. Does this work both on shared tablespace and innodb_file_per_table ?

  8. Steven, this should work on both types of tablespaces in InnoDB. Since renaming table is just a metadata change I dont think it could be a problem.

  9. Valerie Parham-Thompson says:

    Steven, I was curious about your question, so I tested the rename to a new database procedure above with both a shared tablespace and innodb_file_per_table. It works the same with both. I’m using 5.6.15.

  10. Simon Lee says:

    What would be the fastest way to copy a huge database with innodb tables to a new database?

  11. Ville Ojamo says:

    I would like to add that if you are using Percona Cluster, changing the mysql.db table directly will not replicate to other cluster nodes. So the commands for modifying permissions needs to be run on all cluster nodes.

    Also do not forget to put user/password for both [mysql] and [mysqldump] in a file first – otherwise the script cannot connect to database.

  12. Martin Jobst says:

    Thank you for this great solution, it saves me a lot of time!

    The only problem was the trigger dump cannot restored because it writes also the (source) database name into the dump:
    ….. TRIGGER accounts_before_insert BEFORE INSERT ON test_crm_at.accounts FOR EACH ROW BEGIN ….

    And at restore this fails at the database with the new name.
    I found no way to prevent the output of the database name in the mysqldump at line 28 ….

    So I fix this with add following after line 28:
    sed -i “s/$2\./$3\./g” /tmp/${2}_triggers${TIMESTAMP}.dump

    It’s a little strange but I think with inclusion of the point in databasename. in the regex string, it ensures that it not renames other elements as the database name.

  13. Max Newell says:

    This script is almost perfect for me when I need to rename schemas from production snapshots to different names for non-production environments. However, there is one table in all of my schemas that consistently refuses to be renamed (I’ve run your script line by line to isolate it). This is what happens in the MySQL interactive client, and I don’t understand:

    mysql> rename table promo_max.promotions to promo_xxx.promotions ;
    ERROR 1050 (42S01): Table ‘./promo_xxx/promotions’ already exists

    Actually renaming that one table to ANYTHING — even a different table name in the same schema fails:

    mysql> rename table promo_max.promotions to promo_max.s ;
    ERROR 1050 (42S01): Table ‘./promo_max/s’ already exists
    mysql> rename table promo_max.promotions to promo_max.1 ;
    ERROR 1050 (42S01): Table ‘./promo_max/1′ already exists
    mysql> rename table promo_max.promotions to promo_max.HUBBLE_TELESCOPE ;
    ERROR 1050 (42S01): Table ‘./promo_max/HUBBLE_TELESCOPE’ already exists

    (None of these tables, it goes without saying, actually exist.)

    The target database is stock MySQL 5.5.33 on Amazon RDS, using innodb_file_per_table=ON. So I don’t have access to the base filesystem to see if the claimed files already exist (but given the refusal of arbitrary, never-used names, I’m pretty sure they don’t).

  14. Todd Michael says:

    If you wanted to live life on the edge, you can also take the DB offline, rename the folder for the database (careful of MySQL file naming conventions), and then restart the DB.

    Because of the 1-to-1 nature between folder name and database name, MySQL will generally re-establish the database in the schema list … but make no effort to fix permissions etc.

  15. Casper Langemeijer says:

    In line 14:
    “show create database $2G”

    needs to be:
    “show create database $2\G”

    similarly in line 23:
    “show triggersG”

    needs to be:
    “show triggers\G”

Speak Your Mind