I found interesting paper http://citeseer.nj.nec.com/330257.html
"Don't be lazy, be consistent: Postgres-R, A new way to implement Database Replication"
Abstract:
Database designers often point out that eager, update everywhere replication suffers from
high deadlock rates, message overhead and poor response times. In this paper, we show that these
limitations can be circumvented by using a combination of known and novel techniques. Moreover, we
show how the proposed solution can be incorporated into a real database system. The paper discusses
the new protocols and their implementation in PostgreSQL. It also provides experimental results proving that many of
thedangers and limitations of
replication can be avoided by using the appropriate techniques. 1 Introduction Existing replication protocols can be
dividedinto eager and lazy
Regards,
Oleg
On Tue, 20 Mar 2001, Thomas Lockhart wrote:
> > What is the current state-of-the-art WRT replication of any sort ? If anyone
> > has homebrew solutions that they can share, we would welcome tyring too.
>
> There is some code in contrib/rserv for 7.1 which does table
> replication. It has some restrictions, but does implement the basic
> concept. I think a tarball to do the same for 7.0 and earlier is
> available at www.pgsql.com (just Makefile differences).
>
> We are currently working through the issues involved with multi-slave
> replication and the ramifications for failover to (one of) the slaves.
> It looks like the rserv code may assume too much independence between
> slaves and replication sync information, and failover may be
> not-quite-right in those cases.
>
> Will be posting to the list when we know the answer (though
> contributions and inputs are of course always welcome!). afaict changes
> in rserv schema, if necessary, will not be available for 7.1, but we'll
> be posting patches and updating the CVS tree.
>
> btw, it looks like TODO.detail/replication predates the replication
> implementation, and has no real relationship with the implementation.
> There is some thought that WAL/BAR features can help support replication
> at a different level than is done now, but that is work for the future
> afaik.
>
> - Thomas
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
>
Regards, Oleg
_____________________________________________________________
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institute, Moscow University (Russia)
Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/
phone: +007(095)939-16-83, +007(095)939-23-83
