The latest from the MySQL community

I just accidentally deleted all comments made on this blog.

This blog is homegrown and hand-made. It has a very simple spamfilter that catches most spam comments. The few that make it through though, I've been deleting myself using the mysql console.

I tend to write simple queries, ending in: .. AND id = 1234, but today I forgot the id =. I had a backup from October 2008, so some old comments are back now, but I'm still pretty sad.

Lesson from today: make backups! I'm pretty good with things I do for clients, but I tend to not uphold the same standards for my own projects.

Firstly, I have to thank my co-workers Singer Wang and Gerry Narvaja for doing a lot of the work that resulted in this comparison.

After running both InnoDB Hot Backup and Xtrabackup, we have found that there is a measurable but not large difference between the resources that Xtrabackup and InnoDB Hot Backup consume.

Xtrabackup:

• Free
  
• takes 1.1% longer (2 min during a 3 hour backup)
  
• uses 1.4% more space (1G more in a 70G backup — this was for uncompressed backups)
  
• uses 1.115% more cpu overall
  
• split as 0.12% user, 0.66% nice, 0.025% system, …

MySQL backup soon becomes an important matter when the database is used in production. The pain-point comes from the fact that while backuping the database is not available to respond to client requests anymore. With mysqldump - the standard tool for performing MySQL backups - and a large database the operation can go over many tenth of minutes if not hours. If I am running my business on line this is simply not acceptable.

The classical approach to workaround this problem is to take advantage of MySQL replication. I set up a master/slave configuration where the slave acts as copy of the master. Then, when needed, I run mysqldump on the slave without any service interruption on the master.

But ZFS snapshosts bring a new straightforward approach that avoids the pain and the complexity of a master/slave replication.

Snapshots are a key feature of ZFS that allows me to save a copy of …

Save the date - October 14th, 3pm Paris & Berlin, 2pm London, 4pm Jerusalem  -  for this free live webinar where you'll have a chance to ask questions to our experts.

This webinar focuses on how ZFS, SSDs and the Open Storage line of products from Sun are changing the rules in the database storage industry. You will learn how to increase data security, scalability, and reduce the price/performance ratio with these technologies. This webinar includes ZFS best practises for databases backup and performance.

To register, click here.

rsnapshot is a filesystem snapshot utility for making backups of local and remote systems, based on rsync. Rather than just doing a complete copy every time, it uses hardlinks to create incrementals (which are from a local perspective a full backup also). You can specify how long to keep old backups, and all the other usual jazz. You’d generally have it connect over ssh. You’ll want/need to run it on a filesystem that supports hardlinks, so that precludes NTFS.

In the context of MySQL, you can’t just do a filesystem copy of your MySQL data/logs, that would be inconsistent and broken. (amazingly, I still see people insisting/arguing on this – but heck it’s your business/data to gamble with, right?)

Anyway, if you do a local mysqldump also, or for instance use …

I am happy to announce that mylvmbackup version 0.13 has now been released. This release includes a fix for a nasty bug in on of the recently added Perl hooks (precleanup.pm) and some added functionality (better support for remote rsync backups).

From the ChangeLog: 

• Deleted sample precleanup.pm hook as it has potential to cause harm and is too specialized on a particular use case (BUG#394668)
• Added support for rsync via SSH (BUG#392462)
• Fixed InnoDB recovery in case a relative path to the MySQL data directory is defined (BUG#38337), improved the documentation of relpath in the man page.

Do you know if your production MySQL servers will come back up when restarted? A recent support episode illustrates a number of best practices. The task looked trivial: Update a production MySQL server (replication master) with a configuration tuned and tested on a development server. Clean shutdown, change configuration, restart. Unfortunately, the MySQL daemon did not just ‘come back’, leaving 2 sites offline. Thus begins an illuminating debugging story. First place to look is the daemon error log, which revealed that the server was segfaulting, seemingly at the end of or just after InnoDB recovery. Reverting to the previous configuration did not help, nor did changing the InnoDB recovery mode. Working with the client, we performed a failover to a replication slave, while I got a second opinion from a fellow engineer to work out what had gone wrong on the server. Since debug symbols weren’t shown in the stack trace, we needed …

If you're interested in ways to back up stuff, and haven't tried Dar yet, here's an article on using Dar that I've just published on my personal blog. In short, Dar works very much like Tar, but it's got a built-in feature for slicing up archive files which comes handy when you want to distribute backup files across several media, for example DVDs or hard disks.

If you're interested in ways to back up stuff, and haven't tried Dar yet, here's an article on using Dar that I've just published on my personal blog. In short, Dar works very much like Tar, but it's got a built-in feature for slicing up archive files which comes handy when you want to distribute backup files across several media, for example DVDs or hard disks.

If you're interested in ways to back up stuff, and haven't tried Dar yet, here's an article on using Dar that I've just published on my personal blog. In short, Dar works very much like Tar, but it's got a built-in feature for slicing up archive files which comes handy when you want to distribute backup files across several media, for example DVDs or hard disks.