[Pgpool-general] 2PC (was: Re: PGPool suggestion)

[Andrew Sullivan]

On Fri, Nov 11, 2005 at 11:24:30PM +0900, Tatsuo Ishii wrote:
> Suppose master succeeds with a transaction while secondary does
> not. You might say "2PC allows master rollback the pre committed
> transaction". However, this already has suggested that either 1)
> contents of master/secondary differ or 2) hardware, network OS or
> whatever has been broken on secondary. In this case it seems more safe
> to detach secondary and goes into the degeration mode than keeping
> replication with inconsistent DB contents or broken hardware.
> 
> What do you think?

Well, it seems there are two goals here, and 2PC allows you to
continue to satisfy one when the other breaks.

If I fully understand the way 2PC works in the implemented version
(and that's an "if"), you can do something like this (ASCII art
ahead):

			h1			h2
BEGIN			X			X
do work			X			X
PREPARE TRANSACTION	X			X
Host 2 dies					X
COMMIT TRANSACTION	X
   OR
ROLLBACK TRANSACTION

When h2 comes back to life, it MUST come back in an identical state
as it was in when it crashed, which means it can just pick up where
it left off.  This is good if you have relatively few changes, and
you can just stop allowing writes during the lost time on h2.  

Think, for example, of a replica that is in place for legal or
auditing reasons.  You could make a very robust system like that by
requiring, absolutely, that every transaction on h1 must be
replicated on h2; and if that can't happen, the whole transaction
fails.  There is certainly an application or two where such control
is exactly what you want.  Whether it's a want worth the cost of
implementing a general intereface for it is a question I haven't
answered yet, though.

A

-- 
Andrew Sullivan  | ajs at crankycanuck.ca
In the future this spectacle of the middle classes shocking the avant-
garde will probably become the textbook definition of Postmodernism. 
                --Brad Holland