Sometimes I have dedicated RAID1 array for OS and having binary logs and tmp files on this device can be efficient.

“”"
Also I’ve just recently started making a separate logical volume for MySQL binlogs. This helps just for data management (its much more obvious when its time to backup & purge binlogs versus when its time to look for more table storage) but it definitely allows mysql snapshots to be a lot smaller.
“”"

When I was running important (to the company) MySQL swervers I had my binlogs on an entirely different physical path. We would put the tables on a RAID, and the binlogs on the boot drive, which was not RAIDED or backed up in any way (We were using System Imager to install our servers, it was much faster to reinstall from scratch than to restore from backup). This way the logging didn’t compete (as much) with the data for IO, and it would be *very* unlikely that we would lose both the RAID and the boot drive.

Because of our very special circumstances we were running RAID0 on the raids and replicating across machines. On *any* failure we’d switch to the slave immediately and start restoring the data to one of the spare dbs in the rack. Yeah, it’s not the best way, but it is the cheapest, and that mattered at that time.

Of course for inventory reasons we were running the same drive on the boot drive as in the raids (at the time 200 and 250GiB IDE drives) so we had *plenty* of space.

We were also doing LVM snapshots to back up our dbs, but we were using LVM 1, and wrote our own script. IIRC we allowed 10% of a ~2TB volume for snap. Since during that time of day we have relatively low writes to those tables it was plenty.

I just found this blog, and it looks great. Thanks for hte info.

Indeed this is good way to understand how things are going. Actually logging it may make sense so you can see how your undo space requirements fluctuates so you do not run out of it before you expect.

So my backup script does this (runs on a dedicated “backup” slave, so the flush tables w/ read lock doesn’t interfere with any queries or anything)

flush tables with read lock; (it loops until slave_open_temp_tables=0)
flush logs;
show master status; > status.log
show slave status; >> status.log
make lvm snapshot of data partition
unlock tables;
mount snapshot in snapshots dir
copy status.log to snapshot mount

After that bacula comes along and backs up the snapshot mount and binlogs directories.

I like that mylvmbackup spawns a new mysqld to perform the InnoDB recovery btw. I will have to incorporate that at some point.

The script actually prints the output of “lvs” at the end of the backup, which also provides information about the percentage of backing store used during the life time of the snapshot. This allows you to tune the snapshot size to your requirements.