Re: Replication
От | Hannu Krosing |
---|---|
Тема | Re: Replication |
Дата | |
Msg-id | 1156342115.2961.51.camel@localhost.localdomain обсуждение исходный текст |
Ответ на | Re: Replication (Markus Schiltknecht <markus@bluegap.ch>) |
Ответы |
Re: Replication
|
Список | pgsql-hackers |
Ü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
В списке pgsql-hackers по дате отправления: