Tuesday, April 08, 2008

Replication is dead, long live Replication!

Brian Aker has found general agreement with his post: "The Death of Read Replication".

Arjen Lentz says "I think Brian is right...", and Frank Mash confirmed: "what Brian says about replication, caching and memcached is very true".

Just like Video killed the Radio Star it looks like maybe Memcached killed the Replication Hierarchy!

But of course, Brian and others are talking about replication for scaling reads.

In my session on PBXT next week at the conference I will be talking about how we plan to use synchronous replication to produce an HA solution for MySQL at the engine level.

I will also discuss how some flexibility in the PBXT architecture makes it possible to actually scale writes efficiently as mentioned by Arjen in his blog.

So don't miss it:

Inside the PBXT Storage Engine
10:50am - 11:50am Thursday, 04/17/2008
Ballroom G

4 comments:

Anonymous said...

Hi!

Syncronous replication for scaling writes? What is the XA hit for that? If you are transactional that is...

Write through caching is next, memcached is just read through.

Cheers,
-Brian

Paul McCullagh said...

Hi Brian,

Good question! As you noted XA is required for bi-directional replication (and I would want it to be transactional).

Of course it is difficult to say at this stage exactly what the performance will be like. The overhead of XA is something to keep in mind.

In general this is only going to work if I can minimize flushing and the amount of data that is being sent over the network. I think I have found a way to do this.

If I am correct then the main hit for XA will be the network latency. Basically the cost of one round trip.

I'm looking forward to hearing more about the memcached "write through" functionality.

Best regards,

Paul

Arjen Lentz said...

Being XA, two round trips?

Paul McCullagh said...

Yes, I looked at that, and I think I don't have to wait for the Acknowledge of the second message.

So the primary writes a phase 1 message to the log. This is propagated to the secondaries, and the primary waits for OK or abort from the secondaries.

On OK of all it writes a phase 2 commit record to the log. At this point it can acknowledge the commit to the user.

The secondaries will commit when they receive commit, but do not need to Ack this.