This week we talk to Giuseppe Maxia about MySQL Sandbox. Ear Candy is about table_open_cache, Open_tables and Opened_tables, and At the Movies features MariaDB.

MySQL Sandbox
MySQL Sandbox

Examples:
MariaDB slave of a master:

make sandbox mysql-tarball --master
make sandbox mariadb-tarball --slaveof master-port=foo

Exporting:

./my sqldump instancename

Remote mysql sandbox deploy:

deploy remote sandboxes -m MySQLVer -l list,of,servers

Get MySQL Sandbox on Launchpad

read more

Sysbench OLTP, transactions per second

When dealing with high performance, low latency storage devices, such as SSD cards, one finds bottlenecks in new places. This is a story about such a bottle neck and how to work around it.

One unique feature of InnoDB is the double write buffer. This buffer was implemented to recover from half-written pages. This can happen in case of a power failure while InnoDB is writing a page (16KB = 32 sectors) to disk. On reading that page, InnoDB would be able to discover the corruption from the mismatch of the page checksum. However in order to recover, an intact copy of the page would be needed.

The double write buffer provides such a copy. Whenever InnoDB flushes a page to disk, it is first written to the double write buffer. Only when the buffer is safely flushed to disk, InnoDB writes the page to the final destination. When recovering, InnoDB scans the double write buffer and for each …

Following on from my fun post on Where are they now: MySQL Storage Engines, I thought I’d cover the few storage engines that are really just interfaces to a collection of things. In this post, I’m talking about MERGE.

The MERGE engine was basically a multiplexer down to a number of MyISAM tables. They all had to be the same, there was no parallel query execution and it saw fairly limited use. One of the main benefits was that then you could actually put more rows in a MyISAM table than your “files up to 2/4GB” file system allowed. With the advent of partitioning, this really should have instantly gone away and been replaced by it. It wasn’t.

It is another MySQL feature that exists likely due to customer demand at the time. It’s not a complete solution by any means, PARTITIONING is way more complete and …

The Percona Live: MySQL User Conference is just around the corner! Before we begin our trek to San Jose, we want to provide you with one last announcement about our upcoming activities. First of all, as we’ve previously mentioned, Andrew Aksyonoff (Sphinx’s founder) is going to be delivering a Sphinx tutorial on the 22nd of April [...]

A few weekends ago, I started to again look at the code in Drizzle for producing internal temporary tables. Basically, we have a few type of tables:

• Standard
• Temporary (from CREATE TEMPORARY TABLE)
• Temporary (from ALTER TABLE)
• Internal temporary (to help with query execution)

If you’re lucky enough to be creating one of the first three types, you go through an increasingly lovely pile of code that constructs a nice protobuf message about what the table should look like and hands all responsibility over to the storage engine as to how to do that. The basic idea is that Drizzle gets the heck out of the way and lets the storage engine do its thing. This code path looks rather different than what we inherited from MySQL. For a start, we actually have a StorageEngine object rather than just lumping everything into the handler (which we correctly name a Cursor). However… the final …

Until 2.1.1-beta the functions exposed in custom rankers for handling relevancy based on term frequency and Inverse Document Frequency (IDF) did not take field or document lengths into account. In 2.1.1-beta, Sphinx includes functions that take relevance ranking to the next level. New IDF functions mysql> SELECT * FROM myindex WHERE MATCH(‘less_common more_common’) OPTION RANKER= [...]

The MariaDB project is pleased to announce the immediate availability of MariaDB 5.5.30. This is a bug fix release. See the release notes and changelog for details.

Download MariaDB 5.5.30

Release Notes  Changelog  Overview of 5.5

APT and YUM Repository Configuration …

It’s that time of year again. The annual migration of MySQL users will soon begin! In a little more than one month’s time, much of the MySQL ecosystem will be gathered at the Percona Live: MySQL User Conference and, as usual, you can expect an appearance from the Sphinx Team. Stop by booth 302 to meet [...]

Continuing on from my previous posts, MySQL code size over releases and MariaDB code size I’ve decided to also look into some other code branches. I’ve used the same methodology as my previous few posts: sloccount for C and C++ code only.

There are also other branches around in pretty widespread use (if only within a single company). I grabbed the Google, Facebook and Twitter patches and examined them too, along with Percona Server 5.1 and 5.5.

Continuing on from my previous post, MySQL code size over releases.

I wanted to look at the different branches/patch sets of MySQL out there and work out how far from upstream they deviated. I’m just going to compare against whatever upstream version the most easily accessible version is based on (be it 5.0.x, 5.1.x or whatever).

For MariaDB versions, I removed innodb_plugin and replaced it with xtradb for stats purposes as the MariaDB innodb_plugin is essentially the same as upstream and I don’t want to artificially inflate the diff size.

The first three major versions of MariaDB were all based on MySQL 5.1. I used sloccount and only counted C and C++ code.

So, let’s look at some of the MySQL patch sets/branches that are around. Firstly, let’s look at MariaDB: