So I talked to the wonderful JB from O’Reilly who is responsible for all sorts of parts of the conference, and she’s now enabled my presentations on the MySQL Conference Presentations page. While you’re there downloading mine, make sure you go and download some of the others. In particular, you might want to try:
My presentation slides for the Scale Up, Scale Out and High Availability tutorial here at the MySQL Users Conference are now available for download: Scale Up, Scale Out and High Availability: Solutions and CombinationsThese have been on the MySQL Conference website for days now, but for some reason they don’t seem to have been freed yet. To those waiting I’m sorry for the delay in getting these uploaded.
Like most people, and with just over a week to go before the conference, I’m putting the finishing touchs on my various presentations. First up for me, on Monday afternoon, is my tutorial: Scale Up, Scale Out, and High Availability: Solutions and Combinations. What will be doing? Very simply: Looking at every potential solution for maximum scalability and availability for your database environment. If you are attending, be prepared to:
- Expand your mind as we think about scaling up.
- Expand your horizons as we think about scaling out.
- Divide and conquer, as we think about high-availability.
We’re not not hands on in this session – but I will expect you to be brains on!
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.
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.
We’ve decided to make a number of our docs available through Sun’s docs.sun.com documentation website, in addition to our main documentation site at dev.mysql.com/doc. 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 docs.sun.com will be updated each day (unlike our versions, which are updated multiple times each day).
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 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!
We have a MySQL University session later today, featuring me and Trond Norbye (who works on Memcached development). Ostensibly we are talking about some of the tools and environment details of developing on Solaris and OpenSolaris, but with a MySQL focus. I’ve just updated the Forge page with the requisite information and a copy of the slides if you need them. Here’s the abstract:
Developing MySQL on Solaris requires you to install a suitable compiler and other tools, but you may be surprised to know that most of the material is there already, or easy to install if it’s not. But even more so, there is a huge wealth of information that you can get about your application while it’s running, both with and without using more traditional debugging methods. We’ll cover setting up a suitable environment, where to find the things you need, and and how to make use of the process monitoring tools and debugging environment to get the best out of development on Solaris generally, and MySQL specifically.
Please attend if you have any interest in developing on Solaris/OpenSolaris and MySQL. Trond an I will also be on-hand to answer any questions you might have.
As some of you have noticed (and reported) we are having trouble with the CHM builds we do of the various MySQL Reference Manuals. This is something that we are looking into, but the reasons and issues behind it are complex. One of the basic reasons if the sheer complexity and size of the documents are now building – there are thousands of files in a standard HTML build, constituting more than 2,500 pages of material. Unfortunately, the final part of the build process, using Microsoft’s own HTML Help Compiler is something we have no control over, and Microsoft no longer support the product. Sometimes it produces a perfectly fine CHM from the source material. Sometimes, using the exact same material, it produces a build that is corrupt in some way. The CHM building process is automatic – I improved it a couple of years ago to be automated as much as possible using a Windows Powershell script that performs nearly all of the work and verifies the build process. But Microsoft’s tool will report a successful build even if the build actually produces a corrupt CHM file. Identifying a corrupt build is difficult; some of the CHM builds open fine on Windows but not in Linux CHM readers, some the other way round, some that don’t work in anything but which reported a completely fine build. We are looking at different ways of addressing the issues, including creating simplified output (removing some of the more esoteric stuff), and releasing CHMs less often that have been manually checked. I’ll let you know the progress, but until then, we’re going to be highlighting the CHM build issue on the download page.