Re: [Pgreplication-general] converting the DBMirror as peer-to-peer

Started by Bruce Momjianover 21 years ago2 messages

pgman@candle.pha.pa.us

over 21 years ago

Where are we on this? Is it something that can be added to dbmirror as
a patch?

---------------------------------------------------------------------------

merino silva wrote:

Hi all,

The method I've used to convert DBMirror to a
peer-to-peer replicator was two DBMirror instances
with one considered slave of other as the master.

Here, I've stopped the loop back by dropping the
trigger when INSERT, DELETE, UPDATE through the
DBMirror and then creating the trigger again.

The system was tested on the
ManddrakeLinux 9.2
Posgresql 7.3.4
and Perl v5.8.1

A 'LOCK TABLE <table name> IN EXCLUSIVE MODE'
was used before dropping the trigger to prevent
updating the client database, because updates for that
database wont trigger to the remaining one while the
trigger is dropped.

The modified DBMirror.pl is attached with this.

Is this an acceptable solution for peer-to-peer
replication?
What can be go wrong with this approach?

Please reply me with your suggestions.

regards,
merino silva.

__________________________________
Do you Yahoo!?
Get better spam protection with Yahoo! Mail.
http://antispam.yahoo.com/tools

Content-Description: DBMirror.pl

[ Attachment, skipping... ]

_______________________________________________
Pgreplication-general mailing list
Pgreplication-general@gborg.postgresql.org
http://gborg.postgresql.org/mailman/listinfo/pgreplication-general

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Import Notes

Reply to msg id not found: 20040301042312.34273.qmail@web40506.mail.yahoo.com

Noname

ssinger@navtechinc.com

over 21 years ago

In reply to: Bruce Momjian (#1)

On Tue, 20 Apr 2004, Bruce Momjian wrote:

I haven't yet seen the patch, but conceptually I'm conrned about how it
can handle situations like

this sequence

INSERT row X into database A
INSERT row X into database B
DBMIrror from A to B locks table
the mirror will fail.

Where are we on this? Is it something that can be added to dbmirror as
a patch?

---------------------------------------------------------------------------

merino silva wrote:

Hi all,

The method I've used to convert DBMirror to a
peer-to-peer replicator was two DBMirror instances
with one considered slave of other as the master.

Here, I've stopped the loop back by dropping the
trigger when INSERT, DELETE, UPDATE through the
DBMirror and then creating the trigger again.

The system was tested on the
ManddrakeLinux 9.2
Posgresql 7.3.4
and Perl v5.8.1

A 'LOCK TABLE <table name> IN EXCLUSIVE MODE'
was used before dropping the trigger to prevent
updating the client database, because updates for that
database wont trigger to the remaining one while the
trigger is dropped.

The modified DBMirror.pl is attached with this.

Is this an acceptable solution for peer-to-peer
replication?
What can be go wrong with this approach?

Please reply me with your suggestions.

regards,
merino silva.

__________________________________
Do you Yahoo!?
Get better spam protection with Yahoo! Mail.
http://antispam.yahoo.com/tools

Content-Description: DBMirror.pl

[ Attachment, skipping... ]

_______________________________________________
Pgreplication-general mailing list
Pgreplication-general@gborg.postgresql.org
http://gborg.postgresql.org/mailman/listinfo/pgreplication-general

--
Steven Singer ssinger@navtechinc.com
Dispatch Systems Phone: 519-747-1170 ext 282
Navtech Systems Support Inc. AFTN: CYYZXNSX SITA: YYZNSCR
Waterloo, Ontario ARINC: YKFNSCR