Re: On "multi-master" - Mailing list pgsql-general
From | Andrew Sullivan |
---|---|
Subject | Re: On "multi-master" |
Date | |
Msg-id | 20051013181856.GP16317@phlogiston.dyndns.org Whole thread Raw |
In response to | Limitations of PostgreSQL ("Denis G Dudhia" <denu79@rediffmail.com>) |
Responses |
Re: On "multi-master"
Re: On "multi-master" Re: On "multi-master" |
List | pgsql-general |
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@crankycanuck.ca 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
pgsql-general by date: