The MySQL Server 5.7.5 Development Milestone Release, which was published recently, contains some significant changes to the metadata locking (MDL) subsystem and to the usage of the THR_LOCK manager for InnoDB tables. This post provides more information about these changes, which resulted in nice improvements in both scalability and performance.

Sometime during the development cycle of MySQL 5.6 we realized that locks used in the metadata locking subsystem (MDL) implementation can become a scalability bottleneck when many short statements were executed in @autocommit=1 mode against InnoDB tables.

Bug #66473 is a good example (8-table Sysbench POINT_SELECT/InnoDB test). In this particular case the bottleneck was the mutex protecting the MDL_map hash which …

Following my previous post, I got some excellent feedback in the forms of comments, tweets and other chat. In no particular order:

• Commenter Tibi noted that ensuring I’m mounting with noatime, nodiratime and nobarrier should all improve performance.
• Commenter benbradley pointed out a missing flag on some of my sysbench tests which will necessitate re-testing.
• Former co-worker @preston4tw suggests looking at different IO schedulers. For all tests past, I used deadline which seems to be best, but re-testing with noop could be useful.
• Fellow DBA @kormoc encouraged me to try many smaller partitions to limit the number of concurrent fsyncs.

There seem to be …

The EXPLAIN command is one of MySQL’s most useful tools for understanding query performance. When you EXPLAIN a query, MySQL will return the plan created by the query optimizer. It also shows you how that query will be indexed and an estimate of how many rows are processed by that query. From this information, it is easy to see if your queries are taking advantage of table indexes or if you can change them for some extra performance. VividCortex provides a lot of information on query performance, including samples of the queries that are run against your database. Now, those samples will have EXPLAIN data for them too!

So what does the EXPLAIN feature look like in VividCortex? Here’s a screenshot to illustrate:

Those who are familiar with our application will recognize the query-drilldown view. Each of the dots in the scatterplot represents a sample for the selected query, …

Last week I blogged about getting sysbench working with libAttachSQL. This was not only an exercise in performance but also the first real test for libAttachSQL.

Before I had done this testing the most the early Alpha and Beta releases of libAttachSQL had gone through is a few basic queries. So, the first thing I did when I got the sysbench driver working was slap it with 1,000,000 queries. It pretty much exploded instantly on that. Over the course of this release I have probably hit it with over 100,000,000 queries and things run a lot smoother.

This has led to today's release of libAttachSQL 0.5.0. As far as changes go this release has the biggest changelog so …

Taxonomy upgrade extras: migrationsidegradeupgrademysqlmariadbpercona serverconversioncompatibility

This week we did some migrations from MariaDB 10.0 to Percona Server 5.6 at the IT department of a big German bank.

We were perfectly aware that since version 10.0 the MariaDB code base started to diverge slightly away from the MySQL and Percona Server code base which …

Since I recently wrote about both MySQL error 1071 and error 1070 I decided to continue the pattern with a quick note on MySQL error 1069. In case you've never seen it before, this is MySQL error 1069:

ERROR 1069 (42000): Too many keys specified; max 64 keys allowed

I can't think of a valid use case that requires more than 64 indexes on a MySQL table, but it's possible to get this error by inadvertantly adding lots of duplicate indexes to a table. This can happen if you don't explicitly name your indexes.

Read on for examples...

If I try to add the same named …

Different applications may require different level of availability.   This blog is written to provide only the details on Distributed Replicated Block Device (DRBD) with MySQL running in Active-Passive Clustering to allow failover between 2 nodes. 

In many OS clustering technology, Shared Storage is required to allow data to be readable between the clustered nodes.

 
MySQL HA with DRBD is a leading solution to offer

• - An end-to-end, integrated stack of mature and proven open source technologies, fully supported by Oracle;
• Automatic failover and recovery for service continuity;
• Mirroring, via synchronous replication, to ensure failover between nodes without the risk of losing committed transactions;
• Building of HA clusters from commodity hardware, without the requirement for shared-storage.

 

To …

This is the next part of the stories about MySQL 5.7 Performance..

So far, the previous story was about reaching 645K QPS with SQL queries, while in reality it's only a half of the full story ;-) -- because when last year we've reached 500K QPS due a huge improvement on the TRX-list code, the same improvement made a negative impact on the all single-table test workloads..

What happened finally :

• the new code changes dramatically lowered contention on TRX-list (trx_sys mutex)
• which is made MDL related locking much more hot..
• and if one table becomes hot on a workload, MDL lock contention then is hitting its highest level..

So far, it was clear that MDL is needed a fix. Specially seeing that on 8-tables workload we're …

As I mentioned on my last post, where I compared the default configurations options in 5.6 and 5.7, I have been doing some testing for a particular load in several versions of MySQL. What I have been checking is different ways to load a CSV file (the same file I used for testing the compression tools) into MySQL. For those seasoned MySQL DBAs and programmers, you probably know the answer, so you can jump over to my 5.6 versus 5.7 results. However, the first part of this post is dedicated for developers and MySQL beginners that want to know the answer to the title question, in a step-by-step fashion. I must say I also learned something, as I under- and over-estimated some of the effects of certain …

Good news for those wanting to run MariaDB on POWER systems, the latest 10.0 bzr tree (as of a couple of weeks ago) builds and runs well!

I recently pulled the latest MariaDB 10.0 from BZR and built it on a POWER8 system in the lab to run some quick tests. The MariaDB team has done some work on getting MariaDB to run on POWER recently, a bunch of which is based off my work on MySQL on POWER.

There’s obviously still some work in progress going on, but my initial results show performance within around 10% of MySQL, so with a bit of work we will hopefully see MariaDB reach performance parity.

One interesting find was the code to account for thread memory usage uses a single atomic variable: this does not scale and does end up showing up on profiles.

I’ll comment more on the code in a future post, but it looks like we will have MariaDB being functional on POWER in an upcoming release.