Markus Schiltknecht wrote:
> Hello Bruce,
>
> You wrote:
> > I am still feeling that data partitioning is like master/slave
> > replication because you have to get that read-only copy to the other
> > server.
>
> Yes, that's where replication comes into play. But data partitioning per
> se has nothing to do with replication, has it? You can partition your
> data however you want: among tablespaces, among databases or among
> multiple servers. Data partitioning solves different problems than
> replication. I think it's important to keep them separate. Why do you
> mix-in Slony-I in the Data Partitioning Section? One can use any other
> replication solution to "get that read-only copy to the other server".
Yes, updated.
> >>> and I can see pgpool
> >>> as multi-master, or as several single-master systems, in that they
> >>> operate independently.
> >> Several single-master systems? C'mon! Pgpool simply implements the most
> >> simplistic form of multi-master replication. Just because you can access
> >> the single databases inside the cluster doesn't make it less
> >> Multi-Master, does it?
> >
> > OK, changed to "Multi-Master Replication Using Query Broadcasting".
>
> Good. That reads already better for me. ;-)
Oops, now modified to just "Query Broadcasting".
> As Jim Nasby pointed out in [1], not all solutions are as simplistic as
> pgpool and do not necessarily have the same disadvantages - while using
> the very same algorithm: Query Broadcasting.
>
> I suggest we make sure to clarify that and better point out some of the
> aspects all Multi-Master Replication have in common (see
> replication_doku_4.diff of my patches).
>
> > Added.
> >
> > Added.
>
> (the additions to "Shared Disk Failover")
>
> Good. Short and clear. (Except perhaps: how can I find out if NFS has
> full POSIX behavior? Do we have to go into more detail there? I dunno.)
Uh, I am unclear on that myself. I think NFS3 or NSF4 is OK, but am
unsure.
> > Uh, but the locks are the same on each machine as if it was a single
> > server, while in a cluster, the locks are more intertwined with other
> > things that are happening on the server, no?
>
> Sure.
>
> Maybe you are right and we should better not use the term locking there.
> It seems confusing because it's not clear what a 'lock' is for some
> replication systems (i.e. also Postgres-R, how do you compare it's
> "amount of locks"?).
OK, locks are currently mentioned only for clustering.
URL updated:
http://momjian.us/main/writings/pgsql/sgml/failover.html
-- Bruce Momjian bruce@momjian.us EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +