Ok. I was completely unclear regarding how I think Slony would fit into
a multimaster async solution with updates.
Andrew Sullivan wrote:
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.
If it is shared disk, is it even really replication?
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.
Well, a disconnected sales force is interesting in that you will almost
certainly have a "star" topology in your replication environment. After
all, your sales force is not replicating the entire sales database onto
their laptops we hope....
I think you could still use Slony as a sort of pre-conflict-resolution
update-log replication solution. Then you could have custom triggers on
your update logs to actually attempt conflict resolution and handle
failure on that area. I.e. anytime you have updates, you are going to
have a replication solution that operates in the following way:
1) Replicates changed data (updatelog)
2) Resolves conflicts
3) Makes changes to authoritative data sets
4) Replicates datasets back.
Stages 1 and 4 could be handled by Slony, while 2 and 3 would require
custom triggers. In essence this is really master/slave that appears
multimaster. You will have tradeoffs here in granularity of conflict
resolution versus performance.
For a smaller number of nodes (maybe one at each branch office, where
you might have a small level of interruption, you could use a mesh
topology, but it uses the same 4 stages up above. Just you will
probably have a separate update log for every other node, and use a
similar solution. Again, you will have a tradeoff between granularity
in conflict resolution and performance.
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.
Why would Slony have to do your conflict resolution at all? Why not
just use it to replicate update logs and data sets, and leave conflict
resolution to custom triggers? Conflict resolution is really going to
be the area where you have individual needs anyway. Slony makes a good
piece of a solution but it is just that, a piece. Because multimaster
async replication is unlikely to be a one-size fits all area, any out of
the box solution will likely be incomplete, unwieldy, or worse.
Maybe a pgfoundry project consisting of sample setups might be useful as
starting points, however.
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.
Well, I want to thank Afilias for such a useful tool. Again, if we all
could make such contributions, we would take over the world in no time
whatsoever..... Again, I see Slony as a very useful piece of a
multimaster async replication solution, but as you point out, Slony
can't handle it by itself. This isn't in my view a question of a square
peg in a round hole, but an issue of a useful piece of a solution.
Best Wishes,
Chris Travers
Metatron Technology Consulting
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@xxxxxxxxxxxxxx so that your
message can get through to the mailing list cleanly
