How to detect a running mysqldump?

Question

Here are the things I can't change: We got a mySQL myISAM replication running a master and some slaves. One slave is being used for nightly backups using mysqldump. The backups is using heavy locks forcing it's slave to "age" compared to the master. mysqldump is connecting as root dumping all the databases while every other connection is using one non-SUPER-user per database. The dumps are started using a simple shell script on a dedicated backup server.

Here is the problem: I'ld like to detect if a backup is running or not while being connected as a "normal" user to one of the databases running on the server being backuped. Cronjobs should be able to react on the running backup by exiting early or processing only really important required jobs which can't wait until the backup is done. The server running the backup script has no connections to the webservers, their only common point is the mysql server. The backup script could do some things to flag the server as "currently running a backup". I'd prefer to set some kind of "global server-side environment variable visible by all users" to ignore only the one slave running the backup but it would also be ok to simply know that a backup is running on that database or replication chain. Using the database for this is no option as it's being locked during the backup.

I tried to create a temp table on backup start (existing = backup is running, not existing = no backup running), but temp tables only show up for the connection which originally created it (as expected). I googled if a non-SUPER-user could get the permission to see the SHOW PROCESSLIST of all connections including other users and root (any connection from the backup server = backup is running) - but no luck. Giving SUPER to all database users is no option.

Any suggestions?

Thanks for reading (and answering).

Answer 1

Your only hope in this scenario is to have the PROCESS privilege.

The SUPER privilege allows you to kill processes. Naturally, you don't want that. On the other hand, the PROCESS privilege allows you to see the processlist.

According to the MySQL Documentation on the PROCESS Privilege

The PROCESS privilege pertains to display of information about the threads executing within the server (that is, information about the statements being executed by sessions). The privilege enables use of SHOW PROCESSLIST or mysqladmin processlist to see threads belonging to other accounts; you can always see your own threads.

OK, Big Deal. The PROCESS Privilege lets you see the Process List. How does that help?

You can quickly detect a mysqldump in progress when you run SHOW PROCESSLIST; and see a pattern like this in the Info field:

SELECT /*!40001 SQL_NO_CACHE */ * FROM

If you have the PROCESS Privilege and are running MySQL 5.1+, you can run this query:

select COUNT(1) mysqldumpThreads
from information_schema.processlist
where info like 'SELECT /*!40001 SQL_NO_CACHE */%';

Here is a sample output:

mysql> select COUNT(1) mysqldumpThreads
    -> from information_schema.processlist
    -> where info like 'SELECT /*!40001 SQL_NO_CACHE */%';
+------------------+
| mysqldumpThreads |
+------------------+
|                1 |
+------------------+
1 row in set (0.00 sec)

All you need to do is query for that number. If you get a nonzero, mysqldump must be running.

Give it a Try !!!

Answer 2

Make your backup script set up a value in some separate table before backup starts, and reset it when it ends. You can then just query for this value.

Answer 3

You might want to read up on using LVM snapshots to backup you myisam tables and minimize replication down time to a couple minutes:

http://www.mysqlperformanceblog.com/2006/08/21/using-lvm-for-mysql-backup-and-replication-setup/

If you're able to migrate to innodb you could user xtrabackup and take live backups with next to no noticeable interference.

Edit

Personally we were using LVM snapshots for a ~220 GB instance spanning 3 databases. The overhead of the LVM snapshot and load on the disks caused replication to fall behind as much as 8,000 seconds nightly. There wasn't any locking but the poor little disks just couldn't keep up with the heavy replication load and the backup. We had to switch to fusion io. That's certainly nice -- but very costly.