Getting Best out of MySQL on Solaris

I’m still working up some good tips and advice on MySQL on Solaris (particularly the T1000, the new x86 based servers like the X4150 and ZFS, amongst other things), but until then I found Getting Best out of MySQL on Solaris while doing some research.With the latest OpenSolaris builds (b79, from memory) we now have MySQL built-in, and I worked with the folks on the OpenSolaris Database team to get some reasonable configurations and defaults into the system. MySQL 5.1 and 64-bit support is currently going through the process and will be a in future build. I’ve also been working with the DTrace people to improve the DTrace support we have in MySQL (documentation will go live this week, I hope). MySQL 6.0.4 will have some basic DTrace probes built-in, but I’ve proposed a patch to extend and improve on that significantly. We’re in the process of updating the documentation and advice on Solaris (and OpenSolaris) installations and layout too, which is itself part of a much larger overhaul of the installation and setup instructions for all platforms.

MySQL Documentation and Debian/Ubuntu

We’ve got a lot of queries recently on the MySQL docs team address about the documentation (particularly man pages) for MySQL on Debian/Ubuntu. The source of the original problem was reported as a Debian bug. The assumption from the reading of the license in this instance is that you are not allowed to distribute MySQL documentation unless you’ve asked first, and that the documentation is not released under the GPL license. The original license was misunderstood in this respect. In fact, the license as originally quoted in that bug does allow you to provide the documentation if you are providing the MySQL software. In addition, regardless of how you interpret the license, all of our documentation, including installable man pages, has been available on You can find online HTML, offline HTML, PDF, CHM and the man pages for all of our reference manuals (on a version by version basis), along with the main HTML/PDF formats for all of the remaining documentation. We have never tried to limit the availability of the documentation (that’s why we provide it in so many formats).However, as soon as this issue was reported on to us by the folks at Debian we agreed with our legal department to put the man pages under a GPL license. This affects only the man pages, but gets round the misunderstanding above by allowing the man pages to be distributed under the same GPL license as the software. Why did we only change our man page license?MySQL documentation is updated and released very often, in fact as oftenas ten times per day. Allowing anyone to create static copies of anarbitrary documentation release would lead to many outdated copies onthe ‘Net. This is bad for users doing Google searches for MySQLdocumentation, and bad for us (we’ve seen complaints about “our” 5.0.0Manual being badly outdated when MySQL 5.1.20 was out). We appreciateanyone mirroring the MySQL Dev Zone which contains all MySQLdocumentation.So where does that leave the man pages in Debian/Ubuntu? I’m pleased to say that the new 5.0.51-1 package for MySQL that has gone into the latest Debian release (actually, in December). That means that MySQL and the corresponding man pages should appear already in the latest Debian “unstable” branch, and the next major Debian release should include everything you need. Thanks to Christian Hammers (Debian) and Norbert Tretkowski (Debian) for their help on getting this all sorted!

Mysterious crashes? – check your temporary directory settings

Just recently I seem to have noticed an increased number of mysterious crashes and terminations of applications. This is generally on brand new systems that I’m setting up, or on existing systems where I’m setting up a new or duplicate account. Initially everything is fine, but then all of a sudden as I start syncing over my files, shell profile and so on applications will stop working. I’ve experienced it in MySQL, and more recently when starting up Gnome on Solaris 10 9/07. Sometimes the problem is obvious, other times it takes me a while to realize what is happening and causing the problem. But in all cases it’s the same problem – my TMPDIR environment variable points to a directory that doesn't exist. That's because for historical reasons (mostly related to HP-UX, bad permissions and global tmp directories) I've always set TMPDIR to a directory within my home directory. It's just a one of those things I've had in my bash profile for as long as I can remember. Probably 12 years or more at least. This can be counterproductive on some systems - on Solaris for example the main /tmp directory is actually mounted on the swap space, which means that RAM will be used if it’s available, which can make a big difference during compilation. But any setting is counterproductive if you point to a directory that doesn’t exist and then have an application that tries to create a temporary file, fails, and then never prints out a useful trace of why it had a problem (yes, I mean you Gnome!). I’ve just reset my TMPDIR in .bash_vars to read:

case $OSTYPE in (solaris*) export set TMPDIR=/tmp/mc;mkdir -m 0700 -p $TMPDIR ;; (*) export set TMPDIR=~/tmp;mkdir -m 0700 -p $TMPDIR ;;esac

Now I explicitly create a directory in a suitable location during startup, so I shouldn’t experience those crashes anymore.

MySQL and DBD::mysql on Mac OS X

I’ve been investigating some recent issues with installations of MySQL on Mac OS X and the Perl DBD::mysql module for accessing MySQL from within Perl through DBI. The problem exists only with binary distributions of MySQL and is related to the installation location of the libraries for the MySQL client that DBD::mysql uses. By default these are installed into /usr/local/mysql/lib, but the dynamic libraries are configured to be located within /usr/local/mysql/lib/mysql. It’s possible for DBD::mysql to build and link correctly, but trying to use the library will fail because it can’t find the library in the latter directory, even though it linked to the library in the former location. To get round this, the easiest method is to create a link within the directory that points to the parent. For example:

$ cd /usr/local/mysql/lib$ ln -s . mysql

That should fix the problem whether you run the commands before the DBD::mysql build or after it.

Major rewrite of C/ODBC completed

One of my first major tasks at MySQL has just been completed – a major rewrite of the Connector/ODBC (C/ODBC) documentation. There were three major focuses for the rewrite:

  1. Bring the documentation up to date. We had a mix of information on the latest release (currently 3.51, but 5.0 is currently in development), but many of the sections didn’t reflect that new version. There is also new information on how to install the driver on Mac OS X.
  2. Restructure the information. This is something I’m doing across the board on the Connectors docs, as I try to re-organize them all into a more coherent, and compatible, structure. For example, I’ve collated all of the tips about using C/ODBC with different applications into their own section, organized by application. I’ve also extended the information; for example we now have a step by step guide to importing data from MySQL into Microsoft Word and Excel through Microsoft Query.
  3. Setting up the document so that I can more easily add and extend the information in there with tips from the community, bug fixes, and of course new releases.

I’ll now be continuing the work with the other Connectors, like Connector/J and Connector/NET.

One worker in one country

A recent article at CNN talks about how MySQL operates. As one of the MySQL team, I can attest that works, but it requires a significant amount of coordination, and lots of online communication through email, IRC, Skype and other methods to keep everbody talking and all the projects working together. The flip side to that process is that we all get involved in different areas, and you tend to be much more aware of what is going on company wide. There is also better cooperation – because we can all get involved we can all provide our experience and expertise to a wide range of problems and projects. Also, because we come from such a wide range of backgrounds and environments, we have a much wider perspective.So not only does remote, and earth-wide staffing work, but it provides us with a level of cooperation that might be more difficult if we all worked in group offices in the same building.