I took a quick look at MariaDB 10.0 single-treaded performance (simple read-only sysbench). One thing immediately leaps to the eye, and I thought it worthy of mention. It contains an important lesson about the use of synchronisation primitives and in particular "atomic operations" in MariaDB (and MySQL).

I am using the Linux perf tool on this sysbench command:

  sysbench --num-threads=1 --test=oltp --oltp-test-mode=simple --oltp-read-only --oltp-skip-trx

Look at the top offender in the output from perf report:

  1,54%  mysqld  mysqld               [.] set_thread_state_v1

The only thing this does is set a string for SHOW PROCESSLIST (and the like) about what the thread is doing. And we are spending a whopping 1.5% of the total time doing this.

And why? That becomes clear when looking at the disassembly …

Thanks for the comment Rudy, and apologies for not replying sooner.
To be honest, mine was just a mini project to showcase MySQL Cluster on a small solution. As you quite correctly state, Cluster is aimed at storing as much as it can in memory, so, this needs to be taken into account when deploying Cluster on any platform, not just R.Pi ‘architectures’. For a proper solution, it’s always best to evaluate Cluster for our app that, maybe it’s currently using InnoDB, and we want to go 99.999% with it. The MySQL Cluster Evaluation Guide should help us understand whether Cluster is, or isn’t, an appropriate fit. In a R.Pi we’d have to think about exactly what we want to achieve first.

We have always received quite few questions here at Percona Support on how to avoid the dreaded “Too many connections” error, as well as what is the recommended value for max_connections. So, in this article I will try to cover best possible answers to these questions so others can mitigate similar kinds of issues.

My colleague Aurimas wrote a wonderful post some time back about changing max_connections value via GDB when MySQL server is running to get rid of the “Too many connections” error without restarting MySQL. You can check here for details.

By default 151 is the …

MySQL Enterprise Monitor (MEM) is the monitoring solution offered as part of MySQL Enterprise Edition and MySQL Cluster Carrier Grade Edition. In this blog, I will not go into details of the features of MEM, but rather focus on the case where you want to install MEM 3.0 to try it out on your personal desktop or laptop.

A trial version (the full product, but the can only be used for 30 days) is available from Oracle’s Software Delivery Cloud. If you are a MySQL customer, it is recommended that you download MEM from My Oracle Support (MOS).

Once you have downloaded and extracted the installation binaries, you can start the installation. You have the choice between using a GUI, text based, and unattended install. Here I will use …

With the holiday season fast approaching (or is it slow?), data bloggers have already adopted a festive mood, and this Log Buffer edition jubilantly captures and reflects that, and much more.

Oracle:

On December 4, 2013, Oracle will host a customer webcast to acquaint customers with the Oracle SuperCluster M6-32, Oracle’s most powerful engineered system for in-memory Oracle Database performance, Database-as-a-Service and application consolidation.

The ETL logic in BI Apps uses parameters in packages, interfaces, load plans, and knowledge modules (KM) to control the ETL behaviors.

…

When I designed first version of JSON UDFs which was reviewed only internally, I let all functions to validate input and output JSON. But my colleagues told me to remove this functionality, because it makes such functions, as json_search, json_replace or json_contains_key deadly slow if they find the occurrence in the beginning of the long document. And first published version of JSON UDFs: 0.2.0 has not this functionality. What we expected is that users would call json_valid if they want to be 100% sure the document is valid.

But I was not surprised that some users expect JSON functions to work as it was in the first version: validate first, then process. For example, Ammon Sutherland writes: "json_set - according to the documentation a sort of 'INSERT... ON DUPLICATE KEY UPDATE' function which …

Yesterday we had our third Madrid MySQL users group meeting. That was quite interesting.  Thanks go to Juan for his presentation.

We plan the next meeting on January 16th after the New Year is out of the way. If you are interested in MySQL and happen to be in Madrid please consider coming to see us.

More information about the next meeting can be found on the group’s web page. Note: The meeting will be in Spanish. I look forward to seeing you.

While I was working on the MySQL Workbench booth at MySQL Connect this year, an attendee came up and asked what a mutex was and how important it is to them in their function as a DBA.

It’s a good question. The short answer is:

Mutexes are mutually exclusive locks and are designed to prevent concurrent access to resources that in doing so may result in unsafe conditions.

They are required as part of virtually all multi-threaded applications (not just MySQL), and are not something that you can specifically prevent from happening. This is a different concept to row-locks and table locks.

Some examples

If the InnoDB buffer pool is full, internally free space needs to be created in order to be able to load your desired page into memory. What you don’t want, is in between freeing and loading somebody else to take your desired …

I recently conducted a test backup of my “master-slave” setup in my VirtualBox as I was migrating from Percona Server 5.6.12 to version 5.6.13-rel61.0 with Percona XtraBackup v2.2.0 rev. 4885. However, doing the backup on my slave, I encountered this problem:

[04] Compressing and streaming ./test/checksum.ibd
[01] Compressing and streaming ./mysql/slave_master_info.ibd
Assertion "to_read % cursor->page_size == 0" failed at fil_cur.cc:293
innobackupex: Error: The xtrabackup child process has died at /usr/bin/innobackupex line 2641.

This is related to a bug posted by my colleague George  …

You may think that you already know what's the opposite of "DISABLED", but with MySQL Event Scheduler you'll be wrong.

In fact MySQL Event Scheduler may have three different states[1][2]:

DISABLED -  The Event Scheduler thread does not run [1]. In addition, the Event Scheduler state cannot be changed at runtime.
OFF (default) - The Event Scheduler thread does not run [1]. When the Event Scheduler is OFF it can be started by setting the value of event_scheduler to ON.
ON - The Event Scheduler is started; the event scheduler thread runs and executes all scheduled events.

So if you're going to find it in the DISABLED state and instinctively set it to ENABLED you'll end up with a non-starting MySQL daemon.
Be warned and stay safe out there!

[1]: http://dev.mysql.com/doc/refman/5.5/en/events-configuration.html
[2]: When the Event Scheduler is not running does not appear …