Memcached is a simple solution for tough scalability problems. MySQL Cluster is a telco-grade network data store. Both are capable of performance far beyond what a relational database (even as good of one as MySQL) usually delivers. But memcached always relies on some other technology to persistently store data, and while MySQL Cluster can deliver exceptional throughput and response times, making it do so has not always been easy.

So, people have long discussed the idea of putting the two together, and I’ve been lucky enough to spend the past six months working on it.

There are many different ways they might fit together. For instance, memcached could merely be used as a protocol – as a path that gets you to the data in cluster – or it could be a fully functional cache on top of that data. I have tried to leave that decision (and many others) up to you, and build something that can easily be configured to work either way. The …

Drizzle 7 GA has been released, so I wanted to compile and test it on my Mac running OS X 10.6.7.  Since Drizzle 7 is new, Mac binaries are not available yet.  I’ve compiled MySQL from source more times than I can remember, and Drizzle was forked from MySQL, so I expected the build process to be similar and pain-free, and for the most part it was.  I did not use MacPorts or Homebrew for various reasons, mainly because I know that I will compile, tweak and recompile Drizzle often while hacking on it.  Also, the blog post  Drizzle in the Snow is about building Drizzle on Mac OS X, but it’s out of date …

Over last few years I’ve been suggesting more people to disable Query Cache than to enable it. It can cause contention problems as well as stalls and due to coarse invalidation is not as efficient as it could be. These are however mostly due to neglect Query Cache received over almost 10 years, with very little changes done to the core of original implementation which appeared in MySQL 4.0 Query Cache was designed to work with single core systems and relatively small memory amounts, both of which are things of the past.

However, if you think about Core idea of the MySQL Query Cache – it is great. The transparent cache which does not require any extra handling from an application side and which just makes things faster without adding complexity to the application (as memcached does for example). Query Cache is also one of the few cache implementations which I’d call an …

So, the other day I posted the performance benchmarks for the multi-master MariaDB/Galera cluster. Spectacular performance. But some of you may justifiably say:

— Well, we were born into a master/slave world. We, like, adapted to it. We have invested so much brain power to make our applications to work in master/slave environment. What do we do now with all these read/write splitting voodoo Lua scripts and slave lag battling techniques? And master failover... There's a whole industry there. Thousands of jobs!

— But of course! — I say, — Galera likes read/write splitting like the other guy. If you want a node as a slave - just don't use it as a master, simple as that. (Slave lag and master failover will have to go though. Sorry about that.)

Also about a year ago I was so fed up with the expert opinions about how synchronous replication is "slow" (Why "slow"? The word "synchronous" does not even have …

We’ve been busy at The MySQL Council. Giuseppe’s summary does a good job explaining what we’ve been up to.

You can communicate with the MySQL council in several ways including:

• Respond to the MySQL Council Survey.
• Talk to one of the council members. I’ll be in Orlando on Sunday and Monday, and in Santa Clara on Tuesday through Friday. Giuiseppe say’s he’ll be in California then in Florida. Other council members include Sarah Novotny, Sheeri Cabral, Rob Wultsch, and Matt Yonkovit. Any of us would be glad to hear your questions, concerns, or ideas about how to make the …

So, the other day I posted the performance benchmarks for the multi-master MariaDB/Galera cluster. Spectacular performance. But some of you may justifiably say:

— Well, we were born into a master/slave world. We, like, adapted to it. We have invested so much brain power to make our applications to work in master/slave environment. What do we do now with all these read/write splitting voodoo Lua scripts and slave lag battling techniques? And master failover... There's a whole industry there. Thousands of jobs!

— But of course! — I say, — Galera likes read/write splitting like the other guy. If you want a node as a slave - just don't use it as a master, simple as that. (Slave lag and master failover will have to go though. Sorry about that.)

Also about a year ago I was so fed up with the expert opinions about how synchronous replication is "slow" (Why "slow"? The word "synchronous" does not even have 'l' in it!) and …

Rackspace has been busy over the last year, funding both the Drizzle project and the OpenStack project. I've been lucky enough to be involved in both, and I couldn't be more pleased and proud of the stuff that's come from both projects.

What about synergy though?

Well, it turns out that it's pretty easy to use Drizzle as your database for two of the three current main OpenStack components. Glance, the Image Registry and  Nova the Cloud Computing Fabric Controller, both use SQLAlchemy to manage data that needs to go into a database.

There's one prerequisite you need to get up and running, and that's SQLAlchemy 7, which is currently in beta. SQLAlchemy 7 introduces a Drizzle dialect, which tells the ORM how to map properly to Drizzle datatypes and the like. Once you've installed SA7, it's as simple as creating a schema to stick data in and the changing the sql_connection setting in either your glance.conf or your …

I am happy to announce the GA release of Flexviews. I've numbered the release 1.7.0 GA.
There are a small number of bug fixes and enhancements:

• 
  
• Fixes for views which have aggregate functions but no GROUP BY expressions could have had problems during incremental update.
  
• GA support for all aggregate functions except GROUP_CONCAT and AVG(distinct).
  
• The PERCENTILE_XX (ie PERCENTILE_90 for a 90th percentile calculation) is now stable too
  

FlexCDC got a number of fixes and improvements:

• 
  
• TIMESTAMP columns are now properly supported
  
• Now mysqlbinlog errors are detected, and the program exits gracefully
  
• FlexCDC now logs to a log file instead of writing to STDOUT/STDERR
  
• There are new PHP scripts for adding and removing table changelogs …

I am happy to announce the GA release of Flexviews. I've numbered the release 1.7.0 GA.
There are a small number of bug fixes and enhancements:

• 
  
• Fixes for views which have aggregate functions but no GROUP BY expressions could have had problems during incremental update.
  
• GA support for all aggregate functions except GROUP_CONCAT and AVG(distinct).
  
• The PERCENTILE_XX (ie PERCENTILE_90 for a 90th percentile calculation) is now stable too
  

FlexCDC got a number of fixes and improvements:

• 
  
• TIMESTAMP columns are now properly supported
  
• Now mysqlbinlog errors are detected, and the program exits gracefully
  
• FlexCDC now logs to a log file instead of writing to STDOUT/STDERR
  
• There are new PHP scripts for adding and removing table changelogs …

MySQL Cluster was designed for high performance from the very beginning. To achieve high performance one has to understand many aspects of computing. As an example the protocol is very important. In the original design work in 1994 we had a master thesis student build a prototype using a protocol which was based on BER encoding and other standard parts of many telecom protocols. After seeing the code in this prototype which was several thousands of lines of code just to handle the protocol, I realised that this type of protocol will simply cost too much on both the client side as well as on the server side. So this type of prototypes in early design work is extremely useful since it would have been very difficult to change this protocol once we started down the path of developing the Data Server.

Based on this work we instead opted for a protocol where almost everything in the protocol was of fixed size and entirely based on sending …