Hi,

If by any chance you are at the MySQL user conference in Santa Clara conference center, there are some great possibilities to see MySQL and Solaris Cluster in action.

We have a demo at the exhibition hall, where you can see MySQL with zone cluster and MySQL with SC Geographic Edition.

I will host a birds of a feather at Wednesday 4/22/09 evening in meeting room 205 at 7 pm. The Title is "Configuring MySQL in Open HA Cluster, an Easy Exercise" check out the details here. 

I will give a presentation at Thursday 4/23/09 morning 10:50 in Ballroom G, the title is "Solutions for High Availability …

The release of the MySQL 5.4 contains patches which
increases the scalability of the MySQL Server. I am planning to blog
about those changes in some detail over the next few days. This blog
will give an introduction and show what the overall results we have
achieved are.

The changes we have done in MySQL 5.4 to improve scalability and
the ability to monitor the MySQL Server are:

1) Google SMP patch
2) Google IO patches
3) Update of many antiquated defaults in the MySQL Server
4) New InnoDB Thread Concurrency algorithm
5) Improved Spinloop in InnoDB mutexes and RW-locks
6) A couple of performance fixes backported from 6.0
7) Operating system specific optimisations
8) Ported the Google SMP patch to Solaris x86 and SPARC and work
underway for Windows and Intel compiler as well
9) Introducing DTrace probes in the MySQL Server …

Yes, it's been a long time. Week after week, I had ideas I wanted to share, but no time at all to blog. Priorities are clear: family and work come first, and it's very difficult to keep a balance between the two.

So I left a lot behind. The major project I worked on last summer, MySQL in a virtualised environment and with multiple instances on larger boxes, was part of the material we presented at the MySQL Customer Conference back in October. The results were pretty good and we showed a good level of scalability for real life applications, well beyond the typical sysbench results you can find by googling a bit here and there. I will blog about it at some point, it's just that it takes a lot of time to reorganise all the material to publish and make it understandable.

This week the topic is slightly different. We did it again, we dug into the art of building MySQL binaries and we did it on Solaris 10 for SPARC …

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 …

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 …

I didn’t announce it last week, but I did a MySQL University presentation on using MySQL with the ZFS filesystem. ZFS is the main filesystem for Solaris/OpenSolaris and offers a number of different benefits for people using MySQL, including some improvements to the ease of use, management, and performance of the storage you use with your MySQL database.

You can get the presentation, and the recordings of the presentation, from the appropriate MySQL University page: MySQL and ZFS.