I have been occupied with conferences/travel, and will be so next week also. But I still wanted to kick off the next another of this thread. I would like to introduce the perspective of what current replication users are missing the most from the current implementation. I found this blog post (by Mats Kindahl) interesting in this respect: http://mysqlmusings.blogspot.com/2007/06/replication-poll-and-our-plans-for.... It describes a poll on http://dev.mysql.com/ on most wanted replication features, with the following top-5 as result: 1. Online check that Master and Slave tables are consistent 2. Multi-source replication: replicating from several masters to one slave 3. Multi-threaded application of data on slave to improve performance 4. Conflict resolution: earlier replicated rows are not applied 5. Semi-synchronous replication: transaction copied to slave before commit To list list I would add: 6. Reliable crash safety/recovery of slaves 7. Facilities to implement simple and robust slave takeover from old master 8. Easy slave provisioning Now, obviously in the current project we cannot do all of these :-). But the idea is to discuss new APIs, and I think it is important to have in mind what important new features we need to implement in the next say 2-5 years. We would want to help/facilitate such development in the API design where possible/relevant. So please add to the above list if you think something is missing. Of the above list, I think point 3 (parallel replication) is particularly important to keep in mind: - It is one of the top limitations mentioned always by "big" users of replication. - It is a complex task, and so will need a lot of time and effort to get working (so the sooner we start the better!) - As far as I can determine, the MySQL replication team is not really working on this. Points 5 seems to be already implemented in 5.5.1. Points 2 and 4 have already been started by the MySQL replication team according to the (old) blog by Mats (not sure of current status though). Point 8 may already be there with things like LVM snapshots or xtrabackup (not sure). --- One thing I notice in this list is that the concept of global transaction ID seems to play into many of them. Certainly 1, 3, 5, 6, 7, and maybe others also. And it was already discussed in this thread also. So I'm thinking that to get more concrete, global transaction ID seems like the place to start. I will send more thoughts on this in follow-up mails, in particular with respect to possibilities for implementing parallel replication. - Kristian.