Alvaro Herrera wrote:
> But the confirmation that needs to come is that the WAL changes have
> been applied (fsync'ed), so the performance will be terrible. So bad,
> that I don't think anyone will want to use such a replication system ...
Yeah, that's the big problem of sync, multi-master replication. IMHO the
key to high performance sync, multi-master replication is to minimize
the efforts needed to get that confirmation.
A hard drive has the built-in functionality to confirm what has been
written (and hopefully it does not lie about that). A cluster does not
have this ability. Now, what does it mean to get a confirmation from the
cluster at all? First of all, you have to be sure the cluster has
received your message, then you also need to be sure it can apply your
changes (the so called WriteSet).
Unfortunately 'the cluster' consists of many independent machines. If
you wait for every single machine in the cluster to confirm being able
to apply your WriteSet, you won't get beyond single-machine performance
for writing transactions.
Postgres-R uses a Group Communication System to get very fast
'confirmation' by optimizing the logic a little: like with patches, you
can be sure a WriteSet can be applied if you try to apply it to the same
base. So Postgres-R uses totally ordered communication to ensure all
transactions are processed in the very same order on all nodes. Another
optimization is buried in the depth of the GCS: it only guarantees that
the message you sent _will_be_delivered_. So thanks to the GCS you don't
have to wait for all other nodes, but only for the GCS to confirm that
your message will be delivered on the other nodes. Of course the GCS
also needs to send messages around to be able to confirm that, but GCSes
are designed to do exactly that very efficiently.
I hope to have brought some light to the sync, multi-master replication
problem. Please ask if you have more questions. I propose to continue
that discussion on the Postgres-R mailing list I have set up.
Regards
Markus