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