Reset MySQL root password without restarting MySQL (no downtime!)

Disclaimer: Reset the MySQL root password at your own risk! It doesn’t apply if you’re using Pluggable authentication and certainly won’t be usable if/when MySQL system tables are stored on InnoDB

Reset MySQL root password with care!

Reset MySQL root password with care!

What is the situation?

The situation is the classic “need to reset MySQL root password” but you cannot restart MySQL (because it is the master production server, or any other reason), which makes the –skip-grant-tables solution as a no-no possibility.

 What can I do?

There is a workaround, which is the following:

  •  Launch another instance of mysqld, a small one (without innodb).
  •  Copy your user.[frm|MYD|MYI] files from the original datadir to the datadir of the new instance.
  • Modify them and then copy them back to the original location.

That simple? No, but close. Here is the step by step:

Step by step recovery

  1. Create a new datadir and run mysql_install_db for the new datadir. This one will be removed at the end. Don’t forget to change ownership to mysql user and group:
  2. Launch the new instance. Be careful with the datadir path, the socket file and the port number. Also, disable InnoDB, you won’t need it, just add –skip-innodb AND –default-storage-engine=myisam:
  3. Copy the user.* files from the original mysql instance (the ones that you need to modify) to the new instance’s datadir and login to this instance of mysql:
  4. Execute a “flush tables” command, so the user table will be “reopened” and you can see the data and verify:
  5. Now, reset the MySQL root password field with the desired value:
  6. Verify again:
  7. Flush privileges and verify that the new password is correct, by logging in again:
  8. Now that we have made the changes, we can move back the user.* files to the original location, being extremely careful with owner and privileges:
  9. At this moment, you can shutdown the new mysql instance since is no longer needed. Be very very careful so you don’t end up shutting down your original mysqld!:
  10. Now, the last step is to execute a “FLUSH PRIVILEGES” in the original mysqld. Since we cannot yet access it, we need to send a SIGHUP signal to mysqld. MySQL responds to this signal by reloading the grant tables and flushing tables, logs, the thread cache, and the host cache, so choose wisely the moment of the day when you want to send the SIGHUP since the performance might be degraded (look at “flush tables” ).The way to send SIGHUP is to execute “kill” command with the -1 flag:
  11. Finally, login into MySQL as root!:

    You can see your schemas? of course you can! your databases are okay!

We’ve successfully reset the MySQL root password without the need to restart MySQL and thus avoid downtime.

I hope you never face this situation, but in case you do, there’s a workaround to recover your access! Is there another way to perform this?

Share it with the world!

Share this post

Comments (8)

  • rucypli Reply

    nice

    December 10, 2014 at 10:16 pm
  • Harjit Lakhan Reply

    Nice work, one extra step – before copying back in step 8 – BACKUP the orignal files , JUST IN CASE!!!

    December 11, 2014 at 7:09 am
  • Fadi El-Eter (itoctopus) Reply

    Hi Daniel,

    That is super helpful and it does save lives especially for mission critical applications.

    Quick question: If someone is logged in with the old root password, and the above is done, will he be logged out or will he still be logged in?

    December 11, 2014 at 12:23 pm
  • Chintoo Reply

    I am working as MySQL DBA Since 2007 , This article explore the security of MysqL

    Although this is Nice article , I did this step before, but that was much easier than this.

    1- Go to /var/lib/mysq/mysql
    2- vim user.MYD
    3- check the password in the file
    4- In Every production server there will be backup user with reload privileges
    5- enter the MySQL with backup user
    6- below command will show the backup user encrypted password
    select user,password from mysql.user where user=’backup’;
    7- now on OS command prompt replace with below command

    sed -i ‘s/611c244e5a929da3/1d86bc847e3f5728/g’ user.MYD

    8- enter the mysql prompt with backup user and execute below command

    FLUSH TABLE;
    FLUSH PRIVILEGES;
    now exit

    9- enter with root new password of backup user password without restarting MySQL

    minimum backup user privileges needed.for production database

    GRANT SELECT, RELOAD, EXECUTE, SHOW VIEW, EVENT ON *.* TO ‘backup’@’localhost’

    December 12, 2014 at 1:58 am
  • Brijesh Patel Reply

    I really doubt you can modify user.MYD as Chintoo suggested, but you can try using one of the Hex Editor to modify the file and update or empty out the password from the file.

    December 15, 2014 at 12:56 pm
  • rajesh Reply

    Hi Daniel,

    very good article..I got some doubts ..If we have copy user* from recover instance to original instance only root user will be copied..What about if we have other users like backup user,other users?????

    And also i have faced table corruption when i copy from 3307 to 3306.

    December 9, 2015 at 6:27 am
  • Dim Reply

    super post. thanks a lot!

    August 24, 2016 at 5:46 pm
  • Sander Reply

    How does one replicate these changes into the other servers of the cluster? Whenever I restart my cluster, the changes I’ve just added are overwritten by a state transfer.

    April 1, 2017 at 6:30 pm

Leave a Reply