My previouswritings were mostly teoretical, 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
of restrictions before being able to use it.

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 explain more deeply a lot of
interesting design decisions that I left out in the first post
for the sake of brevity and clarity.)

On crash-safe slave

One of the things I really wanted to improve with global
transaction ID is to make the …

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 master,
and it is not trivial to translate them into the corresponding
coordinates on the new master. Global transaction ID solves this
by annotating each event with the global transaction id
which is unique and universal across the whole replication
hierarchy.

This is a tale of the bug lp:798213. The bug report has the initial report,
and a summary of the real problem obtained after detailed
analysis, but it does not describe the processes of getting from
the former to the latter. I thought it would be interesting to
document this, as the analysis of this bug was rather tricky and
contains several good lessons.

Background

The bug first manifested itself as a sporadic failure in one of
our random
query generator tests for replication. We run this test after
all MariaDB pushes in our …

A very good meeting in Istanbul is drawing to an end. People from
Monty Program, Facebook, Galera, Percona, SkySQL, and other parts
of the community are meeting with one foot on the European
continent and another in Asia to discuss all things MariaDB and
MySQL and experience the mystery of the Orient.

At the meeting I had the opportunity to present my plans and visions for the future
development of replication in MariaDB. My talk was very well
received, and I had a lot of good discussions afterwards with
many of the bright people here. Working from home in a virtual
company, it means a lot to get this …

It turns out that the overhead of dynamic linking on Linux amd64
is 2 CPU cycles per cross-module call. I usually take forever to
get to the point in my writing, so I thought I would change this
for once :-)

In MySQL, there has been a historical tendency to favour static
linking, in part because to avoid the overhead (in execution
efficiency) associated with dynamic linking. However, on modern
systems there are also very serious drawbacks when using static
linking.

The particular issue that inspired this article is that I was
working on MWL#74, building a proper shared …

In my work on group commit for MariaDB, I have the following
situation:

A group of threads are going to participate in group commit. This
means that one of the threads, called the group leader,
will run an fsync() for all of them, while the other
threads wait. Once the group leader is done, it needs to wake up
all of the other threads.

The obvious way to do this is to have the group leader call
pthread_cond_broadcast() on a condition that the
other threads are waiting for with pthread_cond_wait():

Working on a new set of replication APIs in MariaDB, I have given
somethought to the generation of replication events on
the master server.

But there is another side of the equation: to apply the generated
events on a slave server. This is something that most replication
setups will need (unless they replicate to non-MySQL/MariaDB
slaves). So it will be good to provide a generic interface for
this, otherwise every binlog-like plugin implementation will have
to re-invent this themselves.

Content reproduced on this site is the property of the respective copyright holders. It is not reviewed in advance by Oracle and does not necessarily represent the opinion of Oracle or any other party.