In the process of creating an automated solution for backing up and restoring an entire MySQL server, I've come across the mysql
database which seems to contain user accounts, permissions, metadata, that kind of thing. Should this database be backed up? Will backing up and attempting to restore it break things?
I've had a heck of a time Googling for "mysql backing up mysql database" as you can imagine.
Here is something interesting to consider: Backing up the
mysql
database limits you greatly in that you can only restore such a database to the same version of mysql you ran the backup from. Here is why:Here is mysql.user from MySQL 5.0.45
Here is mysql.user from MySQL 5.1.32
Here is mysql.user from MySQL 5.5.12
If you attempt a restore of mysql.user to a version of MySQL it was not meant for, it will produce random permission problems. The way to backup the mysql user permissions in a version-agnostic way is to dump the user grants in SQL. That way, the user grants are completely portable. There are two ways to accomplish this:
OPTION #1 : Using MAATKIT
mk-show-grants will generate the SQL needed whatever mysql instance you connect to. (Keep in mind that MAATKIT is being migrated to the Percona Toolkit. This tool will most likely be called pt-show-grants).
OPTION #2 : Script the dumping of the SQL GRANTS
I have written my own emulation of mk-show-grants. It will leave out anonymous users. It looks like this:
Using either of these options will create a more stable backup of user grants.
ON A SEPARATE NOTE
Now if you are using this log-output option
the mysql database will populate the slow log (if enabled) as a mysql table in the mysql schema rather than a text file. So, doing physical backups will include such mysql table-based logs. Believe me, it is not worth the diskspace if the general log and slow query log are enabled and piling up in the mysql schema. Just stick with the MySQL Grants Dump Options.
UPDATE 2011-09-19 15:54 EDT
There is one very important factor in maintaining backups of MySQL permissions via SQL Grants:
Each user comes out with their password in some modified MD5 format. For mysql 4.0 and back, it is a 16-character hexadecimal string. For mysql 4.1+, it is 41 characters (An asterisk followed by a 40-character hexadecimal string).
Before you restore a SQL Grants dump, check the SQL Grants dump file for any 16-character hexadecimal passwords. If you see even one, you must add the following to /etc/my.cnf (or my.ini for Windows) on the mysql server you will restore to:
The old_password directive permits 16-char and 41-char passwords to coexist and correctly authenticate in the same running mysql instance. Any passwords created going forward will be 16-characters.
MySQL restart is not required. Just run this:
Yes, you definitely want to backup the
mysql
database -- it's an integral part of your service. While you can reconstruct it's contents from other information, the difficulty of doing so is prohibitive if you're trying to get back to service quickly.You can restore the mysql database between versions, at least fairly recent versions. There is a tool called
mysql_upgrade
included in new versions of MySQL that will upgrade the system tables for you.http://dev.mysql.com/doc/refman/5.0/en/mysql-upgrade.html
As long as you restore to a similar mysql version, you can restore of the mysql database from a backup. If you are in doubt, just make a diff between mysql database schemas (the one from the backup and the one from the new mysql server).