MySQL database backup: performance issues

Folks,

I'm trying to set up a regular backup of a rather large production database (half a gig) that has both InnoDB and MyISAM tables. I've been using mysqldump so far, but I find that it's taking increasingly longer periods of time, and the server is completely unresponsive while mysqldump is running.

I wanted to ask for your advice: how do I either

1. Make mysqldump backup non-blocking - assign low priority to the process or something like that, OR

2. Find another backup mechanism that will be better/faster/non-blocking.

I know of the existence of MySQL Enterprise Backup product (http://www.mysql.com/products/enterprise/backup.html) - it's expensive and this is not an option for this project.

I've read about setting up a sec开发者_如何学编程ond server as a "replication slave", but that's not an option for me either (this requires hardware, which costs $$).

Thank you!

UPDATE: more info on my environment: Ubuntu, latest LAMPP, Amazon EC2.

---

If replication to a slave isn't an option, you could leverage the filesystem, depending on the OS you're using,

• Consistent backup with Linux Logical Volume Manager (LVM) snapshots.
• MySQL backups using ZFS snapshots.
• The joys of backing up MySQL with ZFS...

I've used ZFS snapshots on a quite large MySQL database (30GB+) as a backup method and it completes very quickly (never more than a few minutes) and doesn't block. You can then mount the snapshot somewhere else and back it up to tape, etc.

---

Edit: (previous answer was suggestion a slave db to back up from, then I noticed Alex ruled that out in his question.)

There's no reason your replication slave can't run on the same hardware, assuming the hardware can keep up. Grab a source tarball, ./configure --prefix=/dbslave; make; make install; and you'll have a second mysql server living completely under /dbslave.

EDIT2: Replication has a bunch of other benefits, as well. For instance, with replication running, you'll may be able to recover the binlog and replay it on top your last backup to recover the extra data after certain kinds of catastrophes.

EDIT3: You mention you're running on EC2. Another, somewhat contrived idea to keep costs down is to try setting up another instance with an EBS volume. Then use the AWS api to spin this instance up long enough for it to catch up with writes from the binary log, dump/compress/send the snapshot, and then spin it down. Not free, and labor-intensive to set up, but considerably cheaper than running the instance 24x7.

---

Try mk-parallel-dump utility from maatkit (http://www.maatkit.org/)

regards,

---

Something you might consider is using binary logs here though a method called 'log shipping'. Just before every backup, issue out a command to flush the binary logs and then you can copy all except the current binary log out via your regular file system operations.

The advantage with this method is your not locking up the database at all, since when it opens up the next binary log in sequence, it releases all the file locks on the prior logs so processing shouldn't be affected then. Tar'em, zip'em in place, do as you please, then copy it out as one file to your backup system.

An another advantage with using binary logs is you can restore up to X point in time if the logs are available. I.e. You have last year's full backup, and every log from then to now. But you want to see what the database was on Jan 1st, 2011. You can issue a restore 'until 2011-01-01' and when it stops, your at Jan 1st, 2011 as far as the database is concerned.

I've had to use this once to reverse the damage a hacker caused.

It is definately worth checking out.

Please note... binary logs are USUALLY used for replication. Nothing says you HAVE to.

---

Adding to what Rich Adams and timdev have already suggested, write a cron job which gets triggered on low usage period to perform the slaving task as suggested to avoid high CPU utilization.

Check mysql-parallel-dump also.