Re: [PATCHES] replication docs: split single vs. multi-master

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".

> If you split things up so data sets resided on only one
> machine, you are right that would not be replication, but do people do
> that? If so, it is almost another solution.

Yes, as I say: Data Partitioning solves another problem.

>>> And for
>>> multi-master, Oracle RAC is clearly multi master,
>> Yes.
>>
>>> 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. ;-)

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, 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"?).

Regards

Markus