Date: 2008-05-21 21:33 Subject: Arjen gets interviewed Security: Public

Sam Varghese of iTWire invited me for a broad interview when I was teaching in Melbourne last week, it's now published (MySQL: the Australian connection).

Post A Comment | Add to Memories | Tell a Friend | Link

Date: 2008-05-21 21:46 Subject: Stuff I did not know about... POSIX join command Security: Public

One of the comments to last week's scribble on joins referred to the POSIX join command. What does this mean? There is a commandline tool called 'join' available on most Unix-ish boxes, including Linux and OS X. From my own Mac ("man 1 join"):

NAME
join -- relational database operator

SYNOPSIS
join [-a file_number | -v file_number] [-e string] [-o list] [-t char]
[-1 field] [-2 field] file1 file2

The commenter also mentions this article which explores the command some more with examples.

It's not MySQL, but it looks very useful. Not all data should be in a db, sometimes a textfile is perfectly sensible, and sometimes you just need an operator like this. And it already exists. Coolness.

Post A Comment | Add to Memories | Tell a Friend | Link

Date: 2008-05-21 22:30 Subject: OpenOffice.org MySQL connectivity: update Security: Public

A while ago I wrote about native MySQL connectivy for OpenOffice.org which Georg Richter had spent a lot of time on, but which then got stuck in some licensing foo. That blog entry generated a number of responses from former MySQL colleagues, noting that something was in the works. A bit later Georg himself commented:

Arjen,

sorry, but I didn't find the time to blog about - I had to write some code :-)

The license of the code will be LGPL 3.0 (like OpenOffice) - it still uses libmysql. The code will be available via cvs.openoffice.org pretty soon.

If you're interested in testing some binaries, check out the new preview version at http://forge.mysql.com/wiki/Connector_OpenOffice

/Georg

So that's cool, and everybody please do check it out!

It's still not clear to me how this actually works in terms of licensing, if it still uses libmysql. Ohwell, I guess it doesn't really matter to users of OOo (LGPL+GPL is fine for us) and the most important thing is that it'll be in the main OOo codebase soon. How Sun makes it jive for StarOffice is entirely their problem ;-)

Post A Comment | Add to Memories | Tell a Friend | Link

Date: 2008-05-21 22:50 Subject: A bluetooth headset that actually does what I want Security: Public

When I visited my friend Jonathan Oxer last week, he told me about his bluetooth headset which he'd found on DealsDirect. I excused myself briefly, opened by laptop, and ordered one online ;-)

So, what it is is a stereo bluetooth headset, with built-in microphone. It can pair with multiple devices, not sure what the maximum is but right now it's 3 for me: the included (!) bluetooth transmitter with a headphone jack for iPods, my mobile phone, and my laptop.

The headset knows that a phone is a phone (from Bluetooth profile), and thus a incoming call automatically takes priority. Yes that's right, no awkward switching mess, it just works (as a Mac user, I appreciate that approach). All that for $99 plus a few dollars postage. Bloody brilliant.

For some cases I'd prefer to use a one-ear headset, but let's not be too picky. In the car my phone talks with my GPS as a handsfree, so that's taken care of anyway.

5 Comments | Post A Comment | Add to Memories | Tell a Friend | Link

Date: 2008-05-21 23:13 Subject: snafu with MySQL relay log path - the why and the fix Security: Public

Referred to by Launchpad Bug #119271 and MySQL Bug#28850, MySQL installations get bitten after an upgrade, if they were acting as a replication slave. However, the actually root cause is not an upgrade.

If you simply set up say Ubuntu Feisty, you'll encounter the same problem. If you set up as a slave, the server uses a relay log. In the affected versions, its put under /var/run. That's a serious snafu, because /var/run is generally on tmpfs and a) very small, and b) gets wiped on a restart. Only runtime foo like .pid files should be under /var/run (as per LSB, Linux Standards Base).
Anyway, the "gets wiped on restart" is where new installations get bitten, although the error is of course the same as on an upgrade where the path changes from /var/lib/mysql: the server simply can't find the relay logs it thought it had.
If you have a perfectly running replication slave, shut it down and restart the machine, you'll have broken replication anyway. One of my students encountered this in the MySQL Replication Workshop last week, just after another student had brought up an error they'd spotted in the logs of their production system.

The issue has only recently been resolved in Ubuntu (5.0.51a), upstream (MySQL has it pushed for 5.0.54), and the problem appears to be fairly prolific among the various distros. CentOS also has something on this. From the comments in all of these, it appears that the basic problem is, although simple, not actually that well understood. The MySQL relay logs should NOT be deleted (or vanish through other means) on a restart. That's all. Simple.

So how did it happen? I first thought the prob was restricted to Debian (from which Ubuntu is derived), but the Debian/Ubuntu my.cnf files have not changed and actually don't contain a relay-log entry. The problem originated upstream at MySQL where the default path for the PID file was changed from the datadir to /var/run/mysqld. That in itself was a correct move (again, for LSB compliance), but elsewhere in the code the base path for the relay log got derived from the path of the PID file, and that's where the trouble originates.
The change of the PID default path was not really noticed anywhere, as most distros already put it in /var/run/mysqld through their default my.cnf file. But since none of them explicitly specifies a relay-log path, it gets put where the compiled-in defaults tell it to go. Kaboom.

So, coding error. The path should not have been derived from the PID base, but programmers are human ;-)
I do wonder why MySQL's QA didn't spot this, they're a fairly thorough bunch.

Another thing to note is that if you have an affected version (any distro, or direct from MySQL), the quick fix is to just put some extra lines in your my.cnf:

# We're fixing up the paths for the relay log infrastructure (repl.slaves)
# 2008-05-21 by a r j e n (at) o p e n q u e r y (dot) c o m (dot) a u
# NOTE 1: adapt the filenames to whatever they currently are on disk!
# The filenames may depend on your hostname or distro specifics.
# NOTE 2: If you built your MySQL server from source,
# or if you installed from the binary tarball,
# your data path will be different from /var/lib/mysql,
# such as /usr/local/mysql/data. Check and adapt.
relay-log = /var/lib/mysql/relay-bin
# let's do these too, just in case
relay-log-index = /var/lib/mysql/relay-bin.index
relay-log-info-file = /var/lib/mysql/relay-bin.info

Then your replication slave universe should return to operate within normal parameters. Essentially, it un-breaks replication ;-)

Actually I think that relay-log-info-file probably used the datadir or the binary log base as its default path already, and that would be why the server would think that the relay logs are somewhere when they're not: the relay-log.info file would contain the current active log filename and position. With the log files disappearing.... you understand. But just in case, make it all explicit and thus prevent problems of this nature.

Post A Comment | Add to Memories | Tell a Friend | Link