Short version (aka, Executive Summary)

If you try to run a 32bit program under 64bit Ubuntu, there is a chance you might see this misleading error message:

-bash: ./executable_filename: No such file or directory

What the shell is actually trying to say is "You can't run 32 bit applications here without installing support for 32 applications!".

Longer version

We purchased the Webyog's MONyog MySQL monitoring tool, after some trial version testing in a Windows environment. When trying to run it on one of our Ubuntu servers, I got this:

myuser@myserver:~/MONyog/bin$ ./MONyog-bin
-bash: ./MONyog-bin: No such file or directory

I checked again: the file was there, permissions were okay. Hmm. Why was bash saying the file wasn't there? Here it is! It's not like the error came from the …

I have not been at CeBit for quite a while, but this year I will be there as a regular visitor this Thursday (6th of March). If you would like to meet with me, please send me an email or ping me via IM/Skype! I look forward to walking around the hallways, visiting my new employer's booth and finding out what other Open Source presences and activities there will be.

Here is some of my thoughts on migrating MySQL to Sql Server. It came out of an email discussion. I’d love to hear your thoughts on migrating to a different database platform, not just MySQL to Sql Server.

I actually thought about writing a white paper or even a course on migrating from MySQL to Sql Server, but never got the time to do it. Sometimes a project doing similar things can serve as a launchpad for this endeavour, but that never came along, at least not yet. I am very interested in database interoperability field though. I’ve done MySQL and Oracle admin in the past and have published some MySQL and Oracle stuff in blogs. I have much better technical skills on Sql Server than any other RDBMS platforms, primarily because I’ve worked on it longer.

Here are some of my thoughts. I think most of it applies equally on migration from Oracle, DB2, Sybase, Postgresql, etc., to Sql Server, or the other way around. It …

At $WORK we typically use Redhat Cluster to make MySQL highly available. We have a number of 2-node clusters (active/passive) and it works nicely, for the most part. One thing I find very annoying is RHCS has no notification framework to notify you when a service is relocated to another node (because of failure or otherwise.)

In a perfect world, the only reason MySQL would pass between nodes is for server maintenance, under the control of a human. In reality, crap happens. Redhat Cluster manages all this, but I still want to know that a failover happened (is hardware going bad? did a software bug cause a failure? etc.)

Most monitoring tools weren’t designed to report on a clustered service. I can add a check that connects to MySQL using the cluster-managed IP - but that only tells me if MySQL has failed completely. The failover between nodes generally takes under a minute so it’s easy for that type of monitoring check to miss a …

Today, Sun announced we've closed the acquisition of MySQL - MySQL is now officially a part of Sun! From a dinner meeting back in late November, through some introspection from MySQL's CEO, to a closing today in late February - everyone involved showed a great sense of pace, urgency and excitement. And now, it's off to the races!

Since the announcement, I've seen and heard near universal support for the relationship - most everyone wants to know where we're headed, so here's a quick overview of our initial plans.

Starting today, we're rolling out global programs to raise awareness and adoption of MySQL among more established enterprises - you'll see ads like this (to the right) targeting institutions and independent software/service vendors (ISV's) looking to …

In this blog I'm sharing the results of a series of tests designed to explore the impact of various MySQL and, in particular, InnoDB tunables. Performance engineers from Sun have previously blogged on this subject - the main difference in this case is that these latest tests were based on Linux rather than Solaris.

It's worth noting that MySQL throughput doesn't scale linearly as you add large numbers of CPUs. This hasn't been a big issue to most users, since there are ways of deploying MySQL successfully on systems with only modest CPU counts. Technologies that are readily available and widely deployed include replication, which allows horizontal scale-out using query slaves, and memcached, which is very effective at reducing the load on a MySQL server. That said, scalability is likely to become more important as people increasingly deploy systems with quad-core processors, with the result that even two processor systems will need to …

In this blog I'm sharing the results of a series of tests designed to explore the impact of various MySQL and, in particular, InnoDB tunables. Performance engineers from Sun have previously blogged on this subject - the main difference in this case is that these latest tests were based on Linux rather than Solaris.

It's worth noting that MySQL throughput doesn't scale linearly as you add large numbers of CPUs. This hasn't been a big issue to most users, since there are ways of deploying MySQL successfully on systems with only modest CPU counts. Technologies that are readily available and widely deployed include replication, which allows horizontal scale-out using query slaves, and memcached, which is very effective at reducing the load on a MySQL server. That said, scalability is likely to become more important as people increasingly deploy systems with quad-core processors, with the result that even two processor systems will need to …

In this blog I'm sharing the results of a series of tests designed to explore the impact of various MySQL and, in particular, InnoDB tunables. Performance engineers from Sun have previously blogged on this subject - the main difference in this case is that these latest tests were based on Linux rather than Solaris.

It's worth noting that MySQL throughput doesn't scale linearly as you add large numbers of CPUs. This hasn't been a big issue to most users, since there are ways of deploying MySQL successfully on systems with only modest CPU counts. Technologies that are readily available and widely deployed include replication, which allows horizontal scale-out using query slaves, and memcached, which is very effective at reducing the load on a MySQL server. That said, scalability is likely to become more important as people increasingly deploy systems with quad-core processors, with the result that even two processor systems will need to …

A

I've decided to start replacing L with GL in acronyms where L supposedly stands for Linux.

I'm not a big user of acronyms, because I think they are exclusionist and they obscure, rather than revealing. (This wouldn't matter if I wrote for people who already knew what I meant and agreed with me, but that's a waste of time). However, LAMP is one that I've probably used a few times, without thinking that it is supposed to stand for Linux, Apache, MySQL, and PHP/Perl/Python. In fact, it doesn't refer to Linux, it refers to GNU/Linux. Therefore, it should be GLAMP.

Why does this matter? I try not to say Linux, unless I'm referring to a kernel, because a kernel is not an operating system. I try to be pretty careful about saying GNU/Linux when I'm talking about an operating system. An exception is a recruiting event yesterday at the University of …