I recently released some RAID testing I did using the sysbench testing framework.  In light of the recent attention paid to multi-core CPU scalability, I have been working on some related tests trying to identify sources of contention using that same set of tests.

After effectively turning off every single innodb safety setting (like flush_log_at_trx_commit, checksums, doublewrite, etc.), and not seeing any real performance increase, I started to wonder what was going on.  
Surely my test client server wasn't the problem, it had plenty of idle CPU according to top, right?  Wrong.
I've been able to drive more QPS to my mysql test servers by starting up parallel sysbench tests from multiple test servers, but using (more or less) the same number of total test threads.  

read more

Script To Check If MySQL Master Master Replication Is Working Correctly

This short article explains how you can use a short script to check whether your MySQL master master replication is working as expected or not.

Script To Check If MySQL Master Master Replication Is Working Correctly

This short article explains how you can use a short script to check whether your MySQL master master replication is working as expected or not.

TOTD #9 explained how to configure JDBC connection pooling for Rails application deployed on GlassFish v2. There are several benefits of using using the JDBC connection pools:

• No need to create a new database connection for each Rails instance.
• No need to specify your password in database.yml or create a hack to hide it.
• No garbage collection of connection after each use.

And because of the above mentioned (and other reasons) an improved application performance, scalability and efficiency.
The only way to deploy a Rails application on GlassFish v2 is to create a WAR file using …

Sun Microsystems, Inc. today announced the addition of the leading enterprise resource planning software vendor Stésud to a growing list of customers that have adopted and deployed Sun's open source MySQL™ database and GlassFish™ application server software. This Belgium-based enterprise company joins Australian online travel pioneer Wotif.com and hundreds of other companies that now rely on MySQL and GlassFish as a lower-cost, higher-performance alternative to traditional database and application server software.

I'm thinking about ways to store archival data for the long term and wanted to solicit anyone who's been down this road for some input, advice, warnings, etc.

Background

Essentially I'm dealing with a system where "live" and "recently live" data is stored in a set of replicated MySQL servers and queried in real-time. As time goes on, however, older "expired" data is moved to a smaller set of replicated "archive" servers that also happen to be MySQL.

This is problematic for a few reasons, but rather than be all negative, I'll express what I'm trying to do in the form of some goals.

Goals

There are a few high-level things I'd like this archive to handle based on current and future needs:

1. Be able to store data for the foreseeable future. That means hundreds of millions of records and, ultimately, billions.
2. Fast access to a small …

We gathered together our ideas of MySQL improvements on this page http://www.percona.com/percona-lab/dev-plan.html
and we are going to implement some of them.
My favorite one is - make InnoDB files .ibd (one created with --innodb-file-per-table=1) movable from one server to another, however it is sort of challenging.
Probably next one patch we want to integrate is Google's smp-fix or Yasufumi's rw-locks (we are going to test both before)

On this page http://www.percona.com/percona-lab.html you can find links to our current binaries and patches.

Entry posted by Vadim | …

To achieve linear scalability of MySQL Cluster using the DBT2
benchmark has been a goal of mine for a long time now. Last
week I finally found the last issue that limited the scalability.
As usual when you discovered the issue it was trivial (in this
case it was fixed by inserting 3 0's in the NDB handler code).

We can now achieve ~41k TPM on a 2-node cluster, ~81k on a
4-node cluster and ~159k TPM on a 8-node cluster giving roughly
97% improved performance by doubling number of nodes. So there
is nothing limiting us now from achieving all the way up to
1M TPM except lack of hardware :)

I've learned a lot about what affects scalability and what
affects performance of MySQL Cluster by performing those
experiments and I'll continue writing up those experiences on
my blog here. I have also uploaded a new DBT2 version where I
added a lot of …

Working on query optimizer bugs can be a rather frustrating experience. First, as soon as some query doesn't run as fast it theoretically could people will consider it a bug. On one hand that's great, you get a constant stream of user input, but on the other hand you end up with a whole pile of "bugs" which you can't hope to finish.

What's more frustrating is that even if you manage to create a fix for an optimizer bug, there are chances it won't be allowed into next GA (currently 5.0.70) or approaching-GA (currently 5.1.30) release (GA is our term for "stable" or "release").

The reason behind this is that most optimizer bugfixes cause the optimizer to pick different query plans, and there's no way to guarantee that the fix will be a change for the better for absolutely everyone. Experience shows that it is possible to have a query that hits two optimizer bugs/deficiencies at once in such a way that they cancel each other out, and …

I was wondering for quite a while if MySQLs C-API (libmysqlclient) can really do async queries and where it is lacking support.

Scanning through the source (sql/client.c) you see:

int mysql_real_query(MYSQL *mysql, const char *query, ulong length)
{

  if (mysql_send_query(mysql,query,length))
    return 1;

  return((int) (*mysql->methods->read_query_result)(mysql));
}

Digging a bit deeper you discover that mysql_send_query() and mysql_read_query_result() are public, but undocumented. Well, but that doesn't stop us.

When I talk about async queries I mean:

• being able to issue several queries in parallel without using threads

That is usually what you need in event-driven applications and allows you to create parallel application without having to use too many system resources (memory, threads, ...).

As long as you use …