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.

4 Answers
4

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:

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:

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:

[mysqld]
old_password=1

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.

I would better spell the SHOW GRANTS generation SQL using QUOTE(), like this: SELECT CONCAT('SHOW GRANTS FOR ',QUOTE(user),'@',QUOTE(host),';') FROM mysql.user WHERE user<>'';
–
kostixApr 12 '13 at 11:30

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.

+1 If you don't backup the mysql database the odds of having a broken system after doing a restore are very high. Been there, done that, got the mental scars to prove it.
–
John GardeniersSep 19 '11 at 0:35

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).

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.

This is very true. I have seen cases where some use this and upgrade just perfectly. I have seen others butcher it. From my standpoint as a MySQL DBA. I have lost faith in that method. Since your answer reflects sound faith in its use, you must be from the first group. +1 for such confidence in mysql_upgrade.
–
RolandoMySQLDBASep 19 '11 at 20:15