Phew, here we go, this blog post has been long time coming! A few months ago I started toying around with the idea of analyzing the PlanetMySQL public blog feed. It doesn’t take long to extract the data and prepare it for analysis but between lots of work and procrastination this blog post was left unfinished.

It was partly out of pure curiosity and partly the fact that it seemed to me there were less posts than previous years that I decided to trend out the number of posts over the past years and here we go.

The blue line shows the blog posts per month over the past six years and the black line is a polynomial trend line. There are a few points of interest which are visible and I’ll be listing here (to all their understanding):
1. The first thing which struck me negatively is …

I’m a big fan of NoSQL when it comes to remove useless work put on some over loaded SQL box , for solving  write scalability issues but i will try to demonstrate that in most case you can push a MySQL and MariaDB server at the same level in vertical scalability compare to NoSQL solution. 

I found some of the benchmarks not always taking into account the best practice of RDBMS usage,  no persistante connections  (shorten authentification , socket and thread stack allocation), not using prepared statement to cache plans and  limit network usage, using bad primary keys like varchar or big numeric data type.

[From varokism: Using MySQL as a NoSQL: a story for exceeding 450000 qps with MariaDB]

I think the biggest issue so far with HandlerSocket is that most of …

The stats helper monkeys at WordPress.com mulled over how this blog did in 2010, and here’s a high level summary of its overall blog health:

The Blog-Health-o-Meter reads Wow.

Crunchy numbers

A helper monkey made this abstract painting, inspired by your stats.

A Boeing 747-400 passenger jet can hold 416 passengers. This blog was viewed about 11,000 times in 2010. That’s about 26 full 747s.

In 2010, there were 13 new posts, not bad for the first year! There was 1 picture uploaded, taking a total of 5kb.

The busiest day of the year was April 26th with 779 views. The most popular post that day was Oracle starts to monetize Free Software, is it wrong?.

Turns out RethinkDB is a SSD database to watch in 2011. I’ve known about it for a while but it hasn’t really stood out just yet (I don’t know anyone running it in production).

That said, I’m excited by the potential.

What’s really shocking to me, is that while SSD and flash storage is very exciting, it wasn’t as revolutionary in 2010 as I would have liked to have seen.

I’m not sure why this is… there are people running them at scale but not significantly enough to make them a revolution.

RethinkDB is a MySQL data store optimized for solid state drives. Solid-state drives do away with moving parts and are extremely low-latency. Most database stores are designed for traditional hard drives and assume relatively high-latency. RethinkDB aims to allow database developers to take full advantage of the performance benefits of solid-state drives.

[From …

With speaker confirmations going out this week, the MySQL track at COLLABORATE 11 – IOUG Forum is filling up with the folks you expect to hear when you go to a MySQL event. Giuseppe Maxia will be playing in the MySQL sandbox, Matt Yonkovit will outline the 7 Deadly Performance Sins, and we’ll have Kaj Arno presenting a look at the MySQL ecosystem.  Oh, and Morgan Tocker. And Alexander Rubin. AND Bill Karwin. It’s like a real MySQL conference – oh wait, it IS a real MySQL conference! Of course, we owe a huge debt of gratitude to our Track Manager, Sheeri Cabral. (She’s presenting too, btw.)

If you haven’t considered COLLABORATE before, think of it as a way to get the best of all educational opportunities – real users and community heroes, combined with the Oracle technical staff who helped to bring you release 5.5.8. Plus, MySQL community members can use offer code …

An SQL error which was a pain to get to the root of:
ERROR 1444 (HY000): The prepared statement contains a stored routine call that refers to that same statement. It’s not allowed to execute a prepared statement in such a recursive manner

Whist coding mysql reverse reconciliation for Securich (the Security plugin for MySQL) I kept getting the above error! We all learn from experience and I’m definitely not going to forget about this one :).

Having stored routines calling other stored routines in a cascading fashion for four or five levels can get complicated and what I was lazy about came to bite me right back. I copy code from one proc to the other (code re-use) thus end up having same variable names in different procs and prepared statements in cascading stored routines is not a smart idea, hence the above error.

Solution:
Give prepared …

As you are probably aware, PHP 5.3.4 does not compile with MySQL 5.5 GA. The details can be seen in MySQL bug queue. Basically, the problem boils down to incorrect installation of MySQL headers. MySQL 5.5 build system does not install the headers under the include-prefix/mysql directly but instead installs under the include-prefix directory itself. So, when the PHP build system looks for the MySQL headers, it cannot find <mysql/psi/mysql_thread.h> and so forth.

What is the fix?

The MySQL dev team has committed patches to fix this issue in …

The documentation says that we need to run mysql as “root” user for it to be effective. The code also indicates the same thing where it tries to do a getuid call to check if the server is running as root user (sql/mysqld.cc:  if (locked_in_memory && !getuid())). The general rule of thumb is that we don’t want to run mysql or rather any database as root user since that leads to vulnerabilities.

Historically memlock seems to cause issues on some OS flavors where “mlockall” implementation is not stable. This is documented in mysql code with the below warning message.

The "–memlock" argument, which was enabled, uses system calls that are

unreliable and unstable on some operating systems and operating-system

versions (notably, some versions of Linux).  This crash could be due to use

of those buggy OS calls.  You should consider whether you really …

The documentation says that we need to run mysql as “root” user for it to be effective. The code also indicates the same thing where it tries to do a getuid call to check if the server is running as root user (sql/mysqld.cc:  if (locked_in_memory && !getuid())). The general rule of thumb is that we don’t want to run mysql or rather any database as root user since that leads to vulnerabilities.

Historically memlock seems to cause issues on some OS flavors where “mlockall” implementation is not stable. This is documented in mysql code with the below warning message.

The "–memlock" argument, which was enabled, uses system calls that are

unreliable and unstable on some operating systems and operating-system

versions (notably, some versions of Linux).  This crash could be due to use

of those buggy OS calls.  You should consider whether you really …

About me

A word about me first: My name is Daniel Mewes and I just came over to California to work at RethinkDB as an intern for the oncoming months. After having been an undergraduate student of computer science at Saarland University, Germany for the last two years, I am exited to work on an influential real-world project at RethinkDB now. Why RethinkDB? Not only does RethinkDB develop an exciting and novel piece of database technology, RethinkDB also provides the great “startup kind” of work experience.

Software testing

In complex software systems like database management systems, different components have to work together. These components can interact in complex ways, yielding a virtually infinite number of possible states that the overall system can reach. This has consequences for software testing. As bugs in the code might only show up in a small fraction of the possible …