We use MySQL for a lot of things (and Sybase for quite a few - and the background with Sybase goes back a long way).
But MySQL is still pretty raw compared to Sybase. No nested selects (I really miss that one); no stored procedures; no triggers. But for a lot of things it's way better.
So MySQL 4.1 was recently released, and one of the nice features is that that it supports nested selects. I can use that, and clean up a lot of queries. So I go download it and give it a try. I'm a believer, and can imagine actually buying support for it as it makes its way into the core of our service.
I like MySQL. I really do. I'm planning on using it for all our database needs. And it's been pretty good for us. This is the first real problem I've hit with it in several years of heavy use.
Was it plain sailing? No. I was expecting the odd curveball, but it turned out to be a lot worse than I ever expected. In fact, it's going to be a while before we can use it in anger.
The first problem I hit was that in addition to all the other changes, they've changed the authentication protocol. If I try and use an older client (one of the 4.0.x series) I get:
% /usr/local/mysql/bin/mysql -u root -p Enter password: ERROR 1251: Client does not support authentication protocol requested by server; consider upgrading MySQL client
Great! OK, so I [later] worked out what was causing this, and that there is a way to tell the server to use the old method.
But this is really bad. This is a simple, straightforward, incompatible change, with no migration path. You have to live in one world or the other. The correct way to handle this is to add the client side support to the old version too.
So in order to support the MySQL 4.1 server, I first have to get every version of the client I can find upgraded to 4.1. Because I don't know, really, who's using which clients to talk to which servers. And this includes all the relevant perl modules in all the supported copies of perl. This is a lot of work, and is made even worse by the fact that the version change may introduce a lot of other effects that have to be tested for.
We've been using Solaris x86 in full production service since 1999, and support everything equally (within reason) on Sparc and x86 architectures. However, all the user-facing stuff is on Sparc, so that if I mess up on Sparc people notice, while I can usually get away with it on x86, which is largely compute nodes. This makes the x86 systems ideal testbeds - I can test a real upgrade or new version on those, and then do the same on Sparc later once I'm sure it works.
So I replace the main public version of MySQL (the one in /usr/local) with 4.1.7, and give it a try:
% /usr/local/mysql/bin/mysql -h testserver -u root -p Illegal instruction (core dumped)
Great! So, what sort of file is this?
% file /usr/local/mysql/bin/mysql /usr/local/mysql/bin/mysql: ELF 32-bit LSB executable 80386 Version 1, dynamically linked, stripped
Oh great. They've stripped the binary. Now it's no use to me for any diagnosis. (Note: never strip a production binary. It has no effect on performance and you might save a bit of diskspace but lose a lot of diagnostic capability.)
Fortunately, they haven't fiddled with the libraries, so I can:
% dump -c libmysqlclient.a |more
libmysqlclient.a[libmysql.o]:
**** STRING TABLE INFORMATION ****
...
.stab.indexstr:
Name
<0>
<1> libmysql.c
<12> V=10.0;DBG_GEN=4.14.28;cd;backend;raw;Xa;O;R=Sun C 5.6 2004/06/0
2
<78> /export/home/mysqldev/sol9x86/mysql-4.1.7/libmysql; /opt/SUNWspr
o/prod/bin/cc -DDEFAULT_CHARSET_HOME='"/usr/local/mysql"' -DDATADIR='"/usr/local
/mysql/data"' -DSHAREDIR='"/usr/local/mysql/share/mysql"' -DUNDEF_THREADS_HACK -
DDONT_USE_RAID -I. -I. -I.. -I../include -I../zlib -O -DDBUG_OFF -xO3 -mt -fsimp
le=1 -ftrap=%none -nofstore -xbuiltin=%all -xlibmil -xlibmopt -xtarget=native -D
_FILE_OFFSET_BITS='64' -DBIG_TABLES -DHAVE_RWLOCK_T -c -o libmysql.o libmysql.c
<543>
Yeah, I know it's wrapped. The point is that you can use dump -c to get how a file was compiled (just look for .stab). In this case, we can see it's the Studio 9 compiler, and we can see the flags used.
The one thing that immediately stands out and worries me from this is the -xtarget=native flag. (Probably via the -fast option, based on the other flags.) This is just asking for trouble, because it will completely preclude the binaries from running on an inferior platform.
I've tested this, and it looks like the binaries work fine on Pentium IV machines (like the V60x), but fail on the Pentium III machines (like the LX50 and my old Dells). So a working hypothesis is that it's been built natively for a Pentium IV. But I can't deploy software that only works on half my systems.