Re: Replication

From: Hannu Krosing <hannu(at)skype(dot)net>
To: Markus Schiltknecht <markus(at)bluegap(dot)ch>
Cc: Fujii Masao <fujii(dot)masao(at)oss(dot)ntt(dot)co(dot)jp>,pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Replication
Date: 2006-08-23 14:08:34
Message-ID: 1156342115.2961.51.camel@localhost.localdomain
Views: Raw Message | Whole Thread | Download mbox
Lists: pgsql-hackers

Ühel kenal päeval, K, 2006-08-23 kell 13:36, kirjutas Markus
> 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:

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Joshua D. Drake 2006-08-23 14:09:05 Re: Some minor changes to pgbench
Previous Message Bruce Momjian 2006-08-23 14:00:57 Re: [HACKERS] COPY view