Now that installing MySQL in Solaris zones is even officially supported by the MySQL support group (see http://www.mysql.com/about/legal/supportpolicies/policies-06.html#q03), the question is: What is the right way of installing MySQL in a zone. Of course this depends on what you want to achieve. The following description is based on Solaris 10. On Opensolaris this is different (somewhat easier, as there are no more sparse root zones.)
If you run a local zone as a whole root zone, you can easily install MySQL from tarball or the package installer.
If you run a local zone as a sparse root zone, there are different options:
First you cannot use the package installer, as this procedure will copy binaries to /usr/bin. But /usr/bin is inherited from the global zone and write protected. You have to use the tarball installation. …

I have recently been investigating a bew feature of MySQL 6.0 - the "Pool-of-Threads" scheduler. This feature is a fairly significant change to the way MySQL completes tasks given to it by database clients.

To begin with, be advised that the MySQL database is implemented as a single multi-threaded process. The conventional threading model is that there are a number of "internal" threads doing administrative work (including accepting connections from clients wanting to connect to the database), then one thread for each database connection. That thread is responsible for all communication with that database client connection, and performs the bulk of database operations on behalf of the client.

This architecture exists in other RDBMS implementations. Another common implementation is a collection of processes all cooperating via a region of shared memory, usually with semaphores or other synchronization objects located in that shared …

I have recently been investigating a bew feature of MySQL 6.0 - the "Pool-of-Threads" scheduler. This feature is a fairly significant change to the way MySQL completes tasks given to it by database clients.

To begin with, be advised that the MySQL database is implemented as a single multi-threaded process. The conventional threading model is that there are a number of "internal" threads doing administrative work (including accepting connections from clients wanting to connect to the database), then one thread for each database connection. That thread is responsible for all communication with that database client connection, and performs the bulk of database operations on behalf of the client.

This architecture exists in other RDBMS implementations. Another common implementation is a collection of processes all cooperating via a region of shared memory, usually with semaphores or other synchronization objects located in that shared …

I have recently been investigating a bew feature of MySQL 6.0 - the "Pool-of-Threads" scheduler. This feature is a fairly significant change to the way MySQL completes tasks given to it by database clients.

To begin with, be advised that the MySQL database is implemented as a single multi-threaded process. The conventional threading model is that there are a number of "internal" threads doing administrative work (including accepting connections from clients wanting to connect to the database), then one thread for each database connection. That thread is responsible for all communication with that database client connection, and performs the bulk of database operations on behalf of the client.

This architecture exists in other RDBMS implementations. Another common implementation is a collection of processes all cooperating via a region of shared memory, usually with semaphores or other synchronization objects located in that shared …

A little while ago, I was the brave soul tasked with making sure Drizzle was working properly and passing all tests on Solaris and OpenSolaris. Brian recently blogged about some of the advantages of also running on Solaris and the SunStudio compilers - more warnings from the compiler is a good thing. Many kudos goes to Monty Taylor for being the brave soul who fixed most of the compiler warnings (and for us, warnings=errors - so we have to fix them) for the SunStudio compilers before I got to making te tests work.

So, I got to the end of it all and got pointed to an OpenSolaris x86 box where the drizzleslap test was timing out. The timeout for tests is some amazingly long amount of time - 15 minutes. All the drizzle-test-run tests are rather short tests.

To make running the tests quick, I usually LD_PRELOAD …

On early Tuesday morning, I made a quick trip to Paris, France, to attend and speak at the Solutions Linux / Open Source 2009 Conference. I've never been to this conference before and was quite surprised about its size - it's actually the largest Open Source event in France and it reminded me a lot of LinuxTag in Germany. Many well-known vendors (e.g. Sun, Novell, Canonical, Bull, etc.) were exhibiting. The also was a large "DotOrg" section for various Open Source projects and I was very happy to see that LeMUG.fr, the official MySQL User Group of France, had a table there, too! A big Thank You goes to Pascal Borghino, who manned that table on his own most of the time and answered questions about MySQL. I …

Stopping All Servers
All 221 tests were successful.
The servers were restarted 14 times
Spent 1424.921 of 1521 seconds executing testcases

(All tests have passed on OpenSolaris on x86 for a while now).

In the last three updates to this blog, I've tried to set out a clear direction of where Sun's headed. I've talked about our three basic priorities:

1. Technology Adoption
2. Commercial Innovation
3. Efficiently Connecting Adoption and Commercial Opportunity.

I'm hoping you've got a clear picture surrounding the first of these two priorities - how and where we drive software adoption, and focus our commercial efforts.

So now I'd like to talk about the linkages - while also addressing one of our biggest strategic challenges, our scale.

Selling Scale

First, why is scale a challenge for Sun? To be clear, I'm not talking about purchasing scale. As I've said before, we use innovation to drive product profitability, not simply bulk purchasing leverage. The scale to which I'm referring is selling and marketing scale. With Sun's current products, we could be selling to twice …

Simon Phipps, Sun's Chief Open Source Officer, speaks to The Wall Street Journal.

Simon Phipps, Sun's Chief Open Source Officer, speaks to The Wall Street Journal.