MySQL Option/Variable changes in the docs

In amongst the other changes I made last week to provide the Reverse Changelog, I’ve also added some additional output to the Options/Variable chapter. Basically, for the OptVars Dynamic Docs, we track when each option/variable had a change, either in the value or when it was introduced, deprecated, etc. We can now output those changes for a given version, either an individual one (for example 5.1.30) or toplevel (5.1). The new changes are documented here:

As always, comments, suggestions welcome.

MySQL University: MySQL and ZFS

I didn’t announce it last week, but I did a MySQL University presentation on using MySQL with the ZFS filesystem. ZFS is the main filesystem for Solaris/OpenSolaris and offers a number of different benefits for people using MySQL, including some improvements to the ease of use, management, and performance of the storage you use with your MySQL database. You can get the presentation, and the recordings of the presentation, from the appropriate MySQL University page: MySQL and ZFS.

Selected MySQL Docs now at

We’ve decided to make a number of our docs available through Sun’s documentation website, in addition to our main documentation site at The documentation uploaded there is only a small selection of the total documentation, and at the moment, it is limited to full documents, such as the reference manuals, MEM docs, NDBAPI Guide and the MySQL Workbench:

The versions on will be updated each day (unlike our versions, which are updated multiple times each day).

Reverse Changelog

One of the pain points of upgrading any software package is knowing which version to upgrade to when the time comes. With software that is frequently updated, like MySQL, choosing a version that provides new features and addresses issues you are aware of, without also being exposed to other issues is an added complexity. This week, I added another new feature to our documentation, spurred on by Baron Schwarz’s idea for a ‘reverse changelog’. As Baron noted, the idea is to report the bugs reported in a specific version, and then provide information about the version in which each bug was fixed, so that you can determine which version you need to choose when upgrading to avoid that bug. You can see the output for 5.1: Bugs Reported and Fixed in 5.1.That page contains every version of 5.1, a list of the bugs known to be reported against that specific version, the bug synopsis/description, and the version in which the bug was known to be fixed. The reported version information is extracted from our bugs database. The bug fixed version is extracted from the changelog information – another part of the dynamic changelog functionality is the ability to find out information like this super easy when generating changelog related output.I’ve done a lot of work over the last couple of years to improve the quality and content of our changelog. Although the basic structure of the changelog hasn’t changed much on the outside, from the inside, I’ve simplified and expanded the content and information that we track, and made the documentation team’s work processes easier to handle too. About 20% of our time in the docs team is tied up in keeping the changelogs up to date with both the changelog content and any relevant changes to the manual, so keeping that time down enables us to focus on the content.On the outside, for our users, we’ve been publishing the enhanced ‘key changes’ information for more than a year now. This uses tags that we add to the changelog entries when we write them, and allow us to pull out the ‘key changes’, that is bugs tagged with Important Change, Incompatible Change, etc. into a single view. Hopefully both the reverse changelog and key changes will be useful to everybody – and I thank (and will thank) Baron for the inspiration for the idea, largely made possible through our dynamic changelog system. For those curious about the dynamic changelog and what it can do, you might also want to check out the Open Bugs for 5.1 list which also uses the information provided by the dynamic changelog to tell you when known bugs are expected to be fixed.If anybody has any further ideas about the sort of information they might want out of the changelog, please feel free to let me know. As a rough guide, pulling out information based on specific tags (for example, all the bugs affecting a particular storage engine, partitioning, or specific platform) are easy to produce, as are changes between specific versions, ranges, or combinations of the above.

MySQL University Needs You!!

MySQL University keeps rolling along. We’ve had some fantastic sessions just recently (not including my own, of course!), such as Lenz’s presentation of backing up MySQL with filesystem snapshots, Allan Packer’s presentation on the optimization of MySQL and, going back a little further, David Van Couvering and Petr Pisl’s talk on using PHP and MySQL within Netbeans. Remember that all of these presentations can be viewed again online if you missed them first time round!We’ve got some good topics coming up, but we ned more!!Got some hot topic that you want to tell the world about? Using MySQL in an interesting way? Got a good MySQL scalability story that you want to tell? Developed a great storage engine? Any and all of these topics are welcome for discussion and presentation at MySQL University. On the other hand, perhaps you’ve seen one of our existing presentations and would like an update or follow-on session that goes deeper, or that enables you to ask more questions. Whatever it is you want to see on MySQL University, let me know here or through the contact form, and get these things scheduled in before the slots all disappear!