The UC is closing in fast and there are a number of (potentially) interesting talks around MySQL Cluster.
Personally, I will give two talks (sessions):

• MySQL Cluster 6.4 (7.0) - New Features
  I will talk about ONLINE ADD NODE, and multithreaded data node, and the rest of the things that are new in 7.0. Please note that MySQL Cluster 6.4 changed name to 7.0, but the session title didn't.
  When and Where: Ballroom A at 05:15pm, Tuesday, 04/21/2009
• LDAP for MySQL Cluster- back-ndb
  Together with Howard Chu, CTO of Symas, we will present OpenLDAP for MySQL Cluster. Check out this …

I’ve spent the past couple weeks ripping out the old client library (based on libmysql) from the Drizzle client utilities (drizzle, drizzledump, drizzleadmin, …). I’ve replaced it with new code that uses the new libdrizzle. Brian merged this patch into the trunk yesterday, so we are one step closer to being rid of the old library! It is still used internally within the server, so my next task is ripping it out from there.

This means that the old library is no longer installed, so all new client and application development needs to use the new libdrizzle. It also means libdrizzle is now required to be able to build Drizzle. While I’ve done my best to convert the old utilities, I’m sure I’ve missed a few things. Please report any bugs you find with them. …

I have been benchmarking Waffle Grid using the new Innodb Plugin 1.03 the past couple of days. Let me say the plugin is fast. Which got me thinking, generally when you fix a bottleneck another area becomes a bottleneck… its a vicious cycle really. I figured why not benchmarks several different settings just to see what sort of improvement or detriment we get in Inno. This hopefully will lead to the next place to look for potential performance improvements. For the test I chose a somewhat IO bound setup and a CPU bound setup.

The IO bound setup was a 20W test, 768M buffer pool.
The CPU boud setup was a 20W test, 5GB buffer pool.

I decided to start with the Double Write Buffer. For those who are not familiar with the double write buffer check out the docs or …

There are two LDAP Directory Servers available that supports MySQL Cluster - OpenLDAP (supported and maintained by Symas Corp.) and OpenDS (Sun Microsystems). Both of them have implemented a back-end called back-ndb that talks direclty to the data nodes. This means that they use the NDBAPI directly to access data in the cluster, thus bypassing the MySQL Server.

Using MySQL Cluster as the back-end makes it possible to easily scale out the LDAP layer without using replication between LDAP servers. If you need to have more capacity in the LDAP layer, add another LDAP server (online, no service interruption), if you need more storage capacity, add data nodes (online, no service interruption). This offers incredible scalability. And no single point of failure.

But …

The topic sounds scary, right? Don't be afraid, we just wanted to mention that we introduced a change in the interface, after we released the beta yesterday. Previous examples which use ConnectionMetaData, ResultSetMetaData and ParameterMetaData won't work anymore. They used to use std::auto_ptr to keep the code from leaking.

Spread the word; Just added Kontrollbase to MySQL Forge: http://forge.mysql.com/projects/project.php?id=318

Spread the word; Just added Kontrollbase to MySQL Forge: http://forge.mysql.com/projects/project.php?id=318

Microsoft and TomTom settle patent claims. Alfresco makes progress and shifts its strategy. The Open Cloud Manifesto is published. Support for free software. And more.

Follow 451 CAOS Links live @caostheory

Quietening the patent drums
Cnet’s Ina Fried had the scoop on the news that Microsoft and TomTom had reached a settlement in their patent dispute. The news story was quickly followed by Microsoft’s official statement, as well as a note from the Software Freedom Law Center that the situation is not completely dealt with. Jay Lyman delivered the 451 CAOS …

Check out the ideas from MySQL for Google Summer of Code 2009!

These are specially-selected projects for students who are looking to do some coding in a real, open-source, highly-adopted software environment. 

The learning experience will be tremendous given that MySQL engineers will be mentoring them. 

Some student stipend is provided by the Google Summer of Code. It is intended for students to gain "exposure to real-world software development scenarios and the opportunity for employment in areas related to their academic pursuits."

One of the first steps when addressing a MySQL performance tuning problem is to perform a system audit of the physical hardware resources, then identify any obvious bottlenecks in these resources.

When dealing with CPU, a quick audit should include identifying the number of CPU cores your server has, and the types of these cores. The key file on Linux systems is /proc/cpuinfo.

Number of cores can be found via the command cat /proc/cpuinfo | grep “^processor” | wc -l

You need to look more closely at the file to determine the type of CPU (e.g. below the model name shows Intel(R) Xeon(R) CPU X3220 @ 2.40GHz. The combination of knowing the number of processors (cores) listed and physical id and siblings helps identify how many CPUs and how many cores per CPU exist.

$ cat /proc/cpuinfo
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model …