On Thu, Oct 13, 2005 at 10:53:51AM -0700, Chris Travers wrote:
> Now, what about PgPool as a multimaster sync replication solution? Sure
> it is statement level.... But is there any reason why you cannot have
> multiple PgPool instances running against a number of DB servers?
Well, to begin with, you have a serious race condition:
pgpool begins T1 on M1 and M2.
Someone logs into M2 and does some work in T2.
M1 completes the work of T1.
M2 completes the work of T2.
pgpool issues COMMIT.
M1 replies with the COMMIT.
M2 detects a deadlock when T2 tries to COMMIT.
Now what? There's nothing to prevent this in the system, as near as
I can see, so it's just not bullet proof enough for the cases where
people really, really need only five minutes of down time a year. If
you _really_ needed that, you'd be willing (and able) to pay the
costs. Of course, we can do what we can to make those costs go down.
:-> But they're not that low yet.
Also, there is still (or was last I checked) a limitation on the
number of machines pgpool could address, and there are some stability
and reliability issues we've seen. It's a great piece of code, don't
get me wrong; but it's not stable enough yet to bet millions of
dollars on.
ObNit: ORAC isn't really synchronous; it just looks that way.
> This is multimaster async replication. But it can be further broken
> down into four types:
Sure; I think you could break it even smaller sub-types, if you
worked at it, too. For example, an async system that tolerates
farily brief interruptions in two-way communications is very
different from the one where your sales force (or your Palm) shows up
after a week and dumps a whole bunch of new conflicts on your lap.
This second case is something Slony wouldn't tolerate; but I think a
relatively-high availability would probably work with some multi-way
conflict resolution, if someone were willing to build it. That
wasn't the itch Afilias needed scratching, because of the kinds of
problems we have to solve (to begin with, exactly one person may be
the registrant of record of a domain name at any one time, so
conflict resolution is just not allowed in our problem set: we have
to maintain global uniqueness). But we did have some discussions
about how one might file the corners of the hole to make it square
enough for the peg. I think it's possible, if someone volunteers to
do the work (maybe in a sub-project, maybe as a co-operative
project). I don't have the problem, so I can't justify the staff
time. So if someone _else_ has the problem, maybe s/he can.
A
--
Andrew Sullivan | ajs@xxxxxxxxxxxxxxx
I remember when computers were frustrating because they *did* exactly what
you told them to. That actually seems sort of quaint now.
--J.D. Baldwin
---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
