Ühel kenal päeval, K, 2006-08-23 kell 13:36, kirjutas Markus
Schiltknecht:
> Hannu Krosing wrote:
> > But if you have very few writes, then there seems no reason to do sync
> > anyway.
>
> I think there is one: high-availability. A standby-server which can
> continue if your primary fails. Of course sync is only needed if you
> absolutely cannot effort loosing any committed transaction.
Yes. I guess that for that an enchanced WAL-shipping would be ok.
Probably one where you require both sync to local disk and copy to
remote (without waiting for sync) to have happened in order to
COMMIT/ROLLBACK successfully.
> >> Another important factor is the amount of conflicting transactions.
> >
> > That too, but just the need to do *any* locking on all nodes will
> > significantly slow down sync replication
>
> If you implement sync replication with locking, yes. But there are
> better ways: the Postgres-R approach does not do network locking, but
> aborts conflicting transactions just before committing. That results in
> much less network traffic (one GCS-message per writing-transaction).
but it still needs to do at least one network roundtrip + any needed
testing on all nodes + WAL sync on all nodes before it can COMMIT, no?
And I'm afraid that GCS serialisation will need more than one roundtrip
or risk being out-of-date.
I'm not saying that Postgres-R (or any other sync replication) is not
doable or even useful. I just can't see right away, how it can scale
very well for any significant write load.
--
----------------
Hannu Krosing
Database Architect
Skype Technologies OÜ
Akadeemia tee 21 F, Tallinn, 12618, Estonia
Skype me: callto:hkrosing
Get Skype for free: http://www.skype.com
