Hi,
Some body help me regarding postgres replication, Give me some ideas .
Thanks in advance
Regards
J Mageshwaran
** DISCLAIMER **
Information contained and transmitted by this E-MAIL is proprietary to
Sify Limited and is intended for use only by the individual or entity to
Mageshwaran wrote:
Hi,
Some body help me regarding postgres replication, Give me some ideas .
Thanks in advance
Here are some ideas:
lose the idiotic, pointless and inaccurate email addendum, especially
the ads for bollywood etc.
do some research yourself, especially by reading the
Andrew Dunstan wrote:
Mageshwaran wrote:
Hi,
Some body help me regarding postgres replication, Give me some ideas .
Thanks in advance
Here are some ideas:
Tsk, Andrew.
Replication in PostgreSQL is usually served via Point in Time recovery,
Slony (http://www.slony.info) or Mammoth
- only full replication possible
I do not understand that point, if it is trigger based, you
have all the flexibility you need. (only some tables, only some rows,
different rows to different targets ),
(or do you mean not all targets, that could also be achieved with
triggers)
Although
Postgres-R is a synchronous approach, I believe it is the closest to
the goal mentioned above. Here is an abstract of the advantages.
If you only want synchronous replication, why not simply use triggers ?
All you would then need is remote query access and two phase commit,
and
which I believe is what the rserv implementation in contrib currently does
... no?
its funny ... what is in contrib right now was developed in a weekend by
Vadim, put in contrib, yet nobody has either used it *or* seen fit to
submit patches to improve it ... ?
On Tue, 12 Jun 2001, Zeugswetter
which I believe is what the rserv implementation in contrib currently
does
... no?
We tried rserv, PG Link (Joseph Conway), and PosrgreSQL Replicator. All
these projects are trigger based asynchronous replication. They all have
some advantages over the current functionality of Postgres-R
Here are some disadvantages to using a trigger based approach:
1) Triggers simply transfer individual data items when they
are modified, they do not keep track of transactions.
2) The execution of triggers within a database imposes a performance
overhead to that database.
3) Triggers
Hello
I have hacked up a replication layer for Perl code accessing a
database throught the DBI interface. It works pretty well with MySQL
(I can run pre-bender slashcode replicated, haven't tried the more
recent releases).
Potentially this hack should also work with Pg but I haven't tried
yet.
Imho an implementation that opens a separate client connection to the
replication target is only suited for async replication, and for that a
WAL
based solution would probably impose less overhead.
Yes there is significant overhead with opening a connection to a
client, so Postgres-R
I would be very interested in hearing about your experiences with
this...
Well, Eric thinks it works just spiffy. 8-)
Recall is written in C++, and is meant to be extensible. It was
extended for perl and the DBI layer.
Note that this hack for perl is not perfect, especially in the
Here are some disadvantages to using a trigger based approach:
1) Triggers simply transfer individual data items when they
are modified, they do not keep track of transactions.
I don't know about other *async* replication engines but Rserv
keeps track of transactions (if I understood
Here are some disadvantages to using a trigger based approach:
1) Triggers simply transfer individual data items when they
are modified, they do not keep track of transactions.
I don't know about other *async* replication engines but Rserv
keeps track of transactions (if I understood you
[EMAIL PROTECTED] (Reinoud van Leeuwen) writes:
Well as I read back the thread I see 2 different approaches to
replication:
...
I can think of some scenarios where I would definitely want to
*choose* one of the options.
Yes. IIRC, it looks to be possible to support a form of async
We have been researching replication for several months now, and
I have some opinions to share to the community for feedback,
discussion, and/or participation. Our goal is to get a replication
solution for PostgreSQL that will meet most needs of users
and applications alike (mission impossible
On Mon, 11 Jun 2001 19:46:44 GMT, you wrote:
We have been researching replication for several months now, and
I have some opinions to share to the community for feedback,
discussion, and/or participation. Our goal is to get a replication
solution for PostgreSQL that will meet most needs of users
16 matches
Mail list logo
