maria-developers team mailing list archive

[Alex Yurchenko <alexey.yurchenko@xxxxxxxxxxxxx>]

Hi,

Kristian, thanks for starting this discussion. I'm glad you mentioned the
need to improve replication APIs. Hereby I will present some points which
we at Codership found to be essential to the success of the project. These
are not technical requirements, but more of a conceptual suggestions
pertaining replication API design. They are based on the work/research we
have done so far with our MySQL/Galera cluster.

1) It is time to drop MASTER/SLAVE mentality. This has nothing to do with
replication per se. For example multi-master Galera cluster is turned into
master-slave simply by directing all writing transactions to a single node.
Without a single change in nodes' configuration, let alone our replication
API. So master-slave is purely a load balancer thing - the node that
receives writes IS the master even if the slaves think otherwise.

2) It is time to drop SYNCHRONOUS/ASYNCHRONOUS mentality. Although Galera
cluster currently supports only synchronous operation, it can be turned
into asynchronous with rather small changes in the code - again without any
changes to API. This is merely a quality of replication engine.

What's bad about this mentalities is that they force one to focus on
peculiarities with a subsequent failure to achieve a general solution that
can satisfy a broader range of requirements.

If you look at the primary purpose of replication (and binlogging), it is
to make redundant copies of data changes as soon as possible. All other
goals like performance scalability, point-in-time recovery and so on are
pending on that primary requirement - that somewhere there is a copy of the
needed information. And how exactly the copy is made should be of no
concern to the server.

So when refactoring replication code and API we suggest to think of
replication as of redundancy service and establish a general API for such
service that can be utilized by different implementations with different
qualities of service. In other words - make a whole replication system a
plugin (like storage engines are), not only some measly filters.

We realize that this may sound too broad of a goal and unattainable in the
short timeframe. However, from our experience it is not that crazy - we
have an example of such API (https://launchpad.net/wsrep). It is not final
yet and may be not suitable for immediate utilization in MariaDB, but still
- a good (and working) example of the interface that is equally suitable
for synchronous and asynchronous replication, binlogging and what not.

Thanks,
Alex

-- 
Alexey Yurchenko,
Codership Oy, www.codership.com
Skype: alexey.yurchenko, Phone: +358-400-516-011