The future of replication revealed in Istanbul

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 kind of inspiration and encouragement from others on occasion, and I am looking forward to continuing the work after an early flight to Copenhagen tomorrow.

The new interface for transaction coordinator plugins is what particularly interests me at the moment. The immediate benefit of this work is working group commit for transactions with the binary log enabled. But just as interesting (if more subtle), the project is an enabler for several other nice features related to hot backup and recovery. I spent a lot of effort working on the interfaces to the transaction controller and related extensions to the storage engine API, and I think the result is quite solid and a good basis for coming work.

After the transaction coordinator plugin, the next step is an API for event generators that will allow plugins to receive replication events on an equal footing with the built-in MySQL binary log implementation; I will be using this in cooperation with Codership to more tightly integrate their Galera synchronous replication into MariaDB. And long-term, I am hoping to combine all of the pieces to finally start attacking the general problem of parallel execution of events on replication slaves, the solution of which is long overdue.

(The MariaDB replication project page has lots of pointers to more information on the various projects for anyone interested).

Almost too good to be true, out excursion today was blessed with sunshine and mild weather after countless days of rain and storm. There were even rumours of sightings of dolphins jumping again during the SkySQL excursion yesterday. So while lots of hard work remains, all in all, the omens seem all good for the future of replication in MariaDB!


  1. Third party replication

    I’m very much interested in plugins that will get replication events.

    I’d say that for “global transaction id” a monotonically increasing id is much more useful than binary log position.

    How will it work when there is more than one transactional storage engine involved?

    1. Re: Third party replication

      Agree that a monotonically increasing id is what we need.

      With respect to working with multiple transactional storage engines: One aspect is that the work on transaction coordinator and group commit that I am currently wrapping up is to ensure consistent commit order between all engines and binlog. This means that one will not see a transaction committed in one engine/binlog but not another (which would be a problem for global transaction id). Maybe this is what you had in mind?

      1. Re: Third party replication

        So a transaction can only succeed if a) commit succeeds in all engines and b) it is logged into the binlog for all engines, right? Well, at least for engines that support XA.

  2. Аудио-курс от НЛП-Тренера

    [url=]Дизайн внутренних состояний[/url]

Leave a comment

Your email address will not be published. Required fields are marked *