Improving replication with multiple storage engines

New MariaDB/MySQL storage engines such as MyRocks and TokuDB have renewed interest in using engines other than InnoDB. This is great, but also presents new challenges. In this article, I will describe work that I am currently finishing, and which addresses one such challenge. For example, the left bar in the figure shows what happens… Continue reading Improving replication with multiple storage engines

No application changes needed: 10 times faster slave with MariaDB 10 parallel replication

Parallel replication is in MariaDB 10.0. I did some benchmarks on the code in 10.0.9. The results are quite good! Here is a graph that shows a 10-times improvement when enabling parallel replication: The graph shows the transaction per second as a function of number of slave worker threads, when the slave is executing events… Continue reading No application changes needed: 10 times faster slave with MariaDB 10 parallel replication

Using MASTER_GTID_WAIT() to avoid stale reads from slaves in replication

I have just implemented MASTER_GTID_WAIT() in MariaDB 10.0. This can be used to give a very elegant solution to the problem of stale reads in replication read-scaleout, without incuring the overheads normally associated with synchronous replication techniques. This idea came up recently in a discussion with Stephane Varoqui, and is similar to the concept of… Continue reading Using MASTER_GTID_WAIT() to avoid stale reads from slaves in replication

More on 40% better single-threaded performance in MariaDB

In my previous post I wrote about how I achived a >40% speedup on sysbench read-only using profile-guided optimisation (PGO). While this is a preliminary result, I though it was so interesting that it deserved early mention. The fact that any benchmark can be improved that much shows clearly that PGO is something worth looking… Continue reading More on 40% better single-threaded performance in MariaDB

40% better single-threaded performance in MariaDB

Continuing my investigation of single-threaded performance in the MariaDB server, I managed to increase throughput of single-threaded read-only sysbench by more than 40% so far: I use read-only sysbench 0.4.12 run like this: sysbench –num-threads=1 –test=oltp –oltp-test-mode=simple –oltp-read-only –oltp-skip-trx run And mysqld is run with minimal options: sql/mysqld –no-defaults –basedir=X –datadir=Y –innodb-buffer-pool-size=128M With modern high-performance… Continue reading 40% better single-threaded performance in MariaDB

MySQL/MariaDB single-threaded performance regressions, and a lesson in thread synchronisation primitives

I took a quick look at MariaDB 10.0 single-threaded 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… Continue reading MySQL/MariaDB single-threaded performance regressions, and a lesson in thread synchronisation primitives

First steps with MariaDB Global Transaction ID

My previous writings were mostly theoretical, so I wanted to give a more practical example, showing the actual state of the current code. I also wanted to show how I have tried to make the feature fit well into the existing replication features, without requiring the user to enable lots of options or understand lots… Continue reading First steps with MariaDB Global Transaction ID

More on global transaction ID in MariaDB

I got some very good comments/questions on my previous post on MariaDB global transaction ID, from Giuseppe and Robert (of Tungsten fame). I thought a follow-up post would be appropriate to answer and further elaborate on the comments, as the points they raise are very important and interesting. (It also gives me the opportunity to… Continue reading More on global transaction ID in MariaDB

Global transaction ID in MariaDB

The main goal of global transaction ID is to make it easy to promote a new master and switch all slaves over to continue replication from the new master. This is currently harder than it could be, since the current replication position for a slave is specified in coordinates that are specific to the current… Continue reading Global transaction ID in MariaDB