I ran sql-bench on the MySQL server, which as you know runs millions of queries, and I didn’t drop any queries until I got to one of the tests that runs millions of small non-database calculation/function-based SELECTs.

However, since you’ve asked, I guess I ought to go test and compare.

Have you done any benchmarking on the performance effect of the probes yet?
It would be interesting to see how much overhead we suffer in a production environment (not much I’d bet :))

Hope I will be able to attend.

Maybe we should move that up.

Yes, AVS is the way to go for a more complete DRBD-like solution, and I’m working on an AVS blog post at the moment.

However, AVS is limited to OpenSolaris at the moment, and basic ZFS replication can be used on OS X and FreeBSD too.

I would like to see some time devoted to the DTrace probes available in the current source tree and working with them.

Thanks,
Amit

See: http://opensolaris.org/os/project/avs/

The idea behind AVS is very much the same as DRBD.

I had to manually build MySQL 5.1 using a custom ebuild package, even though Gentoo has 5.1 ebuilds (though they are WILDLY out of date). I used to be a Gentoo fan but their lack of quality control and uniformity has me thinking that it can never compete with any of the heavy hitters (Ubuntu, Red-Hat, etc.). Not until they develop a clear vision, clear process, and cleanup all the cruft that has been collecting over time.

But the point is that you shouldn’t ever be keeping snapshots long term.

In a typical backup setup, you’d keep limited snapshots around (say one a day), but most likely copy anything more than day old, and certainly a week old, off somewhere else.

In a replication environment, as I’ve described here, you need only keep the snapshots for as long as it takes to replicated them to the slave machine, plus enough snapshots for you to be able to create a suitable incremental for zfs send.

I replicate between two machines with a snapshot every 15 minutes, and keep one snapshot from the start of the day (literally at midnight) and keep only the last 4 (one hour) of snapshots beyond that. The rest are automatically destroyed.

Because of the way the snapshots work, that means I can replicate from the start of the day and any incremental up until the last 15 minute checkpoint, and still have all the changes.

Keeping those 5 snapshots up to date doesn’t make a particular impact on performance, as far as I can tell.

thanks for the post!

When I started checking out MySQL seriously some 3, 4 years ago, among many other things the superb documentation gave me the confidence that this was a product I could rely on.

In short, you guys are doing a great job, and you probably don’t get enough credit for it. Kudos!

With regard to licensing, speaking in terms of “closed source” is a bit silly since it’s documentation, however let’s not dismiss the issue as Debian blah. Those people understand licensing quite well!
The MySQL docs are not GPL, DGPL, creative commons, or anything else OSS licensed. They are fully copyrighted works with no general OSS or other license attached. MySQL allows it to be perused online at dev.mysql.com/doc/ and also downloaded for use. That’s it. No onward distribution or publication is allowed. AFAIK this is not actually described in a license as such, it’s just “allowed” by noting it in a few sentences in the docs themselves.

And thus we must conclude that no, don’t think you can actually include the documentation if you redistribute the MySQL GPL licensed code, as there’s nothing that gives you permission to do so. It would breach the copyright that Sun/MySQL holds on those materials. If Sun/MySQL wishes to be specific about what it wants to allow, and I’m all for that, then it should explicitly give users a license for this that state clearly what is and what is not allowed.

So… thou shalt not FUD, my friend.
Do keep up the excellent work!
Cheers, Arjen.