It's quite a week here! Craig Russell and I will be giving a talk about the NoSQL APIs for MySQL Cluster (mod_ndb, memcached, and ClusterJ) twice: first at Oracle Open World at 9:00 AM on Thursday morning, and then again at Silicon Valley Codecamp on Saturday afternoon. Tomas Ulin's keynote address yesterday morning unveiled some of the goodness in MySQL 5.6 and MySQL Cluster 7.2 (like Batch Key Access, the great optimizer feature from the ill-fated MySQL 6.0 tree).

And last night I dropped by Dave Neilsen's NoSQL Camp, where I saw Andy Twigg ask a very interesting question in a 5-minute lightning talk. Andy simply pointed out that with hard disk drives, random I/O is slow and capacity is cheap -- so of course it makes sense to denormalize your data …

Lots of great energy, events, presentations and receptions going on at Oracle Open World. Two very key receptions are happening Tuesday night. The Solaris Family Reunion reception and the MySQL reception. The Solaris reunion reception info is: http://smartos.eventbrite.com/ The MySQL … Continue reading →

In my last post, we talked about the read/write tradeoff of indexing data structures, and some ways that people augment B-trees in order to get better write performance. We also talked about the significant drawbacks of each method, and I promised to show some more fundamental approaches.

We had two “workload-based” techniques: inserting in sequential order, and using fewer indexes, and two “data structure-based” techniques: a write buffer, and OLAP. Remember, the most common thing people do when faced with an insertion bottleneck is to use fewer indexes, and this kills query performance. So keep in mind that all our work on write-optimization is really work for read-optimization, in that write-optimized indexes are cheap enough that you can keep all the ones you need to get good read performance.

…

Usually my posts are MySQL related though sometimes I will add something that I find that may not be related to MySQL....  like this. Sorry guys at http://planet.mysql.com :)

Here is a cool little NetApp feature to see where all the lovely windows CIFS traffic is going.

The command is 'cifs top' and it needs to have stats capture enabled on the NetApp for it to work. Here it is in action.


nas01b> options cifs.per_client_stats.enable true
nas01b> cifs top
ops/s reads(n, KB/s) writes(n, KB/s) suspect/s IP Name
44 | 6 206 | 0 0 | 0 | 127.0.0.1 IMG01\notreal
44 | 6 192 | 0 0 | 0 | 127.0.0.1 IMG01\notreal
44 | 6 182 | 0 0 | 0 | 127.0.0.1 IMG01\notreal
39 | 5 133 | 0 0 | 0 | 127.0.0.1 IMG01\notreal
nas01> cifs top
ops/s reads(n, KB/s) writes(n, KB/s) suspect/s IP Name
100 | 15 415 | 0 0 | 0 | 127.0.0.1 IMG01\notreal
96 | …

Note to self:

If I have a problem installing Maatkit scripts because maybe Percona server created conflicts with dependencies, here is what I did to solve that:

1. wget http://maatkit.googlecode.com/files/maatkit-7540-1.noarch.rpm
2. yum localinstall --nogpgcheck maatkit-7540-1.noarch.rpm --skip-broken

On point 2, make sure what you install before you say "yes".

Understanding why MySQL chooses a particular join order or why table scan is chosen instead of range scan is often very hard even for experienced MySQL users. Two almost identical queries, differing only in constant values, may produce completely different plans. That's why we're introducing a great new feature in 5.6: Optimizer Tracing. The target users of this feature are developers and MySQL users experienced enough to understand the ins and outs of EXPLAIN.

What Optimizer Tracing is
You may already have guessed this, but optimizer tracing is a printout  of important decisions the MySQL optimizer has done during the process of making the Query Execution Plan.

The trace is presented in JSON format which is easy to read both for humans and others.

Currently, the optimizer trace includes …

Stockholm - October 4th 2011

Severalnines, provider of automation and management software for easily usable, highly available and auto-scalable cloud database platforms, today announces the latest release of its flagship product ClusterControl™ for MySQL Replication.

Introducing ClusterControl™ for MySQL Replication v.1.1.9

ClusterControl™ for MySQL Replication enables customers to Deploy, Manage, Monitor and Scale a clustered database platform based on the standard MySQL Replication.

Developers and DBAs now have access to all of the features of Severalnines' flagship product ClusterControl™ specifically adapted to MySQL Replication.
…

Debian and Ubuntu make use of the !includedir directive at the end of the packaged my.cnf to allow for extending and overriding their default configuration without having to modify the distribution config file.

This is especially nice in combination with configuration tools like puppet as it is usually much easier to add a file to the system than to modify an existing file.

I ran into a small gotcha with this though: the default my.cnf binds mysqld to the localhost TCP interface so that it listens IP 127.0.0.1 only. To make the mysql server reachable from other hosts the bind=127.0.0.1 setting needs to be overwritten.
How to change the binding to a different IP should be obvious, but how to disable an existing binding completely if you want your mysqld to listen on all available interfaces?

The most obvious would be to simply say

bind=

, this does not have any effect …

As you probably know, I have been doing RDBMS work for many years, some 25+ years by now. At Recorded Future I am the database architect, and although an RDBMS is used extensively, MySQL in this case, we are looking at options, and are currently doing more and more work using a NoSQL Solution, probably te most popular one by now, namely MongoDB.

And before you complan: NoSQL is not a good term, but someone with a longer NoSQL background should then find something better, not yours truly. And for all intents and purposes, you know what I am talking about, right?

I plan to post a few MongoDB posts here, how it looks like from an RDBMS dudes (like myself) POV. This is the first installment, but there will be more. I should also point out that I am no expert in NoSQL technologies in general, nor specifically in MongoDB, but I am trying, and our MongoDB setup is large and complex enough to serve as a decent example: We have a …

Note: this article was originally published on http://blogs.innodb.com on Oct 3, 2011 by Jimmy Yang.

In our earlier Labs release, we presented a MySQL NoSQL solution through InnoDB Memcached Daemon Plugin (see earlier Calvin’s and my posts). That earlier release allows the Memcached Plugin directly interacting with InnoDB, completely bypassing MySQL optimizer and QP layers. It differs with another popular MySQL NoSQL solution, HandlerSocket, by skipping even the Handler API layer and directly access the InnoDB through InnoDB APIs. Thus, in theory, it would be simpler and more efficient.

However, there is one major functionality we did not implement in …