In browsing the BZR tree for lp:mysql-server, I noticed some rather exciting code had been merged into the Innobase code.

You may be aware that InnoDB will do some index dives when opening a table to get some statistics about the indexes that can help the optimiser make good query plans.

The problem being that this is many disk seeks. It means that on server restart, you have to spend a whole bunch of time seeking around the disk reading index pages.

Not any more.

There is now code merged in to store the calculated statistics in a table inside InnoDB so that these index dives don’t have to happen on startup.

Originally, this looked like it was going to make it into InnoDB+. The good news is that it’s now in a public …

In case you haven’t heard yet, I’ve merged in the latest InnoDB from MySQL 5.5.7 into Drizzle. The innobase plugin is now based on InnoDB 1.1.3.

This gets a lot of bug fixes and improvements from 1.1.2 (and on 1.1.1). Enjoy!

The MySQL replication system has always had the replication log (“binlog”) as a separate set of files on disk. Originally, this really didn’t matter as, well, MyISAM wasn’t transactional or crash safe so the binlog didn’t need to be either. If you crashed on a busy write workload, your replication was just going to be hosed anyway.

So then came a time where everybody used InnoDB. Transactional, crash-safe and all the goodies. Then, a bit later, came storing master rpl log position in InnoDB log and XA with the binlog. So a rather long time after MySQL first had replication, you could pull the power cord on the master with a decent amount of certainty that things would be okay when you turned it on again.

I am, of course, totally ignoring the slave state and if it’s safe to do that on slaves.

Using XA to make the binlog and InnoDB consistent does have a cost. That cost is fsync()s. You have to do a lot more of …

By this definition, when someone who doesn't work at the MySQL project distributes a package that is based on MySQL code but differs …

Okay… So I’ve blogged many times before about the Storage Engine API in Drizzle. This API is somewhat inherited from MySQL. We have very much attempted to make it a much cleaner interface. Our goals in making changes include: make it much easier to write and maintain a storage engine, make the upper layer code obviously correct and clear in what it’s doing and being able to more easily introduce optimisations.

I’ve recently added a Storage Engine that is only used in testing: storage_engine_api_tester. I’ve blogged on it producing call graphs (really state transition graphs) before both for Storage Engine and Cursor.

I’ve been expanding the test. My test engine is now a wrapper around a real engine instead of just a fake one. …

Our innobase plugin in Drizzle is now based on Innobase 1.1.1 from MySQL 5.5.5-m3.

This brings all the great new improvements from the Innobase team to Drizzle.

If you want to clear local session status variables this is easy, simply execute FLUSH STATUS.  Unfortunately doing the same for global status variables is not as easy.

That is until now.  In the Drizzle7 beta release 2010-11-08 is a new command: FLUSH GLOBAL STATUS

I created this command to fulfil a Rackspace feature request but it appears this has also been a MySQL feature request in the past.  The implementation would be very different in MySQL since the status variables and sessions work differently, but it would certainly be good to see in a future release, and it appears patches already exist for it.

…

It's entirely possible, given my propensity to swear and rant and declare things to be Web Scale, that folks might get the idea that I do not like our newer NoSQL bretheren. Quite the contrary - I think almost all of them are exciting and well suited to various tasks. My biggest beef is in thinking that a single technology should be square-pegged into every round-hole anyone can find. This holds true for Drizzle and MySQL as well, by the way. Just because I work on Drizzle does not mean I think Drizzle should be the method of data storage for every blessed thing on the face of the planet - that would be silly!

I bring this up because I had my first instance of thinking that Cassandra might be a good choice for a project someone was showing me yesterday. In this case, the project was collecting data about events, but it as the data was events about real-world interactions, the particular information stored about each collected event had the …

I wonder if this comes under “Code Style” or not…

Anyway, Monty and I finished getting Drizzle ready for adding “-Wframe-larger-than=32768″ as a standard compiler flag. This means that no function within the Drizzle source tree can use greater than 32kb stack – it’s a compiler warning – and with -Werror, it means that it’s a build error.

GCC is not perfect at detecting stack usage, but it’s pretty good.

Why have we done this?

Well, there is a little bit of recursion in the server… and we can craft queries to blow a small stack (not so good). On MacOS X, the default thread stack size is only 512kb. This gives not many frames if 32kb stack is a even remotely common.

I found some interesting places to throw a lot of things on the stack too – that would be rather far down on a …

My branch that updates the innobase plugin in Drizzle to be based on innodb_plugin 1.0.9 has been merged. For the next milestone, we’ll probably have 1.0.11 as well.

How’s the progress getting 1.1 and 1.2 in? Pretty good actually. We’ll have it for either this milestone or the next one.

and merging newer innodb into HailDB? It’s going well too, expect more news “soon”.