pg.ddx.io pgsql-general@postgresql.org mailing list archive
help / color / mirror / Atom feedReplication
131+ messages / 86 participants
[nested] [flat]
* Replication
@ 1999-04-16 11:44 Natalya S. Makushina <mak@rtsoft.msk.ru>
0 siblings, 0 replies; 131+ messages in thread
From: Natalya S. Makushina @ 1999-04-16 11:44 UTC (permalink / raw)
To: 'pgsql-general@postgresql.org' <rtsoft!postgresql.org!pgsql-general>
Hello all!
Can PostgreSQL have replication?
Any resources about this?
Please help!
Natalya Makushina
E-mail: mak@rtsoft.msk.ru
^ permalink raw reply [nested|flat] 131+ messages in thread
* Replication....
@ 1999-08-24 06:00 =?iso-8859-9?Q?Safa_Pilavc=FD?= <safa.pilavci@rumeli.net>
0 siblings, 0 replies; 131+ messages in thread
From: Safa Pilavcý @ 1999-08-24 06:00 UTC (permalink / raw)
To: pgsql-general
Hello,
Is it possible to do replication through postgresql on Solaris 2.6..?
Can you show me any adress that tells replication on postrgres..?
Thanks..
Safa Pilavcý
Rumeli Telekom A.Þ
Tel : (90) 212 288 78 50
Fax : (90) 212 274 87 21
safa.pilavci@rumeli.net
^ permalink raw reply [nested|flat] 131+ messages in thread
* Re: replication
@ 1999-11-16 16:24 Aaron J. Seigo <aaron@gtv.ca>
0 siblings, 1 reply; 131+ messages in thread
From: Aaron J. Seigo @ 1999-11-16 16:24 UTC (permalink / raw)
To: Manuel Cabido <manny@tinago.msuiit.edu.ph>; pgsql-general@hub.org; +Cc: pgsql-general-digest@hub.org
hi...
> I would like to inquire if with PostgreSQL 6.5.3.x I can put the same
> database on two or more different Linux server such that each update will
> be replicated on all database backends...
>
this is on the to-do list under "Exotic Features". it seems to be one of the
more asked about features that doesn't exist at the moment on the General list.
unfortunately, it isn't a trivial project so it won't happen over night...
right now, you can jury rig your own system up using network file systems,
periodic updates of local filesystems, etc... this is limited in
usefulness...
true replication does not exist (ala Oracle or MSJet)... yet.
--
Aaron J. Seigo
Sys Admin
^ permalink raw reply [nested|flat] 131+ messages in thread
* Re: [GENERAL] Re: replication
@ 1999-11-16 17:21 Jeff Hoffmann <jeff@propertykey.com>
parent: Aaron J. Seigo <aaron@gtv.ca>
0 siblings, 1 reply; 131+ messages in thread
From: Jeff Hoffmann @ 1999-11-16 17:21 UTC (permalink / raw)
To: ; +Cc: pgsql-general@hub.org; pgsql-general-digest@hub.org
"Aaron J. Seigo" wrote:
> > I would like to inquire if with PostgreSQL 6.5.3.x I can put the same
> > database on two or more different Linux server such that each update will
> > be replicated on all database backends...
>
> right now, you can jury rig your own system up using network file systems,
> periodic updates of local filesystems, etc... this is limited in
> usefulness...
my favorite hack is to wrap the c/c++ api so you can set up a group of
mirror database connections and then calling the wrapped functions will
call the original function on each of the mirror database connections.
i've really never thought of it as something that should be part of the
library, though, since that's pretty easy to implement in the
application.
^ permalink raw reply [nested|flat] 131+ messages in thread
* Re: [GENERAL] Re: replication
@ 1999-11-16 18:54 Aaron J. Seigo <aaron@gtv.ca>
parent: Jeff Hoffmann <jeff@propertykey.com>
0 siblings, 1 reply; 131+ messages in thread
From: Aaron J. Seigo @ 1999-11-16 18:54 UTC (permalink / raw)
To: Jeff Hoffmann <jeff@propertykey.com>; +Cc: pgsql-general@hub.org
hi...
> my favorite hack is to wrap the c/c++ api so you can set up a group of
> mirror database connections and then calling the wrapped functions will
> call the original function on each of the mirror database connections.
> i've really never thought of it as something that should be part of the
> library, though, since that's pretty easy to implement in the
> application.
very cool... but i too agree that this shouldn't necessarily be in the
libraries...
this needs to be in the back end... otherwise, if you have multiple people
performing updates on different replicated servers, how can you guarentee
concurancy? how do you manage the differences between read-only and updateable
replicants? (this can be done using your wrapper method, but quickly gets
clumsy)
also, it would make maintaining replication simpler if it were part of the
back end process... and not prone to some app that goes around your wrapped lib
and defeats the replication scheme altogether... imo, it should be part of the
transaction system.... =)
--
Aaron J. Seigo
Sys Admin
^ permalink raw reply [nested|flat] 131+ messages in thread
* Re: [GENERAL] Re: replication
@ 1999-11-16 19:33 Jeff Hoffmann <jeff@propertykey.com>
parent: Aaron J. Seigo <aaron@gtv.ca>
0 siblings, 0 replies; 131+ messages in thread
From: Jeff Hoffmann @ 1999-11-16 19:33 UTC (permalink / raw)
To: Aaron J. Seigo <aaron@gtv.ca>; pgsql-general@hub.org
"Aaron J. Seigo" wrote:
> this needs to be in the back end... otherwise, if you have multiple people
> performing updates on different replicated servers, how can you guarentee
> concurancy? how do you manage the differences between read-only and updateable
> replicants? (this can be done using your wrapper method, but quickly gets
> clumsy)
yeah it can get clumsy, but fortunately updates are pretty rare in my
case (and usually only performed by one person) so i don't really worry
about those issues, but i should. the only safety issue i use is
starting a transaction for each connection, perform the action on all of
the databases, and then commit the transaction on each. it's not bad
unless one of the commits fails and the others don't, then i have to
retry the failed ones & hope it works. i don't know how to fix it if i
had to give up on one of the transactions for a mirror. again, not
perfect, but it works pretty well for me & my simpler cases.
^ permalink raw reply [nested|flat] 131+ messages in thread
* Re: [GENERAL] Re: replication
@ 1999-11-16 20:41 Richard Welsh <rwelsh@OneStepInternet.com>
0 siblings, 1 reply; 131+ messages in thread
From: Richard Welsh @ 1999-11-16 20:41 UTC (permalink / raw)
To: pgsql-general@hub.org
Is it possible to log the transactions ( as complete statements ) on one
database then process the logged transactions on the second database at
intervals to keep it up to date?
RDW.
-----Original Message-----
From: Jeff Hoffmann <jeff@propertykey.com>
To: Aaron J. Seigo <aaron@gtv.ca>; pgsql-general@hub.org
<pgsql-general@hub.org>
Date: November 16, 1999 2:28 PM
Subject: Re: [GENERAL] Re: replication
>"Aaron J. Seigo" wrote:
>
>> this needs to be in the back end... otherwise, if you have multiple
people
>> performing updates on different replicated servers, how can you guarentee
>> concurancy? how do you manage the differences between read-only and
updateable
>> replicants? (this can be done using your wrapper method, but quickly gets
>> clumsy)
>
>yeah it can get clumsy, but fortunately updates are pretty rare in my
>case (and usually only performed by one person) so i don't really worry
>about those issues, but i should. the only safety issue i use is
>starting a transaction for each connection, perform the action on all of
>the databases, and then commit the transaction on each. it's not bad
>unless one of the commits fails and the others don't, then i have to
>retry the failed ones & hope it works. i don't know how to fix it if i
>had to give up on one of the transactions for a mirror. again, not
>perfect, but it works pretty well for me & my simpler cases.
>
>************
>
>
^ permalink raw reply [nested|flat] 131+ messages in thread
* Re: [GENERAL] Re: replication
@ 1999-11-16 22:15 Aaron J. Seigo <aaron@gtv.ca>
parent: Richard Welsh <rwelsh@OneStepInternet.com>
0 siblings, 0 replies; 131+ messages in thread
From: Aaron J. Seigo @ 1999-11-16 22:15 UTC (permalink / raw)
To: Richard Welsh <rwelsh@OneStepInternet.com>; pgsql-general@hub.org
hi...
> Is it possible to log the transactions ( as complete statements ) on one
> database then process the logged transactions on the second database at
> intervals to keep it up to date?
>
transaction logging is already done on disk in pg_log, however you can't count
on it being correct (esp as pgsql moves towards things such as WAL) as there
will be things in memory that aren't necessarily on disk... this leaves us with
no better a solution than doing it some other way...
the best place for this would be in the transaction handler of pgsql itself.
where a transaction completed on a Master server would cause the same updates
on all Replicants... this would do it for read-only database replication...
under this sort of system, you could only update one database, but all
databases would show the updates (MS Jet works this way? *tries to remember*)...
past that, you could then modify transactions to check not just for
transactions locally, but for transactions on any other given database
installation(s)... global locking, in other words...
this works as long as you can reach all your hosts all the time... if you
can't... then you either get you entire replication setup hung (which would be
pointless) ... or ... you keep revision #s on each row/field that are kept
locally should other Masters not be reachable by design or accident (i believe
this is how Oracle does it.. revision #s)... and once communication is
restored, then the systems sort out the revisions amongst themselves, asking
for user intervention on deadlocks. this would allow multiple Masters, multiple
Replicants and downtimes between them all. this is very tricky and probably the
last piece of the puzzle that would/should be tackled...
looking through the source there are a few promising places to start... (this
should probaly be on the hackers list now.. heh.. *shrug*)
acess/transam - the transaction manager... the commit functionality would need
to be altered to do updates across replicated systems...
storage/lmgr - lock manager... would need to be made aware of other lock tables
that may not be local.. possibly an interface to allow remote checking of lock
tables... a read-only node would always see a write lock on its own tables...
perhaps it would be rerouted to the Master for writing.
utils/time - checks the timliness of data due to transactions... could be
extended eventually to provide, along with the lock manager, concurency between
multiple masters? additional logging information would also be required to
pull this one off (assuming a network connection that isn't up 100% of the
time)...
then there is the point of where you would define the Master/Replicant
relationships within the database(s) itself.. e.g. would it be another system
table to keep track of Masters/Replicants and rules for their operations?
anyways, this is just the thoughts that come to mind... no real detail here,
nor any sense if this would be The Right Way to do it... however, my guess
would be to say that these places in the source would be where to start
looking...
word from those in the know?
--
Aaron J. Seigo
Sys Admin
^ permalink raw reply [nested|flat] 131+ messages in thread
* REPLICATION
@ 1999-12-08 08:44 neil d. quiogue <neil@email.com.ph>
0 siblings, 0 replies; 131+ messages in thread
From: neil d. quiogue @ 1999-12-08 08:44 UTC (permalink / raw)
To: pgsql-general
Greetings,
Last February 1999, there had been some interesting discussions on data
replication. What is the current update on this? Is there a replication
agent in the making? Or is there a separate module/application that is
open source/free?
Any help would be great.
Regards,
Neil D. Quiogue
^ permalink raw reply [nested|flat] 131+ messages in thread
* replication
@ 2000-04-05 20:48 Jenifer Pepling <jpepling@freei.com>
0 siblings, 0 replies; 131+ messages in thread
From: Jenifer Pepling @ 2000-04-05 20:48 UTC (permalink / raw)
To: 'pgman@candle.pha.pa.us' <pgman@candle.pha.pa.us>
Can postgres handle replication? In Oracle there is the ability to
do snapshots and have these snapshots on other machines stay up todate
due to the snapshot refreshes.
Are there any replication or distributed database pieces to postgres?
than you so much for your response before hand.
Jenifer Pepling
^ permalink raw reply [nested|flat] 131+ messages in thread
* Replication
@ 2000-07-11 01:55 XWorkers <xworkers@bangla.net>
0 siblings, 0 replies; 131+ messages in thread
From: XWorkers @ 2000-07-11 01:55 UTC (permalink / raw)
To: Postgre Admin <pgsql-admin@postgresql.org>; pgsql-general
Hellow everyone,
I am facing a problem using postgresql. How replication can be performed
for postgres databases?
TIA.
^ permalink raw reply [nested|flat] 131+ messages in thread
* replication
@ 2000-09-21 12:52 Adam Lang <aalang@rutgersinsurance.com>
0 siblings, 4 replies; 131+ messages in thread
From: Adam Lang @ 2000-09-21 12:52 UTC (permalink / raw)
To: pgsql-general
Are there any type of replication features in postgresql 7.0?
I would like it where two databases have the same structure, but say at
midnight every night Database 1 synchs up database 2.
Granted, I could always write code to do that, but it wouldn't be very
sophisticated. (If I coded it, would do something like find rows in table
1 which aren't in the second database, append them database two, same with
the second table, etc.)
Adam Lang
Systems Engineer
Rutgers Casualty Insurance Company
^ permalink raw reply [nested|flat] 131+ messages in thread
* Re: replication
@ 2000-09-21 13:14 Karel Zak <zakkr@zf.jcu.cz>
parent: Adam Lang <aalang@rutgersinsurance.com>
3 siblings, 0 replies; 131+ messages in thread
From: Karel Zak @ 2000-09-21 13:14 UTC (permalink / raw)
To: Adam Lang <aalang@rutgersinsurance.com>; +Cc: pgsql-general
On Thu, 21 Sep 2000, Adam Lang wrote:
> Are there any type of replication features in postgresql 7.0?
Not exist some standard solution for PG for DB replication ...
Maybe in a far future (via some WAL logs?).
Karel
^ permalink raw reply [nested|flat] 131+ messages in thread
* Re: replication
@ 2000-09-21 13:34 Daryl Chance <dchance@valuedata.net>
parent: Adam Lang <aalang@rutgersinsurance.com>
3 siblings, 1 reply; 131+ messages in thread
From: Daryl Chance @ 2000-09-21 13:34 UTC (permalink / raw)
To: pgsql-general
Could this possibly be done using triggers? I'm new to
postgres, but I know on a project I was doing using oracle
the dba could setup triggers to run on the OnInsert() (not
sure what it's actually called in oracle...). Do maybe
on the "OnInsert" of table foo you could do:
Insert into foo@remotesite1 ....
Is this possible in postgres? I'm looking at using postgres
for the next version of my SW and if replication isn't in,
I'm gonna need something like this :).
btw, remotesite could be setup in what oracle referred to
as "tnsnames.ora". It was a file that had a list of
hosts, ports and the database name so that you wouldn't
have to know all that info to connect to an oracle database,
just what you named it, your username and your password.
Thanks,
--------------------------------------------------------
| Daryl Chance | I have made this letter longer then |
| Valuedata, LLC | usual because I lacked the time to |
| Memphis, TN | make it shorter. -- Blaise Pascal |
--------------------------------------------------------
----- Original Message -----
From: "Adam Lang" <aalang@rutgersinsurance.com>
To: "PGSQL General" <pgsql-general@postgresql.org>
Sent: Thursday, September 21, 2000 7:52 AM
Subject: [GENERAL] replication
> Are there any type of replication features in postgresql 7.0?
>
> I would like it where two databases have the same structure, but say at
> midnight every night Database 1 synchs up database 2.
>
> Granted, I could always write code to do that, but it wouldn't be very
> sophisticated. (If I coded it, would do something like find rows in
table
> 1 which aren't in the second database, append them database two, same with
> the second table, etc.)
>
> Adam Lang
> Systems Engineer
> Rutgers Casualty Insurance Company
>
>
^ permalink raw reply [nested|flat] 131+ messages in thread
* Re: replication
@ 2000-09-21 14:18 Poul L. Christiansen <poulc@cs.auc.dk>
parent: Adam Lang <aalang@rutgersinsurance.com>
3 siblings, 0 replies; 131+ messages in thread
From: Poul L. Christiansen @ 2000-09-21 14:18 UTC (permalink / raw)
To: Adam Lang <aalang@rutgersinsurance.com>; +Cc: pgsql-general
Adam Lang wrote:
>
> Are there any type of replication features in postgresql 7.0?
>
> I would like it where two databases have the same structure, but say at
> midnight every night Database 1 synchs up database 2.
>
> Granted, I could always write code to do that, but it wouldn't be very
> sophisticated. (If I coded it, would do something like find rows in table
> 1 which aren't in the second database, append them database two, same with
> the second table, etc.)
And you would also have to check which records have been modified and
replicate them.
You are not the first person to ask for this feature and it is on the
TODO list:
http://www.postgresql.org/docs/pgsql/doc/TODO.detail/replication
but it is categorized under "exotic features", so I don't know when
we'll see it implemented :(
But I think www.psql.com are working on replication right now.
Poul L. Christiansen
>
> Adam Lang
> Systems Engineer
> Rutgers Casualty Insurance Company
^ permalink raw reply [nested|flat] 131+ messages in thread
* Re: replication
@ 2000-09-21 16:59 Stephan Szabo <sszabo@megazone23.bigpanda.com>
parent: Daryl Chance <dchance@valuedata.net>
0 siblings, 1 reply; 131+ messages in thread
From: Stephan Szabo @ 2000-09-21 16:59 UTC (permalink / raw)
To: Daryl Chance <dchance@valuedata.net>; +Cc: pgsql-general
On Thu, 21 Sep 2000, Daryl Chance wrote:
> Could this possibly be done using triggers? I'm new to
> postgres, but I know on a project I was doing using oracle
> the dba could setup triggers to run on the OnInsert() (not
> sure what it's actually called in oracle...). Do maybe
> on the "OnInsert" of table foo you could do:
>
> Insert into foo@remotesite1 ....
>
> Is this possible in postgres? I'm looking at using postgres
> for the next version of my SW and if replication isn't in,
> I'm gonna need something like this :).
You could probably write a C trigger that would propogate
changes, except that there are still problems. What do you
do when you roll back the transaction? Currently, there
aren't triggers for transaction start and end. Triggers that
do stuff outside the database right now are a bad idea unless
you have some other mechanism to determine whether something
was really supposed to be done. It could be done, but isn't
trivial.
^ permalink raw reply [nested|flat] 131+ messages in thread
* Fw: replication
@ 2000-09-21 17:41 Adam Lang <aalang@rutgersinsurance.com>
0 siblings, 0 replies; 131+ messages in thread
From: Adam Lang @ 2000-09-21 17:41 UTC (permalink / raw)
To: pgsql-general
Adam Lang
Systems Engineer
Rutgers Casualty Insurance Company
----- Original Message -----
From: "Adam Lang" <aalang@rutgersinsurance.com>
To: "Stephan Szabo" <sszabo@megazone23.bigpanda.com>
Sent: Thursday, September 21, 2000 1:41 PM
Subject: Re: [GENERAL] replication
> Plus, I don't want to replicate on a per insert/update basis. I would
like
> to do it as a large batch during off hours.
>
> Adam Lang
> Systems Engineer
> Rutgers Casualty Insurance Company
> ----- Original Message -----
> From: "Stephan Szabo" <sszabo@megazone23.bigpanda.com>
> To: "Daryl Chance" <dchance@valuedata.net>
> Cc: <pgsql-general@postgresql.org>
> Sent: Thursday, September 21, 2000 12:59 PM
> Subject: Re: [GENERAL] replication
>
>
> > On Thu, 21 Sep 2000, Daryl Chance wrote:
> >
> > > Could this possibly be done using triggers? I'm new to
> > > postgres, but I know on a project I was doing using oracle
> > > the dba could setup triggers to run on the OnInsert() (not
> > > sure what it's actually called in oracle...). Do maybe
> > > on the "OnInsert" of table foo you could do:
> > >
> > > Insert into foo@remotesite1 ....
> > >
> > > Is this possible in postgres? I'm looking at using postgres
> > > for the next version of my SW and if replication isn't in,
> > > I'm gonna need something like this :).
> >
> > You could probably write a C trigger that would propogate
> > changes, except that there are still problems. What do you
> > do when you roll back the transaction? Currently, there
> > aren't triggers for transaction start and end. Triggers that
> > do stuff outside the database right now are a bad idea unless
> > you have some other mechanism to determine whether something
> > was really supposed to be done. It could be done, but isn't
> > trivial.
>
^ permalink raw reply [nested|flat] 131+ messages in thread
* Re: replication
@ 2000-09-21 17:42 Adam Lang <aalang@rutgersinsurance.com>
parent: Stephan Szabo <sszabo@megazone23.bigpanda.com>
0 siblings, 1 reply; 131+ messages in thread
From: Adam Lang @ 2000-09-21 17:42 UTC (permalink / raw)
To: Stephan Szabo <sszabo@megazone23.bigpanda.com>; Daryl Chance <dchance@valuedata.net>; +Cc: pgsql-general
Well, if I end up needing to do something with it, I'll get back to the list
on ideas/solutions I encountered and see about potential pitfalls.
Adam Lang
Systems Engineer
Rutgers Casualty Insurance Company
----- Original Message -----
From: "Stephan Szabo" <sszabo@megazone23.bigpanda.com>
To: "Daryl Chance" <dchance@valuedata.net>
Cc: <pgsql-general@postgresql.org>
Sent: Thursday, September 21, 2000 12:59 PM
Subject: Re: [GENERAL] replication
> On Thu, 21 Sep 2000, Daryl Chance wrote:
>
> > Could this possibly be done using triggers? I'm new to
> > postgres, but I know on a project I was doing using oracle
> > the dba could setup triggers to run on the OnInsert() (not
> > sure what it's actually called in oracle...). Do maybe
> > on the "OnInsert" of table foo you could do:
> >
> > Insert into foo@remotesite1 ....
> >
> > Is this possible in postgres? I'm looking at using postgres
> > for the next version of my SW and if replication isn't in,
> > I'm gonna need something like this :).
>
> You could probably write a C trigger that would propogate
> changes, except that there are still problems. What do you
> do when you roll back the transaction? Currently, there
> aren't triggers for transaction start and end. Triggers that
> do stuff outside the database right now are a bad idea unless
> you have some other mechanism to determine whether something
> was really supposed to be done. It could be done, but isn't
> trivial.
^ permalink raw reply [nested|flat] 131+ messages in thread
* Re: replication
@ 2000-09-21 18:43 Adam Lang <aalang@rutgersinsurance.com>
parent: Rob Hutton <rhutton@istmanagement.com>
0 siblings, 0 replies; 131+ messages in thread
From: Adam Lang @ 2000-09-21 18:43 UTC (permalink / raw)
To: ; +Cc: pgsql-general
Well, this is the situation. A client has a database application currently
running on Access (which multiple people share over a network). They want
to make data accessible via the internet. So, what I was thinking was keep
the production database at their location, convert it to postgresql, and
make a replacement application for them to do their work. Then, host their
webserver remotely and have another database there. The main location has a
DSL connection. I figured then that once a day, three times a day
(whatever) the main database synchs up the remote one. (The remote database
will only be used by PHP to extract data, no modifications).
The point of this is that no matter what the main location will always be
able to get their work done while still being able to host their website
offsite.
If there was only a single database at either end, the whole setup is
susceptible to a telecomm link going down and cutting something off.
Adam Lang
Systems Engineer
Rutgers Casualty Insurance Company
----- Original Message -----
From: "Rob Hutton" <rhutton@istmanagement.com>
To: "Adam Lang" <aalang@rutgersinsurance.com>; "Stephan Szabo"
<sszabo@megazone23.bigpanda.com>; "Daryl Chance" <dchance@valuedata.net>
Cc: <pgsql-general@postgresql.org>
Sent: Thursday, September 21, 2000 3:19 PM
Subject: RE: [GENERAL] replication
> I asked a similar question earlier in the week and got no response. If
> there is transaction logging, then it is fairly easy to implement syncing,
> even real time, the only question is to play back the log every x amount
of
> time on the remote db. The tricky part is two fold.
>
> First, you have to maintain a table of all of the remote DBs that are
> syncing and the last two send and receive timestamps, and whether the last
> was successful. If not, then at the next sync time, you have to replay
the
> logs again back to the previous time that was successful. Then you have
to
> have a process that cleans up all of the transactions that are previous to
> the most recent successful sync.
>
> The second part is collision resolution. That is, what happens when an
> edit is made to a DB at both ends in between the sync period. Most of the
> time the later timestamp wins, but what happens if that effects business
> rules, range limitations, etc. For instance, if b must be between a and
c,
> and b and c are lowered on one end, and on the other b is raised above the
> new setting for c, how is this resolved. You end up writing a rules
engine
> for this stuff...
>
> Rob
>
> > -----Original Message-----
> > From: pgsql-general-owner@hub.org [mailto:pgsql-general-owner@hub.org]On
> > Behalf Of Adam Lang
> > Sent: Thursday, September 21, 2000 12:42 PM
> > To: Stephan Szabo; Daryl Chance
> > Cc: pgsql-general@postgresql.org
> > Subject: Re: [GENERAL] replication
> >
> >
> > Well, if I end up needing to do something with it, I'll get back
> > to the list
> > on ideas/solutions I encountered and see about potential pitfalls.
> >
> > Adam Lang
> > Systems Engineer
> > Rutgers Casualty Insurance Company
> > ----- Original Message -----
> > From: "Stephan Szabo" <sszabo@megazone23.bigpanda.com>
> > To: "Daryl Chance" <dchance@valuedata.net>
> > Cc: <pgsql-general@postgresql.org>
> > Sent: Thursday, September 21, 2000 12:59 PM
> > Subject: Re: [GENERAL] replication
> >
> >
> > > On Thu, 21 Sep 2000, Daryl Chance wrote:
> > >
> > > > Could this possibly be done using triggers? I'm new to
> > > > postgres, but I know on a project I was doing using oracle
> > > > the dba could setup triggers to run on the OnInsert() (not
> > > > sure what it's actually called in oracle...). Do maybe
> > > > on the "OnInsert" of table foo you could do:
> > > >
> > > > Insert into foo@remotesite1 ....
> > > >
> > > > Is this possible in postgres? I'm looking at using postgres
> > > > for the next version of my SW and if replication isn't in,
> > > > I'm gonna need something like this :).
> > >
> > > You could probably write a C trigger that would propogate
> > > changes, except that there are still problems. What do you
> > > do when you roll back the transaction? Currently, there
> > > aren't triggers for transaction start and end. Triggers that
> > > do stuff outside the database right now are a bad idea unless
> > > you have some other mechanism to determine whether something
> > > was really supposed to be done. It could be done, but isn't
> > > trivial.
> >
> >
^ permalink raw reply [nested|flat] 131+ messages in thread
* RE: replication
@ 2000-09-21 19:19 Rob Hutton <rhutton@istmanagement.com>
parent: Adam Lang <aalang@rutgersinsurance.com>
0 siblings, 1 reply; 131+ messages in thread
From: Rob Hutton @ 2000-09-21 19:19 UTC (permalink / raw)
To: Adam Lang <aalang@rutgersinsurance.com>; Stephan Szabo <sszabo@megazone23.bigpanda.com>; Daryl Chance <dchance@valuedata.net>; +Cc: pgsql-general
I asked a similar question earlier in the week and got no response. If
there is transaction logging, then it is fairly easy to implement syncing,
even real time, the only question is to play back the log every x amount of
time on the remote db. The tricky part is two fold.
First, you have to maintain a table of all of the remote DBs that are
syncing and the last two send and receive timestamps, and whether the last
was successful. If not, then at the next sync time, you have to replay the
logs again back to the previous time that was successful. Then you have to
have a process that cleans up all of the transactions that are previous to
the most recent successful sync.
The second part is collision resolution. That is, what happens when an
edit is made to a DB at both ends in between the sync period. Most of the
time the later timestamp wins, but what happens if that effects business
rules, range limitations, etc. For instance, if b must be between a and c,
and b and c are lowered on one end, and on the other b is raised above the
new setting for c, how is this resolved. You end up writing a rules engine
for this stuff...
Rob
> -----Original Message-----
> From: pgsql-general-owner@hub.org [mailto:pgsql-general-owner@hub.org]On
> Behalf Of Adam Lang
> Sent: Thursday, September 21, 2000 12:42 PM
> To: Stephan Szabo; Daryl Chance
> Cc: pgsql-general@postgresql.org
> Subject: Re: [GENERAL] replication
>
>
> Well, if I end up needing to do something with it, I'll get back
> to the list
> on ideas/solutions I encountered and see about potential pitfalls.
>
> Adam Lang
> Systems Engineer
> Rutgers Casualty Insurance Company
> ----- Original Message -----
> From: "Stephan Szabo" <sszabo@megazone23.bigpanda.com>
> To: "Daryl Chance" <dchance@valuedata.net>
> Cc: <pgsql-general@postgresql.org>
> Sent: Thursday, September 21, 2000 12:59 PM
> Subject: Re: [GENERAL] replication
>
>
> > On Thu, 21 Sep 2000, Daryl Chance wrote:
> >
> > > Could this possibly be done using triggers? I'm new to
> > > postgres, but I know on a project I was doing using oracle
> > > the dba could setup triggers to run on the OnInsert() (not
> > > sure what it's actually called in oracle...). Do maybe
> > > on the "OnInsert" of table foo you could do:
> > >
> > > Insert into foo@remotesite1 ....
> > >
> > > Is this possible in postgres? I'm looking at using postgres
> > > for the next version of my SW and if replication isn't in,
> > > I'm gonna need something like this :).
> >
> > You could probably write a C trigger that would propogate
> > changes, except that there are still problems. What do you
> > do when you roll back the transaction? Currently, there
> > aren't triggers for transaction start and end. Triggers that
> > do stuff outside the database right now are a bad idea unless
> > you have some other mechanism to determine whether something
> > was really supposed to be done. It could be done, but isn't
> > trivial.
>
>
^ permalink raw reply [nested|flat] 131+ messages in thread
* Re: replication
@ 2000-09-21 20:17 Adam Lang <aalang@rutgersinsurance.com>
0 siblings, 1 reply; 131+ messages in thread
From: Adam Lang @ 2000-09-21 20:17 UTC (permalink / raw)
To: ; +Cc: pgsql-general
That is not the situation though. The reason I want to have to databases is
to have one at the site that actual production is going to be worked on, and
then a replicated database at a remote location where the webserver is.
As for the interface, they use Access forms, which I'll just write a new VB
app using ODBC to replace.
Adam Lang
Systems Engineer
Rutgers Casualty Insurance Company
----- Original Message -----
From: "Len Morgan" <len-morgan@crcom.net>
To: "Adam Lang" <aalang@rutgersinsurance.com>
Sent: Thursday, September 21, 2000 2:52 PM
Subject: Re: [GENERAL] replication
> There is another approach that I have used: Convert all of the tables in
the
> current Access system to Postgres tables and then use ODBC links in the
> current program instead of internal tables. This way you only have one
> database, no need to replicate and it's much more "live". If you give the
> tables in Postgres the same names they have in access, you won't have to
> change any of the forms/queries/reports, etc.
>
> Just my 2 cent's worth.
>
> Len Morgan
>
>
> -----Original Message-----
> From: Adam Lang <aalang@rutgersinsurance.com>
> Cc: pgsql-general@postgresql.org <pgsql-general@postgresql.org>
> Date: Thursday, September 21, 2000 1:43 PM
> Subject: Re: [GENERAL] replication
>
>
> >Well, this is the situation. A client has a database application
currently
> >running on Access (which multiple people share over a network). They
want
> >to make data accessible via the internet. So, what I was thinking was
keep
> >the production database at their location, convert it to postgresql, and
> >make a replacement application for them to do their work. Then, host
their
> >webserver remotely and have another database there. The main location has
a
> >DSL connection. I figured then that once a day, three times a day
> >(whatever) the main database synchs up the remote one. (The remote
database
> >will only be used by PHP to extract data, no modifications).
> >
> >The point of this is that no matter what the main location will always be
> >able to get their work done while still being able to host their website
> >offsite.
> >
> >If there was only a single database at either end, the whole setup is
> >susceptible to a telecomm link going down and cutting something off.
> >
> >Adam Lang
> >Systems Engineer
> >Rutgers Casualty Insurance Company
> >----- Original Message -----
> >From: "Rob Hutton" <rhutton@istmanagement.com>
> >To: "Adam Lang" <aalang@rutgersinsurance.com>; "Stephan Szabo"
> ><sszabo@megazone23.bigpanda.com>; "Daryl Chance" <dchance@valuedata.net>
> >Cc: <pgsql-general@postgresql.org>
> >Sent: Thursday, September 21, 2000 3:19 PM
> >Subject: RE: [GENERAL] replication
> >
> >
> >> I asked a similar question earlier in the week and got no response.
If
> >> there is transaction logging, then it is fairly easy to implement
> syncing,
> >> even real time, the only question is to play back the log every x
amount
> >of
> >> time on the remote db. The tricky part is two fold.
> >>
> >> First, you have to maintain a table of all of the remote DBs that are
> >> syncing and the last two send and receive timestamps, and whether the
> last
> >> was successful. If not, then at the next sync time, you have to replay
> >the
> >> logs again back to the previous time that was successful. Then you
have
> >to
> >> have a process that cleans up all of the transactions that are previous
> to
> >> the most recent successful sync.
> >>
> >> The second part is collision resolution. That is, what happens when
an
> >> edit is made to a DB at both ends in between the sync period. Most of
> the
> >> time the later timestamp wins, but what happens if that effects
business
> >> rules, range limitations, etc. For instance, if b must be between a
and
> >c,
> >> and b and c are lowered on one end, and on the other b is raised above
> the
> >> new setting for c, how is this resolved. You end up writing a rules
> >engine
> >> for this stuff...
> >>
> >> Rob
> >>
> >> > -----Original Message-----
> >> > From: pgsql-general-owner@hub.org
> [mailto:pgsql-general-owner@hub.org]On
> >> > Behalf Of Adam Lang
> >> > Sent: Thursday, September 21, 2000 12:42 PM
> >> > To: Stephan Szabo; Daryl Chance
> >> > Cc: pgsql-general@postgresql.org
> >> > Subject: Re: [GENERAL] replication
> >> >
> >> >
> >> > Well, if I end up needing to do something with it, I'll get back
> >> > to the list
> >> > on ideas/solutions I encountered and see about potential pitfalls.
> >> >
> >> > Adam Lang
> >> > Systems Engineer
> >> > Rutgers Casualty Insurance Company
> >> > ----- Original Message -----
> >> > From: "Stephan Szabo" <sszabo@megazone23.bigpanda.com>
> >> > To: "Daryl Chance" <dchance@valuedata.net>
> >> > Cc: <pgsql-general@postgresql.org>
> >> > Sent: Thursday, September 21, 2000 12:59 PM
> >> > Subject: Re: [GENERAL] replication
> >> >
> >> >
> >> > > On Thu, 21 Sep 2000, Daryl Chance wrote:
> >> > >
> >> > > > Could this possibly be done using triggers? I'm new to
> >> > > > postgres, but I know on a project I was doing using oracle
> >> > > > the dba could setup triggers to run on the OnInsert() (not
> >> > > > sure what it's actually called in oracle...). Do maybe
> >> > > > on the "OnInsert" of table foo you could do:
> >> > > >
> >> > > > Insert into foo@remotesite1 ....
> >> > > >
> >> > > > Is this possible in postgres? I'm looking at using postgres
> >> > > > for the next version of my SW and if replication isn't in,
> >> > > > I'm gonna need something like this :).
> >> > >
> >> > > You could probably write a C trigger that would propogate
> >> > > changes, except that there are still problems. What do you
> >> > > do when you roll back the transaction? Currently, there
> >> > > aren't triggers for transaction start and end. Triggers that
> >> > > do stuff outside the database right now are a bad idea unless
> >> > > you have some other mechanism to determine whether something
> >> > > was really supposed to be done. It could be done, but isn't
> >> > > trivial.
> >> >
> >> >
> >
> >
^ permalink raw reply [nested|flat] 131+ messages in thread
* Re: replication
@ 2000-09-21 20:19 Michael Fork <mfork@toledolink.com>
parent: Adam Lang <aalang@rutgersinsurance.com>
0 siblings, 1 reply; 131+ messages in thread
From: Michael Fork @ 2000-09-21 20:19 UTC (permalink / raw)
To: Adam Lang <aalang@rutgersinsurance.com>; +Cc: pgsql-general
You can continue to use the same Access app, just link the tables through
ODBC to the postgres sever (save you from reinventing the wheel)
Michael Fork - CCNA - MCP - A+
Network Support - Toledo Internet Access - Toledo Ohio
On Thu, 21 Sep 2000, Adam Lang wrote:
> That is not the situation though. The reason I want to have to databases is
> to have one at the site that actual production is going to be worked on, and
> then a replicated database at a remote location where the webserver is.
>
> As for the interface, they use Access forms, which I'll just write a new VB
> app using ODBC to replace.
>
> Adam Lang
> Systems Engineer
> Rutgers Casualty Insurance Company
> ----- Original Message -----
> From: "Len Morgan" <len-morgan@crcom.net>
> To: "Adam Lang" <aalang@rutgersinsurance.com>
> Sent: Thursday, September 21, 2000 2:52 PM
> Subject: Re: [GENERAL] replication
>
>
> > There is another approach that I have used: Convert all of the tables in
> the
> > current Access system to Postgres tables and then use ODBC links in the
> > current program instead of internal tables. This way you only have one
> > database, no need to replicate and it's much more "live". If you give the
> > tables in Postgres the same names they have in access, you won't have to
> > change any of the forms/queries/reports, etc.
> >
> > Just my 2 cent's worth.
> >
> > Len Morgan
> >
> >
> > -----Original Message-----
> > From: Adam Lang <aalang@rutgersinsurance.com>
> > Cc: pgsql-general@postgresql.org <pgsql-general@postgresql.org>
> > Date: Thursday, September 21, 2000 1:43 PM
> > Subject: Re: [GENERAL] replication
> >
> >
> > >Well, this is the situation. A client has a database application
> currently
> > >running on Access (which multiple people share over a network). They
> want
> > >to make data accessible via the internet. So, what I was thinking was
> keep
> > >the production database at their location, convert it to postgresql, and
> > >make a replacement application for them to do their work. Then, host
> their
> > >webserver remotely and have another database there. The main location has
> a
> > >DSL connection. I figured then that once a day, three times a day
> > >(whatever) the main database synchs up the remote one. (The remote
> database
> > >will only be used by PHP to extract data, no modifications).
> > >
> > >The point of this is that no matter what the main location will always be
> > >able to get their work done while still being able to host their website
> > >offsite.
> > >
> > >If there was only a single database at either end, the whole setup is
> > >susceptible to a telecomm link going down and cutting something off.
> > >
> > >Adam Lang
> > >Systems Engineer
> > >Rutgers Casualty Insurance Company
> > >----- Original Message -----
> > >From: "Rob Hutton" <rhutton@istmanagement.com>
> > >To: "Adam Lang" <aalang@rutgersinsurance.com>; "Stephan Szabo"
> > ><sszabo@megazone23.bigpanda.com>; "Daryl Chance" <dchance@valuedata.net>
> > >Cc: <pgsql-general@postgresql.org>
> > >Sent: Thursday, September 21, 2000 3:19 PM
> > >Subject: RE: [GENERAL] replication
> > >
> > >
> > >> I asked a similar question earlier in the week and got no response.
> If
> > >> there is transaction logging, then it is fairly easy to implement
> > syncing,
> > >> even real time, the only question is to play back the log every x
> amount
> > >of
> > >> time on the remote db. The tricky part is two fold.
> > >>
> > >> First, you have to maintain a table of all of the remote DBs that are
> > >> syncing and the last two send and receive timestamps, and whether the
> > last
> > >> was successful. If not, then at the next sync time, you have to replay
> > >the
> > >> logs again back to the previous time that was successful. Then you
> have
> > >to
> > >> have a process that cleans up all of the transactions that are previous
> > to
> > >> the most recent successful sync.
> > >>
> > >> The second part is collision resolution. That is, what happens when
> an
> > >> edit is made to a DB at both ends in between the sync period. Most of
> > the
> > >> time the later timestamp wins, but what happens if that effects
> business
> > >> rules, range limitations, etc. For instance, if b must be between a
> and
> > >c,
> > >> and b and c are lowered on one end, and on the other b is raised above
> > the
> > >> new setting for c, how is this resolved. You end up writing a rules
> > >engine
> > >> for this stuff...
> > >>
> > >> Rob
> > >>
> > >> > -----Original Message-----
> > >> > From: pgsql-general-owner@hub.org
> > [mailto:pgsql-general-owner@hub.org]On
> > >> > Behalf Of Adam Lang
> > >> > Sent: Thursday, September 21, 2000 12:42 PM
> > >> > To: Stephan Szabo; Daryl Chance
> > >> > Cc: pgsql-general@postgresql.org
> > >> > Subject: Re: [GENERAL] replication
> > >> >
> > >> >
> > >> > Well, if I end up needing to do something with it, I'll get back
> > >> > to the list
> > >> > on ideas/solutions I encountered and see about potential pitfalls.
> > >> >
> > >> > Adam Lang
> > >> > Systems Engineer
> > >> > Rutgers Casualty Insurance Company
> > >> > ----- Original Message -----
> > >> > From: "Stephan Szabo" <sszabo@megazone23.bigpanda.com>
> > >> > To: "Daryl Chance" <dchance@valuedata.net>
> > >> > Cc: <pgsql-general@postgresql.org>
> > >> > Sent: Thursday, September 21, 2000 12:59 PM
> > >> > Subject: Re: [GENERAL] replication
> > >> >
> > >> >
> > >> > > On Thu, 21 Sep 2000, Daryl Chance wrote:
> > >> > >
> > >> > > > Could this possibly be done using triggers? I'm new to
> > >> > > > postgres, but I know on a project I was doing using oracle
> > >> > > > the dba could setup triggers to run on the OnInsert() (not
> > >> > > > sure what it's actually called in oracle...). Do maybe
> > >> > > > on the "OnInsert" of table foo you could do:
> > >> > > >
> > >> > > > Insert into foo@remotesite1 ....
> > >> > > >
> > >> > > > Is this possible in postgres? I'm looking at using postgres
> > >> > > > for the next version of my SW and if replication isn't in,
> > >> > > > I'm gonna need something like this :).
> > >> > >
> > >> > > You could probably write a C trigger that would propogate
> > >> > > changes, except that there are still problems. What do you
> > >> > > do when you roll back the transaction? Currently, there
> > >> > > aren't triggers for transaction start and end. Triggers that
> > >> > > do stuff outside the database right now are a bad idea unless
> > >> > > you have some other mechanism to determine whether something
> > >> > > was really supposed to be done. It could be done, but isn't
> > >> > > trivial.
> > >> >
> > >> >
> > >
> > >
>
^ permalink raw reply [nested|flat] 131+ messages in thread
* Re: replication
@ 2000-09-21 20:32 Adam Lang <aalang@rutgersinsurance.com>
parent: Michael Fork <mfork@toledolink.com>
0 siblings, 0 replies; 131+ messages in thread
From: Adam Lang @ 2000-09-21 20:32 UTC (permalink / raw)
To: ; +Cc: pgsql-general
I'm not keeping the Access forms because I would like to move them to
something a little more robust. Also, if I'm going to continue support the
application, moving the code from Acces-VBA to VB is bit cleaner. Even for
people after me.
Adam Lang
Systems Engineer
Rutgers Casualty Insurance Company
----- Original Message -----
From: "Michael Fork" <mfork@toledolink.com>
To: "Adam Lang" <aalang@rutgersinsurance.com>
Cc: "PGSQL General" <pgsql-general@postgresql.org>
Sent: Thursday, September 21, 2000 4:19 PM
Subject: Re: [GENERAL] replication
> You can continue to use the same Access app, just link the tables through
> ODBC to the postgres sever (save you from reinventing the wheel)
>
> Michael Fork - CCNA - MCP - A+
> Network Support - Toledo Internet Access - Toledo Ohio
>
> On Thu, 21 Sep 2000, Adam Lang wrote:
>
> > That is not the situation though. The reason I want to have to
databases is
> > to have one at the site that actual production is going to be worked on,
and
> > then a replicated database at a remote location where the webserver is.
> >
> > As for the interface, they use Access forms, which I'll just write a new
VB
> > app using ODBC to replace.
> >
> > Adam Lang
> > Systems Engineer
> > Rutgers Casualty Insurance Company
> > ----- Original Message -----
> > From: "Len Morgan" <len-morgan@crcom.net>
> > To: "Adam Lang" <aalang@rutgersinsurance.com>
> > Sent: Thursday, September 21, 2000 2:52 PM
> > Subject: Re: [GENERAL] replication
> >
> >
> > > There is another approach that I have used: Convert all of the tables
in
> > the
> > > current Access system to Postgres tables and then use ODBC links in
the
> > > current program instead of internal tables. This way you only have
one
> > > database, no need to replicate and it's much more "live". If you give
the
> > > tables in Postgres the same names they have in access, you won't have
to
> > > change any of the forms/queries/reports, etc.
> > >
> > > Just my 2 cent's worth.
> > >
> > > Len Morgan
> > >
> > >
> > > -----Original Message-----
> > > From: Adam Lang <aalang@rutgersinsurance.com>
> > > Cc: pgsql-general@postgresql.org <pgsql-general@postgresql.org>
> > > Date: Thursday, September 21, 2000 1:43 PM
> > > Subject: Re: [GENERAL] replication
> > >
> > >
> > > >Well, this is the situation. A client has a database application
> > currently
> > > >running on Access (which multiple people share over a network). They
> > want
> > > >to make data accessible via the internet. So, what I was thinking
was
> > keep
> > > >the production database at their location, convert it to postgresql,
and
> > > >make a replacement application for them to do their work. Then, host
> > their
> > > >webserver remotely and have another database there. The main location
has
> > a
> > > >DSL connection. I figured then that once a day, three times a day
> > > >(whatever) the main database synchs up the remote one. (The remote
> > database
> > > >will only be used by PHP to extract data, no modifications).
> > > >
> > > >The point of this is that no matter what the main location will
always be
> > > >able to get their work done while still being able to host their
website
> > > >offsite.
> > > >
> > > >If there was only a single database at either end, the whole setup is
> > > >susceptible to a telecomm link going down and cutting something off.
> > > >
> > > >Adam Lang
> > > >Systems Engineer
> > > >Rutgers Casualty Insurance Company
> > > >----- Original Message -----
> > > >From: "Rob Hutton" <rhutton@istmanagement.com>
> > > >To: "Adam Lang" <aalang@rutgersinsurance.com>; "Stephan Szabo"
> > > ><sszabo@megazone23.bigpanda.com>; "Daryl Chance"
<dchance@valuedata.net>
> > > >Cc: <pgsql-general@postgresql.org>
> > > >Sent: Thursday, September 21, 2000 3:19 PM
> > > >Subject: RE: [GENERAL] replication
> > > >
> > > >
> > > >> I asked a similar question earlier in the week and got no
response.
> > If
> > > >> there is transaction logging, then it is fairly easy to implement
> > > syncing,
> > > >> even real time, the only question is to play back the log every x
> > amount
> > > >of
> > > >> time on the remote db. The tricky part is two fold.
> > > >>
> > > >> First, you have to maintain a table of all of the remote DBs that
are
> > > >> syncing and the last two send and receive timestamps, and whether
the
> > > last
> > > >> was successful. If not, then at the next sync time, you have to
replay
> > > >the
> > > >> logs again back to the previous time that was successful. Then you
> > have
> > > >to
> > > >> have a process that cleans up all of the transactions that are
previous
> > > to
> > > >> the most recent successful sync.
> > > >>
> > > >> The second part is collision resolution. That is, what happens
when
> > an
> > > >> edit is made to a DB at both ends in between the sync period. Most
of
> > > the
> > > >> time the later timestamp wins, but what happens if that effects
> > business
> > > >> rules, range limitations, etc. For instance, if b must be between
a
> > and
> > > >c,
> > > >> and b and c are lowered on one end, and on the other b is raised
above
> > > the
> > > >> new setting for c, how is this resolved. You end up writing a
rules
> > > >engine
> > > >> for this stuff...
> > > >>
> > > >> Rob
> > > >>
> > > >> > -----Original Message-----
> > > >> > From: pgsql-general-owner@hub.org
> > > [mailto:pgsql-general-owner@hub.org]On
> > > >> > Behalf Of Adam Lang
> > > >> > Sent: Thursday, September 21, 2000 12:42 PM
> > > >> > To: Stephan Szabo; Daryl Chance
> > > >> > Cc: pgsql-general@postgresql.org
> > > >> > Subject: Re: [GENERAL] replication
> > > >> >
> > > >> >
> > > >> > Well, if I end up needing to do something with it, I'll get back
> > > >> > to the list
> > > >> > on ideas/solutions I encountered and see about potential
pitfalls.
> > > >> >
> > > >> > Adam Lang
> > > >> > Systems Engineer
> > > >> > Rutgers Casualty Insurance Company
> > > >> > ----- Original Message -----
> > > >> > From: "Stephan Szabo" <sszabo@megazone23.bigpanda.com>
> > > >> > To: "Daryl Chance" <dchance@valuedata.net>
> > > >> > Cc: <pgsql-general@postgresql.org>
> > > >> > Sent: Thursday, September 21, 2000 12:59 PM
> > > >> > Subject: Re: [GENERAL] replication
> > > >> >
> > > >> >
> > > >> > > On Thu, 21 Sep 2000, Daryl Chance wrote:
> > > >> > >
> > > >> > > > Could this possibly be done using triggers? I'm new to
> > > >> > > > postgres, but I know on a project I was doing using oracle
> > > >> > > > the dba could setup triggers to run on the OnInsert() (not
> > > >> > > > sure what it's actually called in oracle...). Do maybe
> > > >> > > > on the "OnInsert" of table foo you could do:
> > > >> > > >
> > > >> > > > Insert into foo@remotesite1 ....
> > > >> > > >
> > > >> > > > Is this possible in postgres? I'm looking at using postgres
> > > >> > > > for the next version of my SW and if replication isn't in,
> > > >> > > > I'm gonna need something like this :).
> > > >> > >
> > > >> > > You could probably write a C trigger that would propogate
> > > >> > > changes, except that there are still problems. What do you
> > > >> > > do when you roll back the transaction? Currently, there
> > > >> > > aren't triggers for transaction start and end. Triggers that
> > > >> > > do stuff outside the database right now are a bad idea unless
> > > >> > > you have some other mechanism to determine whether something
> > > >> > > was really supposed to be done. It could be done, but isn't
> > > >> > > trivial.
> > > >> >
> > > >> >
> > > >
> > > >
> >
^ permalink raw reply [nested|flat] 131+ messages in thread
* Re: replication
@ 2000-09-22 07:58 Elmar Haneke <elmar@haneke.de>
parent: Adam Lang <aalang@rutgersinsurance.com>
3 siblings, 1 reply; 131+ messages in thread
From: Elmar Haneke @ 2000-09-22 07:58 UTC (permalink / raw)
To: Adam Lang <aalang@rutgersinsurance.com>; pgsql-general
Adam Lang wrote:
>
> Are there any type of replication features in postgresql 7.0?
>
> I would like it where two databases have the same structure, but say at
> midnight every night Database 1 synchs up database 2.
>
> Granted, I could always write code to do that, but it wouldn't be very
> sophisticated. (If I coded it, would do something like find rows in table
> 1 which aren't in the second database, append them database two, same with
> the second table, etc.)
I would suggest to consider the xmin values stored with each row in
database. This number does contain the transaction-number of the
last change to this tuple.
An replication should copy all tuples having larger xmin than
copied by the last replication. If each table has an primary key,
replication can decide wether the tuple is updated or inserted.
For deletes you should consider to use triggers copying the keys
of deleted tuples to an "delete-log-table". If an delete-transaction
is aborted, the entries to this table should be cancelled
automatically by the transaction control.
I'm not sure wether you can use the oid as an key for this purpose.
Is oid updatable to keep it in sync on both databases?
Elmar
^ permalink raw reply [nested|flat] 131+ messages in thread
* Re: replication
@ 2000-09-22 15:31 Bruce Guenter <bruceg@em.ca>
parent: Elmar Haneke <elmar@haneke.de>
0 siblings, 1 reply; 131+ messages in thread
From: Bruce Guenter @ 2000-09-22 15:31 UTC (permalink / raw)
To: pgsql-general
On Fri, Sep 22, 2000 at 09:58:24AM +0200, Elmar Haneke wrote:
> Adam Lang wrote:
> > Are there any type of replication features in postgresql 7.0?
I've been thinking that one way to emulate replication would be to run a
pgsql "shim" that would redirect queries to two back-ends
simultaneously, creating transactions for update commands, and aborting
when necessary. The shim would be a long-running gateway process, that
could check for data consistency when it started up. This is all off
the top of my head, so is this at all a reasonable idea?
I am running into a similar situation, where I want to set up two live
redundant sites, where nightly updates aren't an option.
--
Bruce Guenter <bruceg@em.ca> http://em.ca/~bruceg/
^ permalink raw reply [nested|flat] 131+ messages in thread
* Re: replication
@ 2000-09-22 16:03 Tom Lane <tgl@sss.pgh.pa.us>
parent: Bruce Guenter <bruceg@em.ca>
0 siblings, 1 reply; 131+ messages in thread
From: Tom Lane @ 2000-09-22 16:03 UTC (permalink / raw)
To: Bruce Guenter <bruceg@em.ca>; +Cc: pgsql-general
Bruce Guenter <bruceg@em.ca> writes:
> I've been thinking that one way to emulate replication would be to run a
> pgsql "shim" that would redirect queries to two back-ends
> simultaneously, creating transactions for update commands, and aborting
> when necessary. The shim would be a long-running gateway process, that
> could check for data consistency when it started up. This is all off
> the top of my head, so is this at all a reasonable idea?
Awhile back, someone reported that they were successfully using exactly
this idea. Check the PG list archives (sorry, I forget which list).
I'm not convinced that this scales real well to multiple concurrent
clients ... at the very least, you'd need a single gateway that
serializes all the requests. You might still have problems with the
two databases not executing requests in exactly the same order. Also
it'd be really dangerous to use OIDs as a way of identifying rows in
application queries. But with a cooperative application it could
probably be made to work.
regards, tom lane
^ permalink raw reply [nested|flat] 131+ messages in thread
* Re: replication
@ 2000-09-22 16:08 Bruce Guenter <bruceg@em.ca>
parent: Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 0 replies; 131+ messages in thread
From: Bruce Guenter @ 2000-09-22 16:08 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: pgsql-general
On Fri, Sep 22, 2000 at 12:03:13PM -0400, Tom Lane wrote:
> Bruce Guenter <bruceg@em.ca> writes:
> > I've been thinking that one way to emulate replication would be to run a
> > pgsql "shim" that would redirect queries to two back-ends
> > simultaneously, creating transactions for update commands, and aborting
> > when necessary. The shim would be a long-running gateway process, that
> > could check for data consistency when it started up. This is all off
> > the top of my head, so is this at all a reasonable idea?
>
> Awhile back, someone reported that they were successfully using exactly
> this idea. Check the PG list archives (sorry, I forget which list).
Cool! I'll take a look.
> I'm not convinced that this scales real well to multiple concurrent
> clients ... at the very least, you'd need a single gateway that
> serializes all the requests.
Or multiple gateways, one "near" each database server, that try to keep
some synchronization with each other.
> You might still have problems with the
> two databases not executing requests in exactly the same order.
> Also
> it'd be really dangerous to use OIDs as a way of identifying rows in
> application queries.
Oh, definitely agreed. OIDs go out the window, unless both servers have
have identical queries delivered to them at all times. This is rather
difficult to guarantee.
--
Bruce Guenter <bruceg@em.ca> http://em.ca/~bruceg/
^ permalink raw reply [nested|flat] 131+ messages in thread
* Replication
@ 2001-01-25 00:18 Ryan Mahoney <ryan@paymentalliance.net>
0 siblings, 0 replies; 131+ messages in thread
From: Ryan Mahoney @ 2001-01-25 00:18 UTC (permalink / raw)
To: pgsql-general
What is the status of Replication in 7.1? Where can I find out more info?
Setting up e-commerce site, need to keep a 'backup' version of pgsql up to
date in case of fallover.
Thanks!
-Ryan Mahoney
^ permalink raw reply [nested|flat] 131+ messages in thread
* replication?
@ 2001-07-18 20:31 Fran Fabrizio <ffabrizio@mmrd.com>
0 siblings, 3 replies; 131+ messages in thread
From: Fran Fabrizio @ 2001-07-18 20:31 UTC (permalink / raw)
To: pgsql-general
Does postgres support replication? I think this is the feature I need.
I have a table in one db that I need to use from another db on another
machine. The first db is behind two firewalls (for a good reason =) and
the second needs to be hung out on the internet, so I can't really use
the same db. But I would like to have the table on the internet Pg
install to be updated whenever the master table behind the firewalls is
updated. It doesn't need to be real-time, but maybe once every hour or
half hour. I certainly have no problem cheating and just copying a file
over or something if that will work. I looked through the docs but
didn't see anything about replication in the Administrator manual, where
I assume it'd be discussed. I did see a vague reference to a
replication toolkit in the release notes, is this what I'm looking for?
Thanks,
Fran
^ permalink raw reply [nested|flat] 131+ messages in thread
* Re: replication?
@ 2001-07-18 21:33 Ryan Mahoney <ryan@paymentalliance.net>
parent: Fran Fabrizio <ffabrizio@mmrd.com>
2 siblings, 0 replies; 131+ messages in thread
From: Ryan Mahoney @ 2001-07-18 21:33 UTC (permalink / raw)
To: Fran Fabrizio <ffabrizio@mmrd.com>; pgsql-general
http://www.greatbridge.org/genpage?replication_top
All you could ever want to know about pgsql replication.
God Luck!
-r
At 04:31 PM 7/18/01 -0400, Fran Fabrizio wrote:
>Does postgres support replication? I think this is the feature I need.
>I have a table in one db that I need to use from another db on another
>machine. The first db is behind two firewalls (for a good reason =) and
>the second needs to be hung out on the internet, so I can't really use
>the same db. But I would like to have the table on the internet Pg
>install to be updated whenever the master table behind the firewalls is
>updated. It doesn't need to be real-time, but maybe once every hour or
>half hour. I certainly have no problem cheating and just copying a file
>over or something if that will work. I looked through the docs but
>didn't see anything about replication in the Administrator manual, where
>I assume it'd be discussed. I did see a vague reference to a
>replication toolkit in the release notes, is this what I'm looking for?
>
>Thanks,
>Fran
>
>
>---------------------------(end of broadcast)---------------------------
>TIP 6: Have you searched our list archives?
>
>http://www.postgresql.org/search.mpl
>
>
>
>---
>Incoming mail is certified Virus Free.
>Checked by AVG anti-virus system (http://www.grisoft.com).
>Version: 6.0.251 / Virus Database: 124 - Release Date: 4/26/01
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.251 / Virus Database: 124 - Release Date: 4/26/01
^ permalink raw reply [nested|flat] 131+ messages in thread
* Re: replication?
@ 2001-07-18 22:28 Adam Manock <abmanock@planetcable.net>
parent: Fran Fabrizio <ffabrizio@mmrd.com>
2 siblings, 0 replies; 131+ messages in thread
From: Adam Manock @ 2001-07-18 22:28 UTC (permalink / raw)
To: Fran Fabrizio <ffabrizio@mmrd.com>; pgsql-general
Hi,
from: http://www.postgresql.org/idocs/index.php?backup.html :
"pg_dump -h host1 dbname | psql -h host2 dbname"
You could run this out of cron on your internal DB server (host1)
And use a firewall rule like:
# Allow internal DB server to use TCP for DB dumps
pass in quick proto tcp from ip_of_host1 to ip_of_host2 port = 5432 flags
S/FSRPAU keep state
The rule above is for IP Filter http://coombs.anu.edu.au/~avalon/
Adam
At 04:31 PM 7/18/01 -0400, Fran Fabrizio wrote:
Does postgres support replication? I think this is the feature I need.
I have a table in one db that I need to use from another db on another
machine. The first db is behind two firewalls (for a good reason =) and
the second needs to be hung out on the internet, so I can't really use
the same db. But I would like to have the table on the internet Pg
install to be updated whenever the master table behind the firewalls is
updated. It doesn't need to be real-time, but maybe once every hour or
half hour. I certainly have no problem cheating and just copying a file
over or something if that will work. I looked through the docs but
didn't see anything about replication in the Administrator manual, where
I assume it'd be discussed. I did see a vague reference to a
replication toolkit in the release notes, is this what I'm looking for?
Thanks,
Fran
^ permalink raw reply [nested|flat] 131+ messages in thread
* Re: replication?
@ 2001-07-18 23:12 Justin Clift <justin@postgresql.org>
parent: Fran Fabrizio <ffabrizio@mmrd.com>
2 siblings, 0 replies; 131+ messages in thread
From: Justin Clift @ 2001-07-18 23:12 UTC (permalink / raw)
To: Fran Fabrizio <ffabrizio@mmrd.com>; +Cc: pgsql-general
Hi Fran,
You might want to check out the PostgreSQL replication solutions linked
to from :
http://techdocs.postgresql.org/oresources.php#replication
PostgreSQL Replicator seems to be the most complete, but I'm not sure
(haven't yet gotten around to testing them properly).
:-)
Regards and best wishes,
Justin Clift
Fran Fabrizio wrote:
>
> Does postgres support replication? I think this is the feature I need.
> I have a table in one db that I need to use from another db on another
> machine. The first db is behind two firewalls (for a good reason =) and
> the second needs to be hung out on the internet, so I can't really use
> the same db. But I would like to have the table on the internet Pg
> install to be updated whenever the master table behind the firewalls is
> updated. It doesn't need to be real-time, but maybe once every hour or
> half hour. I certainly have no problem cheating and just copying a file
> over or something if that will work. I looked through the docs but
> didn't see anything about replication in the Administrator manual, where
> I assume it'd be discussed. I did see a vague reference to a
> replication toolkit in the release notes, is this what I'm looking for?
>
> Thanks,
> Fran
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
>
> http://www.postgresql.org/search.mpl
^ permalink raw reply [nested|flat] 131+ messages in thread
* Replication
@ 2001-11-15 19:14 Mihai Gheorghiu <tanethq@earthlink.net>
0 siblings, 0 replies; 131+ messages in thread
From: Mihai Gheorghiu @ 2001-11-15 19:14 UTC (permalink / raw)
To: pgsql-general
I checked gborg.postgresql.org, but I'm still not clear about the following:
I have a configuration that backs-up the database on server A every night
and the file is stored on server B (200 miles away, over a T1). Upon
arrival, the db is restored on server B, so, in the morning, A and B are
identical.
The working server is A. Users at location B actually use server A over T1
for normal operations.
If the T1 fails (assume overnight, after backup was transmitted), users at
the two ends can work off the local server.
If PG was installed without replication support, is there a way to
synchronize the two databases after each end has made changes to them?
Thank you all.
^ permalink raw reply [nested|flat] 131+ messages in thread
* Replication
@ 2002-03-01 01:55 George Osvald <mail@okstudio.com.au>
0 siblings, 1 reply; 131+ messages in thread
From: George Osvald @ 2002-03-01 01:55 UTC (permalink / raw)
To: pgsql-general
I am running Postgresql at my office and I am considering running it on the
net as well. My ISP only has MYSQL so I would have to set up my own
postgresql server on my user account. I have a few questions:
-Can I use replication over ADSL connection?
-Do I have to replicate the whole database or can I replicate only certain
tables?
-Can I use something like rsync to do that for me?
-Would it be possible to replicate tables from MYSQL database to my
Postgresql?
Thank you very much for any advise.
Regards,
George Osvald
OK STUDIO
mail@okstudio.com.au
http://www.okstudio.com.au
^ permalink raw reply [nested|flat] 131+ messages in thread
* Re: Replication
@ 2002-03-01 09:13 Holger Marzen <holger@marzen.de>
parent: George Osvald <mail@okstudio.com.au>
0 siblings, 0 replies; 131+ messages in thread
From: Holger Marzen @ 2002-03-01 09:13 UTC (permalink / raw)
To: George Osvald <mail@okstudio.com.au>; +Cc: pgsql-general
On Fri, 1 Mar 2002, George Osvald wrote:
> I am running Postgresql at my office and I am considering running it on the
> net as well. My ISP only has MYSQL so I would have to set up my own
> postgresql server on my user account. I have a few questions:
If you use PHP there then it is probably neccessery to recompile PHP
with --enable-pgsql.
> -Can I use replication over ADSL connection?
If it's a Unix/Linux box you can dump your local db and ssh to the
remote machine, running psql with i/o-redirection from the local
machine. ssh crypts and can compress on the fly.
You then don't need to open the postgres tcp-port to the world because
you run psql on the remote machine.
--
PGP/GPG Key-ID:
http://blackhole.pca.dfn.de:11371/pks/lookup?op=get&search=0xB5A1AFE1
^ permalink raw reply [nested|flat] 131+ messages in thread
* replication
@ 2002-10-17 22:46 Paul <paul@nomail.com>
0 siblings, 1 reply; 131+ messages in thread
From: Paul @ 2002-10-17 22:46 UTC (permalink / raw)
To: pgsql-general
Hi,
I've been looking into possibilities for doing master-master replication
with postgres. So far all the open-source projects I've seen are not capable
of doing this. Are there any commercial solutions for master-master
replication with postgres?
Thanks,
Paul
-----------== Posted via Newsfeed.Com - Uncensored Usenet News ==----------
http://www.newsfeed.com The #1 Newsgroup Service in the World!
-----= Over 100,000 Newsgroups - Unlimited Fast Downloads - 19 Servers =-----
^ permalink raw reply [nested|flat] 131+ messages in thread
* Re: replication
@ 2002-10-22 15:12 Andrew Sullivan <andrew@libertyrms.info>
parent: Paul <paul@nomail.com>
0 siblings, 0 replies; 131+ messages in thread
From: Andrew Sullivan @ 2002-10-22 15:12 UTC (permalink / raw)
To: pgsql-general
On Fri, Oct 18, 2002 at 12:46:26AM +0200, Paul wrote:
> Hi,
>
> I've been looking into possibilities for doing master-master replication
> with postgres. So far all the open-source projects I've seen are not capable
> of doing this. Are there any commercial solutions for master-master
> replication with postgres?
No, not yet, as far as I know.
A
--
----
Andrew Sullivan 204-4141 Yonge Street
Liberty RMS Toronto, Ontario Canada
<andrew@libertyrms.info> M2P 2A8
+1 416 646 3304 x110
^ permalink raw reply [nested|flat] 131+ messages in thread
* replication
@ 2003-04-20 10:18 valter m <maweb@hotmail.com>
0 siblings, 0 replies; 131+ messages in thread
From: valter m @ 2003-04-20 10:18 UTC (permalink / raw)
To: pgsql-general
i want to replicate a db and load balancing "select from", the software uses
sql transactions.
I'm using pg 7.3.1, what software can i use?
thanks for your answer.
Valy
----------------
zblogger.com easy blogging!
_________________________________________________________________
MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*.
http://join.msn.com/?page=features/virus
^ permalink raw reply [nested|flat] 131+ messages in thread
* Replication
@ 2003-12-17 08:15 John Sidney-Woollett <johnsw@wardbrook.com>
0 siblings, 2 replies; 131+ messages in thread
From: John Sidney-Woollett @ 2003-12-17 08:15 UTC (permalink / raw)
To: johnsw@wardbrook.com; +Cc: johnsw@wardbrook.com, "Anthony Best" <abest@digitalflex.net>; pgsql-general
Apologies if this is a double post - I'm sure I sent a similar e-mail to
the list, but it seems to have disappeared in the ether.
Id there a definitive list of what replication options are currently
available for 7.4 (and 7.5), and what their relative strengths and
weaknesses are; ease of use, configuration, cost, support etc
I need to start tackling replication of our DB in the next few weeks, and
wondered what the options are.
I've seen RServer and Mammoth Replication - these look good (on paper) but
both appear to involve a license fee (which is more than I have to spend
right now).
Is pgReplication ready for 7.4 yet? And are there any other *free*
options? If not maybe I'll have to find the money for a commercial
solution.
I'd appreciate any feedback from anyone who has a working replication
solution.
Thanks
John Sidney-Woollett
^ permalink raw reply [nested|flat] 131+ messages in thread
* Re: Replication
@ 2003-12-17 14:22 Andrew Rawnsley <ronz@ravensfield.com>
parent: John Sidney-Woollett <johnsw@wardbrook.com>
1 sibling, 2 replies; 131+ messages in thread
From: Andrew Rawnsley @ 2003-12-17 14:22 UTC (permalink / raw)
To: johnsw@wardbrook.com; +Cc: pgsql-general
On Dec 17, 2003, at 3:15 AM, John Sidney-Woollett wrote:
> Apologies if this is a double post - I'm sure I sent a similar e-mail
> to
> the list, but it seems to have disappeared in the ether.
>
> Id there a definitive list of what replication options are currently
> available for 7.4 (and 7.5), and what their relative strengths and
> weaknesses are; ease of use, configuration, cost, support etc
>
> I need to start tackling replication of our DB in the next few weeks,
> and
> wondered what the options are.
>
> I've seen RServer and Mammoth Replication - these look good (on paper)
> but
> both appear to involve a license fee (which is more than I have to
> spend
> right now).
There's 2 versions of eRServer - v1.2 is free on gborg and Postgresql,
Inc. has another
that you get with a support contract.
I've patched eRServer pretty heavily to fix some bugs and add some
usability. The
eRServer list has some discussion of these.
Jan Weick is in the early stages of developing a new replication system
that
looks to be pretty nice. He also has a project set up on gborg.
In addition, RServ (what eRServer was based on) is still going, along
with dbmirror
(which is in contrib in the main distribution).
Mammoth is something you would have to ask Joshua Drake about. Don't
know anything about it.
>
> Is pgReplication ready for 7.4 yet? And are there any other *free*
> options? If not maybe I'll have to find the money for a commercial
> solution.
Doesn't look like based on the web site at gborg.
>
> I'd appreciate any feedback from anyone who has a working replication
> solution.
>
So far eRServer is working ok for me. If you use the unpatched version
on gborg, be sure to
read the erserver list archives, as the current tarball has a problem
or two. If you want to
work with my fork let me know. I like to think it works better, but I'm
hardly unbiased...
> Thanks
>
> John Sidney-Woollett
>
>
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 9: the planner will ignore your desire to choose an index scan if
> your
> joining column's datatypes do not match
>
--------------------
Andrew Rawnsley
President
The Ravensfield Digital Resource Group, Ltd.
(740) 587-0114
www.ravensfield.com
^ permalink raw reply [nested|flat] 131+ messages in thread
* Re: Replication
@ 2003-12-18 08:16 John Sidney-Woollett <johnsw@wardbrook.com>
parent: Andrew Rawnsley <ronz@ravensfield.com>
1 sibling, 0 replies; 131+ messages in thread
From: John Sidney-Woollett @ 2003-12-18 08:16 UTC (permalink / raw)
To: Andrew Rawnsley <ronz@ravensfield.com>; +Cc: pgsql-general
Andrew
Thanks for the info.
Can you detail more fully the changes you made to eRServer - v1.2, and
will your patched version work with 7.4?
John
Andrew Rawnsley said:
>
> On Dec 17, 2003, at 3:15 AM, John Sidney-Woollett wrote:
>
>> Apologies if this is a double post - I'm sure I sent a similar e-mail
>> to
>> the list, but it seems to have disappeared in the ether.
>>
>> Id there a definitive list of what replication options are currently
>> available for 7.4 (and 7.5), and what their relative strengths and
>> weaknesses are; ease of use, configuration, cost, support etc
>>
>> I need to start tackling replication of our DB in the next few weeks,
>> and
>> wondered what the options are.
>>
>> I've seen RServer and Mammoth Replication - these look good (on paper)
>> but
>> both appear to involve a license fee (which is more than I have to
>> spend
>> right now).
>
> There's 2 versions of eRServer - v1.2 is free on gborg and Postgresql,
> Inc. has another
> that you get with a support contract.
>
> I've patched eRServer pretty heavily to fix some bugs and add some
> usability. The
> eRServer list has some discussion of these.
>
> Jan Weick is in the early stages of developing a new replication system
> that
> looks to be pretty nice. He also has a project set up on gborg.
>
> In addition, RServ (what eRServer was based on) is still going, along
> with dbmirror
> (which is in contrib in the main distribution).
>
> Mammoth is something you would have to ask Joshua Drake about. Don't
> know anything about it.
>
>>
>> Is pgReplication ready for 7.4 yet? And are there any other *free*
>> options? If not maybe I'll have to find the money for a commercial
>> solution.
>
> Doesn't look like based on the web site at gborg.
>
>>
>> I'd appreciate any feedback from anyone who has a working replication
>> solution.
>>
>
> So far eRServer is working ok for me. If you use the unpatched version
> on gborg, be sure to
> read the erserver list archives, as the current tarball has a problem
> or two. If you want to
> work with my fork let me know. I like to think it works better, but I'm
> hardly unbiased...
>
>> Thanks
>>
>> John Sidney-Woollett
>>
>>
>>
>> ---------------------------(end of
>> broadcast)---------------------------
>> TIP 9: the planner will ignore your desire to choose an index scan if
>> your
>> joining column's datatypes do not match
>>
> --------------------
>
> Andrew Rawnsley
> President
> The Ravensfield Digital Resource Group, Ltd.
> (740) 587-0114
> www.ravensfield.com
>
>
^ permalink raw reply [nested|flat] 131+ messages in thread
* Re: Replication
@ 2003-12-18 20:40 Robert Treat <xzilla@users.sourceforge.net>
parent: John Sidney-Woollett <johnsw@wardbrook.com>
1 sibling, 2 replies; 131+ messages in thread
From: Robert Treat @ 2003-12-18 20:40 UTC (permalink / raw)
To: johnsw@wardbrook.com; +Cc: Anthony Best <abest@digitalflex.net>; pgsql-general
Check out the pg_replicator project on gborg, IIRC it has links to some
of the replication solutions.... USOGRES comes to mind...
BTW - I'f you do give each one a twirl, we'd love to hear about your
experiences.
Robert Treat
On Wed, 2003-12-17 at 03:15, John Sidney-Woollett wrote:
> Apologies if this is a double post - I'm sure I sent a similar e-mail to
> the list, but it seems to have disappeared in the ether.
>
> Id there a definitive list of what replication options are currently
> available for 7.4 (and 7.5), and what their relative strengths and
> weaknesses are; ease of use, configuration, cost, support etc
>
> I need to start tackling replication of our DB in the next few weeks, and
> wondered what the options are.
>
> I've seen RServer and Mammoth Replication - these look good (on paper) but
> both appear to involve a license fee (which is more than I have to spend
> right now).
>
> Is pgReplication ready for 7.4 yet? And are there any other *free*
> options? If not maybe I'll have to find the money for a commercial
> solution.
>
> I'd appreciate any feedback from anyone who has a working replication
> solution.
>
> Thanks
>
> John Sidney-Woollett
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 9: the planner will ignore your desire to choose an index scan if your
> joining column's datatypes do not match
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
^ permalink raw reply [nested|flat] 131+ messages in thread
* Re: Replication
@ 2003-12-18 21:24 Andrew Sullivan <andrew@libertyrms.info>
parent: Robert Treat <xzilla@users.sourceforge.net>
1 sibling, 0 replies; 131+ messages in thread
From: Andrew Sullivan @ 2003-12-18 21:24 UTC (permalink / raw)
To: pgsql-general
On Thu, Dec 18, 2003 at 03:40:44PM -0500, Robert Treat wrote:
> >
> > I've seen RServer and Mammoth Replication - these look good (on paper) but
> > both appear to involve a license fee (which is more than I have to spend
> > right now).
For the record, there is an open source version of erserver. It's
available on gborg.
A
--
----
Andrew Sullivan 204-4141 Yonge Street
Afilias Canada Toronto, Ontario Canada
<andrew@libertyrms.info> M2P 2A8
+1 416 646 3304 x110
^ permalink raw reply [nested|flat] 131+ messages in thread
* Re: Replication
@ 2003-12-18 21:35 John Sidney-Woollett <johnsw@wardbrook.com>
parent: Robert Treat <xzilla@users.sourceforge.net>
1 sibling, 0 replies; 131+ messages in thread
From: John Sidney-Woollett @ 2003-12-18 21:35 UTC (permalink / raw)
To: Robert Treat <xzilla@users.sourceforge.net>; +Cc: johnsw@wardbrook.com, "Anthony Best" <abest@digitalflex.net>; pgsql-general
Robert
Thanks for the info.
I'll keep the list posted with feedback after I decide which product to go
with.
John
Robert Treat said:
> Check out the pg_replicator project on gborg, IIRC it has links to some
> of the replication solutions.... USOGRES comes to mind...
>
> BTW - I'f you do give each one a twirl, we'd love to hear about your
> experiences.
>
> Robert Treat
>
> On Wed, 2003-12-17 at 03:15, John Sidney-Woollett wrote:
>> Apologies if this is a double post - I'm sure I sent a similar e-mail to
>> the list, but it seems to have disappeared in the ether.
>>
>> Id there a definitive list of what replication options are currently
>> available for 7.4 (and 7.5), and what their relative strengths and
>> weaknesses are; ease of use, configuration, cost, support etc
>>
>> I need to start tackling replication of our DB in the next few weeks,
>> and
>> wondered what the options are.
>>
>> I've seen RServer and Mammoth Replication - these look good (on paper)
>> but
>> both appear to involve a license fee (which is more than I have to spend
>> right now).
>>
>> Is pgReplication ready for 7.4 yet? And are there any other *free*
>> options? If not maybe I'll have to find the money for a commercial
>> solution.
>>
>> I'd appreciate any feedback from anyone who has a working replication
>> solution.
>>
>> Thanks
>>
>> John Sidney-Woollett
>>
>>
>>
>> ---------------------------(end of broadcast)---------------------------
>> TIP 9: the planner will ignore your desire to choose an index scan if
>> your
>> joining column's datatypes do not match
>
> --
> Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
>
>
^ permalink raw reply [nested|flat] 131+ messages in thread
* Replication ?
@ 2003-12-31 11:06 Andreas <maps.on@gmx.net>
0 siblings, 1 reply; 131+ messages in thread
From: Andreas @ 2003-12-31 11:06 UTC (permalink / raw)
To: pgsql-general
Hello list,
did someone try successfully to use the replication extension that was
released to the community this summer ?
Maybe someone could share his/her impressions and produce a tiny
description what to do to actually build the extension, install and
connect 2 servers so they share the sql that is thrown at them.
Watch your way when you step over into 2004 later today ;)
Andreas
^ permalink raw reply [nested|flat] 131+ messages in thread
* Re: Replication ?
@ 2003-12-31 11:12 John Sidney-Woollett <johnsw@wardbrook.com>
parent: Andreas <maps.on@gmx.net>
0 siblings, 0 replies; 131+ messages in thread
From: John Sidney-Woollett @ 2003-12-31 11:12 UTC (permalink / raw)
To: Andreas <maps.on@gmx.net>; +Cc: pgsql-general
Here is some info (see below).
Andrew Rawnsley gave some quite good feedback, and an offer of his
modified version eRServer - try checking the archives for more info, or
e-mail me in about 4 weeks time when I will have installed (hopefully) a
replication solution.
John Sidney-Woollett
> Id there a definitive list of what replication options are currently
> available for 7.4 (and 7.5), and what their relative strengths and
> weaknesses are; ease of use, configuration, cost, support etc
>
> I need to start tackling replication of our DB in the next few weeks,
> and
> wondered what the options are.
>
> I've seen RServer and Mammoth Replication - these look good (on paper)
> but
> both appear to involve a license fee (which is more than I have to
> spend
> right now).
There's 2 versions of eRServer - v1.2 is free on gborg and Postgresql,
Inc. has another
that you get with a support contract.
I've patched eRServer pretty heavily to fix some bugs and add some
usability. The
eRServer list has some discussion of these.
Jan Weick is in the early stages of developing a new replication system
that
looks to be pretty nice. He also has a project set up on gborg.
In addition, RServ (what eRServer was based on) is still going, along
with dbmirror
(which is in contrib in the main distribution).
Mammoth is something you would have to ask Joshua Drake about. Don't
know anything about it.
>
> Is pgReplication ready for 7.4 yet? And are there any other *free*
> options? If not maybe I'll have to find the money for a commercial
> solution.
Doesn't look like based on the web site at gborg.
>
> I'd appreciate any feedback from anyone who has a working replication
> solution.
>
So far eRServer is working ok for me. If you use the unpatched version
on gborg, be sure to
read the erserver list archives, as the current tarball has a problem
or two. If you want to
work with my fork let me know. I like to think it works better, but I'm
hardly unbiased...
> Thanks
>
> John Sidney-Woollett
>
>
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 9: the planner will ignore your desire to choose an index scan if
> your
> joining column's datatypes do not match
>
--------------------
Andrew Rawnsley
President
The Ravensfield Digital Resource Group, Ltd.
(740) 587-0114
www.ravensfield.com
Andreas said:
> Hello list,
>
> did someone try successfully to use the replication extension that was
> released to the community this summer ?
>
> Maybe someone could share his/her impressions and produce a tiny
> description what to do to actually build the extension, install and
> connect 2 servers so they share the sql that is thrown at them.
>
>
> Watch your way when you step over into 2004 later today ;)
>
> Andreas
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 8: explain analyze is your friend
>
^ permalink raw reply [nested|flat] 131+ messages in thread
* Re: Replication
@ 2004-02-19 18:10 Joshua D. Drake <jd@commandprompt.com>
parent: Andrew Rawnsley <ronz@ravensfield.com>
1 sibling, 0 replies; 131+ messages in thread
From: Joshua D. Drake @ 2004-02-19 18:10 UTC (permalink / raw)
To: Andrew Rawnsley <ronz@ravensfield.com>; +Cc: pgsql-general
>
> Mammoth is something you would have to ask Joshua Drake about. Don't
> know anything about it.
Just FYI: There is very detailed information about Mammoth Replicator
located here:
http://www.commandprompt.com/entry.lxp?lxpe=304
Sincerely,
Joshua D. Drake
>
>>
>> Is pgReplication ready for 7.4 yet? And are there any other *free*
>> options? If not maybe I'll have to find the money for a commercial
>> solution.
>
>
> Doesn't look like based on the web site at gborg.
>
>>
>> I'd appreciate any feedback from anyone who has a working replication
>> solution.
>>
>
> So far eRServer is working ok for me. If you use the unpatched version
> on gborg, be sure to
> read the erserver list archives, as the current tarball has a problem or
> two. If you want to
> work with my fork let me know. I like to think it works better, but I'm
> hardly unbiased...
>
>> Thanks
>>
>> John Sidney-Woollett
>>
>>
>>
>> ---------------------------(end of broadcast)---------------------------
>> TIP 9: the planner will ignore your desire to choose an index scan if
>> your
>> joining column's datatypes do not match
>>
> --------------------
>
> Andrew Rawnsley
> President
> The Ravensfield Digital Resource Group, Ltd.
> (740) 587-0114
> www.ravensfield.com
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
--
Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC
Postgresql support, programming shared hosting and dedicated hosting.
+1-503-667-4564 - jd@commandprompt.com - http://www.commandprompt.com
Mammoth PostgreSQL Replicator. Integrated Replication for PostgreSQL
Attachments:
[text/x-vcard] jd.vcf (638B, ../../4034FC21.7070601@commandprompt.com/2-jd.vcf)
download | inline:
begin:vcard
fn:Joshua D. Drake
n:Drake;Joshua D.
org:Command Prompt, Inc.
adr:;;PO Box 215;Cascade Locks;Oregon;97014;USA
email;internet:jd@commandprompt.com
title:Consultant
tel;work:503-667-4564
tel;fax:503-210-0034
note:Command Prompt, Inc. is the largest and oldest US based commercial PostgreSQL support provider. We provide the only commercially viable integrated PostgreSQL replication solution, but also custom programming, and support. We authored the book Practical PostgreSQL, the procedural language plPHP, and adding trigger capability to plPerl.
x-mozilla-html:FALSE
url:http://www.commandprompt.com/
version:2.1
end:vcard
^ permalink raw reply [nested|flat] 131+ messages in thread
* Replication
@ 2004-04-20 09:26 Pailloncy Jean-Gérard <pailloncy@ifrance.com>
0 siblings, 1 reply; 131+ messages in thread
From: Pailloncy Jean-Gérard @ 2004-04-20 09:26 UTC (permalink / raw)
To: pgsql-general
Hi,
I just see that Mysql will propose at the end of the month a full
synchronous replication system with auto-recovery.
http://www.mysql.com/products/cluster/
We need to see when stable version would be released.....
I use PostgreSQL and I would appreciate to have the same features in
PostgreSQL.
Any comments ? (no flame, please)
Cordialement,
Jean-Gérard Pailloncy
^ permalink raw reply [nested|flat] 131+ messages in thread
* Re: Replication
@ 2004-04-20 11:51 Andrew Sullivan <ajs@crankycanuck.ca>
parent: Pailloncy Jean-Gérard <pailloncy@ifrance.com>
0 siblings, 1 reply; 131+ messages in thread
From: Andrew Sullivan @ 2004-04-20 11:51 UTC (permalink / raw)
To: pgsql-general
On Tue, Apr 20, 2004 at 11:26:24AM +0200, Pailloncy Jean-G?rard wrote:
> Hi,
>
> I just see that Mysql will propose at the end of the month a full
> synchronous replication system with auto-recovery.
Well, sort of. It seems to be yet another 80/20 Solution From MySQL
(tm).
It looks like it's based on a new table type. It stores everything
in memory, and then writes out asynchronously. This strikes me as
pretty dangerous from the point of view of reliability: what if the
box dies before the write is complete? (And don't tell me about
super-redundant high-availability hardware. I _have_ all that. All
hardware sucks; HA stuff just sucks less often at a higher price.)
Also, it doesn't support the other table types. I don't want to
contemplate the horrible mess you'd have to clean up if you had a
transaction crossing three table types and get a hardware failure.
I'm afraid I agree with the recently-posted Oracle Veep interview:
this does not represent any serious challenge to the core ORAC
market.
> I use PostgreSQL and I would appreciate to have the same features in
> PostgreSQL.
Sure, so would I. Talk to Jan Wieck about what he plans to do
about it, and maybe consider supporting that development work too ;-)
A
--
Andrew Sullivan | ajs@crankycanuck.ca
^ permalink raw reply [nested|flat] 131+ messages in thread
* Re: Replication
@ 2004-04-21 15:23 Jan Wieck <JanWieck@Yahoo.com>
parent: Andrew Sullivan <ajs@crankycanuck.ca>
0 siblings, 1 reply; 131+ messages in thread
From: Jan Wieck @ 2004-04-21 15:23 UTC (permalink / raw)
To: Andrew Sullivan <ajs@crankycanuck.ca>; +Cc: pgsql-general
Andrew Sullivan wrote:
> On Tue, Apr 20, 2004 at 11:26:24AM +0200, Pailloncy Jean-G?rard wrote:
>> Hi,
>>
>> I just see that Mysql will propose at the end of the month a full
>> synchronous replication system with auto-recovery.
>
> Well, sort of. It seems to be yet another 80/20 Solution From MySQL
> (tm).
>
> It looks like it's based on a new table type. It stores everything
> in memory, and then writes out asynchronously. This strikes me as
> pretty dangerous from the point of view of reliability: what if the
> box dies before the write is complete? (And don't tell me about
> super-redundant high-availability hardware. I _have_ all that. All
> hardware sucks; HA stuff just sucks less often at a higher price.)
> Also, it doesn't support the other table types. I don't want to
> contemplate the horrible mess you'd have to clean up if you had a
> transaction crossing three table types and get a hardware failure.
>
> I'm afraid I agree with the recently-posted Oracle Veep interview:
> this does not represent any serious challenge to the core ORAC
> market.
Quoting from the MySQL(tm) FAQ about MySQL(tm) Cluster(tm) avaliable at
http://www.mysql.com/products/cluster/faq.html
<quote>
Q: Does MySQL Cluster work with MyISAM and InnoDB?
A: MySQL Cluster can include the MyISAM and InnoDB storage engines. Of
these, the high-availability data must reside in the MySQL Cluster
storage engine.
The MySQL Cluster DB node stores MySQL Cluster data, the MySQL Server
parses SQL and sends requests to the DB node. The MySQL Server does not
store any data belonging to the MySQL Cluster storage engine.
InnoDB/MyISAM data is still stored in the MySQL server and can be used
in the standard way, but that data is not replicated, so that data is
not visible from any other MySQL server that is connected to the MySQL
Cluster.
</quote>
It is just another table handler made available for the SQL query
engine. Touting loudly and on all available channels that "MySQL Cluster
combines the world's most popular open source database with a
parallel-server" naturally leads to the misinterpretation that all the
wonderfull new features like foreign keys, MVCC and rollback will now
horizontally scale over multiple, high available nodes. This is not true.
The NDB table type does not have support for foreign keys, constraints,
triggers. It does support transactions, but these transactions are not
the same transactions as the ones of the InnoDB table handler, so a
COMMIT is not atomic across different table types. MySQL likes to point
out that the largest systems like SAP R/3 do not use referential
integrity on the database level. That is true so far, but having worked
for many years as an SAP base consultant I can tell you that the reason
for that is NOT performance. SAP spends that effort multiple times by
implementing their own, custom integrity control and data domain system
in the DB abstraction layer, to gain DB vendor independence. That
abstraction layer is larger than PHP and Apache together, so this
example is IMHO totally irrelevant for the typical MySQL user.
Also, the NDB table type is based on an in-memory, partitioned storage
engine (that's where the speed comes from) and to get high availablility
one needs at least two times the full database size in RAM (plus some
for the OS and other overhead), and a higher factor to really achieve
the 99.999%. So to serve let's say a 100 GB database, we're talking
about 220-240 GB of RAM. Now that's 8 boxes with 32GB each? And
according to a MySQL consultant I spoke with, the real bottleneck is the
network, so these boxes like to have "better than Gigabit Ethernet" as a
backbone. That are some decent hardware requirements, make sure you have
a forklift on your next shopping list.
So what one gets with NDB on the bottom line is another table type that
is usefull for some special cases. I can imagine for example systems
that read sensor data, which cannot be interrupted. Sensors usually
don't care much about referential integrity, so for the logging system
this is in fact irrelevant, the data has to be stored now and corrected
later. I think it is indeed a big plus for a system, to make that
logging data available inside the same SQL query engine where the more
complicated bits and pieces of the application are implemented in. But
that is all, and that can pretty easy be achieved by doing bulk-loads of
the log data into regular database tables. Unless one really needs the
ability to query and analyse up to the last second of logdata, running
some multiple 100 kilodollar hardware and network equipment just for the
fun of a memory cluster solution is a bit overkill.
As the Oracle VP of product strategy, Ken Jacobs, pointed out: "MySQL is
trying to address certain product shortcomings by acquiring a
third-party technology. This does not mean they now have a product that
is competitive with Oracle—or even other—database products, whether
clustered or not.". Absolutely right Mr. Jacobs, they have done that
before by adding InnoDB, now they added some limited multimaster
replication capabilities. But instead of developing an integrated
solution that includes the InnoDB table handler, where this
functionality would be usefull, they just added a fifth wheel to the cart.
>
>> I use PostgreSQL and I would appreciate to have the same features in
>> PostgreSQL.
>
> Sure, so would I. Talk to Jan Wieck about what he plans to do
> about it, and maybe consider supporting that development work too ;-)
Ken Jacobs further said "No one has anything at all like Oracle's Real
Application Clusters". And that is right too. However good PostgreSQL by
now compares on SQL features and standalone DB performance. On
replication we are 2 years or more behind.
Right now we need to get the Slony-I project out the door and let that
settle a bit and maybe get enhanced over one more release. With that as
the base, we will start designing a synchronous multimaster system that
can be jump-started from a running, asynchronous replication setup. All
this "high-availability" babble is IMHO totally pointless as long as
there is no way of (re)creataing a (failed) node from scratch without
taking an outage. And that functionality is listed on the MySQL roadmap
for 5.1 ... so somewhere in 2008? Slony does that for async master-slave
right today.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #
^ permalink raw reply [nested|flat] 131+ messages in thread
* Re: Replication
@ 2004-04-21 17:28 Andrew Sullivan <ajs@crankycanuck.ca>
parent: Jan Wieck <JanWieck@Yahoo.com>
0 siblings, 2 replies; 131+ messages in thread
From: Andrew Sullivan @ 2004-04-21 17:28 UTC (permalink / raw)
To: pgsql-general
On Wed, Apr 21, 2004 at 11:23:51AM -0400, Jan Wieck wrote:
> for that is NOT performance. SAP spends that effort multiple times by
> implementing their own, custom integrity control and data domain system
> in the DB abstraction layer, to gain DB vendor independence. That
> abstraction layer is larger than PHP and Apache together, so this
> example is IMHO totally irrelevant for the typical MySQL user.
Actually, I think it _is_ relevant. It's proof, IMNSHO, that the
strategy of "doing it in the client" is completely bankrupt. It's
one thing to do it this way if you have software which is a
category-killer the way SAP is, because you can afford the overhead
of all those developers doing all that extra work, and you can make
your customers buy trillion-dollar hardware to run your bloated
masterpiece. The Rest Of Us, however, need to do things efficiently,
and that means doing the work in the place where it is least likely
to need to be checked again. For most database applications, that's
inside the database. (I'll not now start my rant on the mess caused
by developers who are careless with this principle.)
A
--
Andrew Sullivan | ajs@crankycanuck.ca
The plural of anecdote is not data.
--Roger Brinner
^ permalink raw reply [nested|flat] 131+ messages in thread
* Re: Replication
@ 2004-04-21 22:39 Uwe C. Schroeder <uwe@oss4u.com>
parent: Andrew Sullivan <ajs@crankycanuck.ca>
1 sibling, 1 reply; 131+ messages in thread
From: Uwe C. Schroeder @ 2004-04-21 22:39 UTC (permalink / raw)
To: Andrew Sullivan <ajs@crankycanuck.ca>; pgsql-general
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Wednesday 21 April 2004 10:28 am, Andrew Sullivan wrote:
> On Wed, Apr 21, 2004 at 11:23:51AM -0400, Jan Wieck wrote:
> > for that is NOT performance. SAP spends that effort multiple times by
> > implementing their own, custom integrity control and data domain system
> > in the DB abstraction layer, to gain DB vendor independence. That
> > abstraction layer is larger than PHP and Apache together, so this
> > example is IMHO totally irrelevant for the typical MySQL user.
>
> Actually, I think it _is_ relevant. It's proof, IMNSHO, that the
> strategy of "doing it in the client" is completely bankrupt. It's
> one thing to do it this way if you have software which is a
> category-killer the way SAP is, because you can afford the overhead
> of all those developers doing all that extra work, and you can make
> your customers buy trillion-dollar hardware to run your bloated
> masterpiece. The Rest Of Us, however, need to do things efficiently,
> and that means doing the work in the place where it is least likely
> to need to be checked again. For most database applications, that's
> inside the database. (I'll not now start my rant on the mess caused
> by developers who are careless with this principle.)
I concur. However the problem SAP had some 18years ago when they invented
their system were massive differences between databases. The scope they had
in mind didn't allow for whole database layers to be redundant just for the
sake of being able to talk to several database engines - ergo they wrote one
layer and omitted using vendor dependant database features.
Nowadays most relevant databases are pretty compatible when it comes to
constraints, so if you stick to the basics you should be fine now.
UC
- --
Open Source Solutions 4U, LLC 2570 Fleetwood Drive
Phone: +1 650 872 2425 San Bruno, CA 94066
Cell: +1 650 302 2405 United States
Fax: +1 650 872 2417
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
iD8DBQFAhvgKjqGXBvRToM4RAmy1AJ9q2n44+9KFAp+o2u3NPqR6DISyGACePO6V
a6L/yfArAk3m0N6lSQVDx0k=
=dRNi
-----END PGP SIGNATURE-----
^ permalink raw reply [nested|flat] 131+ messages in thread
* Re: Replication
@ 2004-04-22 02:08 Christopher Browne <cbbrowne@acm.org>
parent: Andrew Sullivan <ajs@crankycanuck.ca>
1 sibling, 2 replies; 131+ messages in thread
From: Christopher Browne @ 2004-04-22 02:08 UTC (permalink / raw)
To: pgsql-general
Martha Stewart called it a Good Thing when ajs@crankycanuck.ca (Andrew Sullivan) wrote:
> On Wed, Apr 21, 2004 at 11:23:51AM -0400, Jan Wieck wrote:
>> for that is NOT performance. SAP spends that effort multiple times
>> by implementing their own, custom integrity control and data domain
>> system in the DB abstraction layer, to gain DB vendor
>> independence. That abstraction layer is larger than PHP and Apache
>> together, so this example is IMHO totally irrelevant for the
>> typical MySQL user.
>
> Actually, I think it _is_ relevant. It's proof, IMNSHO, that the
> strategy of "doing it in the client" is completely bankrupt. It's
> one thing to do it this way if you have software which is a
> category-killer the way SAP is, because you can afford the overhead
> of all those developers doing all that extra work, and you can make
> your customers buy trillion-dollar hardware to run your bloated
> masterpiece. The Rest Of Us, however, need to do things
> efficiently, and that means doing the work in the place where it is
> least likely to need to be checked again. For most database
> applications, that's inside the database. (I'll not now start my
> rant on the mess caused by developers who are careless with this
> principle.)
There's a further issue, namely that these "bankrupt" ways were
adopted literally decades ago, and involve the "trillion-dollar"
investments.
Way back when, R/2 was implemented on MVS using IMS, and SAP
implemented their own toolset to manage that, including their own
more-or-less-implicit transaction manager. Thirty years later, they
have ported it to run on systems that didn't exist back then, but it's
still, in essence, a "mainframe" thing, even if you're running it atop
Windows NT and Microsoft's port of Sybase. It persists because
there's 30 years worth of ABAP/4 code customized for a zillion
purposes that SAP can keep on selling.
The problem is not one of carelessness; it is that R/2 was written to
run on databases like IMS, a pre-relational hierarchical system, and
Adabas, which couldn't support having more than 256 tables, once upon
a time... They had to create an ad-hoc variation on CICS, and
starting from scratch would cost trillions.
Even they couldn't afford that. Microsoft has been trying to do some
"reinvention" of Windows in the new "Longhorn" thing, and despite
having $Billion$ in the bank, it looks like those ambitions are dying
the death of a thousand paper cuts.
Jan's right, in that the typical MySQL user that's building an
unambitious little PHP application doesn't care about the extra
layers. They wouldn't have bought CICS, whether from IBM or from BEA,
or something more modern, like Tuxedo; if they're using MySQL as a
step up from MS Access, "doing things right" wasn't a notion that they
had in their heads to even contemplate.
It's like deciding to prefer Windows because if you visit Office
Depot, Staples, CompUSA, and Circuit City, that's the only system you
see boxed software for; it's not a measure of goodness, but merely the
fact that it's visible, and can be made serviceable enough.
Sleepycat DB can accurately claim to have hundreds of millions of
deployments simply out of the fact that practically every Linux system
links to it. (I see 67 programs in my /usr/bin that link to
libdb3.so.3...) They're obviously far and away the "most popular open
source database." Entertainingly enough, they have a replication
system, too, and even an XA interface to support 2PC :-). No SQL,
though...
--
"cbbrowne","@","acm.org"
http://www.ntlug.org/~cbbrowne/linux.html
Why do we drive on parkways and park on driveways?
^ permalink raw reply [nested|flat] 131+ messages in thread
* Re: Replication
@ 2004-04-22 02:09 Christopher Browne <cbbrowne@acm.org>
parent: Uwe C. Schroeder <uwe@oss4u.com>
0 siblings, 0 replies; 131+ messages in thread
From: Christopher Browne @ 2004-04-22 02:09 UTC (permalink / raw)
To: pgsql-general
Quoth uwe@oss4u.com ("Uwe C. Schroeder"):
> I concur. However the problem SAP had some 18years ago when they
> invented their system were massive differences between
> databases. The scope they had in mind didn't allow for whole
> database layers to be redundant just for the sake of being able to
> talk to several database engines - ergo they wrote one layer and
> omitted using vendor dependant database features. Nowadays most
> relevant databases are pretty compatible when it comes to
> constraints, so if you stick to the basics you should be fine now.
One of the issues was always that of locking. Different systems still
have different semantics.
--
output = reverse("gro.gultn" "@" "enworbbc")
http://www.ntlug.org/~cbbrowne/nonrdbms.html
I've implemented a parser combinator library in Generic C#, and indeed
what is pretty clear in a functional language looks extremely
scientific in an object-oriented one. -- Peter Sestoft
^ permalink raw reply [nested|flat] 131+ messages in thread
* Re: Replication
@ 2004-04-22 13:42 Eric Comeau <eric.comeau@signiant.com>
0 siblings, 1 reply; 131+ messages in thread
From: Eric Comeau @ 2004-04-22 13:42 UTC (permalink / raw)
To: pgsql-general
>
> On Tue, Apr 20, 2004 at 11:26:24AM +0200, Pailloncy Jean-G?rard wrote:
> > Hi,
> >
> > I just see that Mysql will propose at the end of the month a full
> > synchronous replication system with auto-recovery.
>
> Well, sort of. It seems to be yet another 80/20 Solution From MySQL
> (tm).
>
> It looks like it's based on a new table type. It stores everything
> in memory, and then writes out asynchronously. This strikes me as
> pretty dangerous from the point of view of reliability: what if the
> box dies before the write is complete? (And don't tell me about
> super-redundant high-availability hardware. I _have_ all that. All
> hardware sucks; HA stuff just sucks less often at a higher price.)
> Also, it doesn't support the other table types. I don't want to
> contemplate the horrible mess you'd have to clean up if you had a
> transaction crossing three table types and get a hardware failure.
>
> I'm afraid I agree with the recently-posted Oracle Veep interview:
> this does not represent any serious challenge to the core ORAC
> market.
What is Oracle selling as their replication solution these days?
When I still had a MetaLink userid they had posted a
"Product Obsolescence Desupport Notice"
for
"Oracle Replication Services"
The dates where something like:
Desupport End Dates
Error Correction Support: 01-SEP-2002
Extended Assistance Support: 01-SEP-2005
Oracle Recommended customers upgrade/migrate to the following...
which was no migration path exits, as no new versions will be release
and no replacement product is available
Their ORAC if I understand it correctly is a "cluster" solution and
no a "replication" solution.
Guess I should visit their web site and see what they are pedaling for
replication over WAN links these days.
>
> > I use PostgreSQL and I would appreciate to have the same
> features in
> > PostgreSQL.
>
> Sure, so would I. Talk to Jan Wieck about what he plans to do
> about it, and maybe consider supporting that development work too ;-)
>
> A
>
> --
> Andrew Sullivan | ajs@crankycanuck.ca
>
^ permalink raw reply [nested|flat] 131+ messages in thread
* Re: Replication
@ 2004-04-22 14:18 Michael Chaney <mdchaney@michaelchaney.com>
parent: Christopher Browne <cbbrowne@acm.org>
1 sibling, 0 replies; 131+ messages in thread
From: Michael Chaney @ 2004-04-22 14:18 UTC (permalink / raw)
To: pgsql-general
On Wed, Apr 21, 2004 at 10:08:07PM -0400, Christopher Browne wrote:
> or something more modern, like Tuxedo; if they're using MySQL as a
> step up from MS Access,
^^
That's spelled "down". Access is almost 100% SQL-92 compliant, allows
subselects, and does pretty good query optimization. MySQL has nothing
on it. And, no, I'm not some Microsofty.
Michael
--
Michael Darrin Chaney
mdchaney@michaelchaney.com
http://www.michaelchaney.com/
^ permalink raw reply [nested|flat] 131+ messages in thread
* Re: Replication
@ 2004-04-22 18:40 Andrew Sullivan <ajs@crankycanuck.ca>
parent: Christopher Browne <cbbrowne@acm.org>
1 sibling, 0 replies; 131+ messages in thread
From: Andrew Sullivan @ 2004-04-22 18:40 UTC (permalink / raw)
To: pgsql-general
On Wed, Apr 21, 2004 at 10:08:07PM -0400, Christopher Browne wrote:
> The problem is not one of carelessness;
No, I agree that in SAP's case it wasn't carelessness. As you say,
that was a long time ago. What I am arguing is that it is careless
to design things using that approach today. And people do.
A
--
Andrew Sullivan | ajs@crankycanuck.ca
^ permalink raw reply [nested|flat] 131+ messages in thread
* Re: Replication
@ 2004-04-26 18:23 Andrew Sullivan <ajs@crankycanuck.ca>
parent: Eric Comeau <eric.comeau@signiant.com>
0 siblings, 0 replies; 131+ messages in thread
From: Andrew Sullivan @ 2004-04-26 18:23 UTC (permalink / raw)
To: pgsql-general
On Thu, Apr 22, 2004 at 09:42:12AM -0400, Eric Comeau wrote:
>
> What is Oracle selling as their replication solution these days?
[. . .]
> Their ORAC if I understand it correctly is a "cluster" solution and
> no a "replication" solution.
This is an example of why I think most of the discussion about
"replication" is so confusing. ORAC is certainly a kind of
replication: it provides always-on, hot redundancy in a cluster of
machines. It's multi-master, and something very close to
asynchronous. It's a _very_ clever system, but it'll do you not one
whit of good if your primary site fails. Also, it's not suitable for
use on unreliable hardware: every cluster member failure causes a
"remastering" event which causes everything to stop while remastering
happens. Finally, it requires some nifty but expensive storage --
storage which itself could be a single point of failure, if it failed
in the right ways.
To solve all of that, Oracle also offers Data Guard. This is
basically a standard log-shipping technique. The off-site "standby"
databases can't be used while in standby mode. This has all the
standard caveats of asynchronous WAN replication, not least of which
is that if you processed a $100 million transaction right before your
master failed, and then you recovered onto a slave which didn't have
that last moment of data, you might find yourself making a $100
million mistake.
So, Oracle Corp offers two different ways to keeo you up nights. :)
I'm sure they're both wonderful products. But they certainly don't
have a one-size-fits-all approach.
A
--
Andrew Sullivan | ajs@crankycanuck.ca
^ permalink raw reply [nested|flat] 131+ messages in thread
* replication
@ 2004-06-08 15:31 David Parker <dparker@tazznetworks.com>
0 siblings, 1 reply; 131+ messages in thread
From: David Parker @ 2004-06-08 15:31 UTC (permalink / raw)
To: pgsql-general
Hi. I'm new to postgresql in general, and have been tasked with coming
up with a replication solution for our postgresql based application.
Assuming we don't bite off trying to roll our own solution, it looks
like the open-source options for replication are:
1) contrib/rserv
2) erserver
3) slony
4) pgreplication
From looking at the code, it looks like contrib/rserv might have evolved
into erserver. I'm curious what the motivation for starting the new
slony replication project was - is it intended to address short-comings
in erserver? There has been some traffic on the list today about the
pgreplication project, too, but I haven't had a chance to look at it
yet. Is anybody using it?
Of course there's nothing that says there can't be multiple replication
solutions for postgresql, but as somebody just coming into the
community, I have NO idea what the relationship between them is, or if
anybody is even doing replication.
I realize that this is a very general question, and I don't expect an
essay comparing the various solutions, but hearing the
thoughts/impressions of anybody who has used any of these packages would
be a huge help to me.
Thanks!
- DAP
======================================================
David Parker Tazz Networks (401) 709-5130
^ permalink raw reply [nested|flat] 131+ messages in thread
* Re: replication
@ 2004-06-09 17:27 Jan Wieck <JanWieck@Yahoo.com>
parent: David Parker <dparker@tazznetworks.com>
0 siblings, 0 replies; 131+ messages in thread
From: Jan Wieck @ 2004-06-09 17:27 UTC (permalink / raw)
To: David Parker <dparker@tazznetworks.com>; +Cc: pgsql-general
On 6/8/2004 11:31 AM, David Parker wrote:
> Hi. I'm new to postgresql in general, and have been tasked with coming
> up with a replication solution for our postgresql based application.
> Assuming we don't bite off trying to roll our own solution, it looks
> like the open-source options for replication are:
>
> 1) contrib/rserv
> 2) erserver
> 3) slony
> 4) pgreplication
5) contrib/dbmirror
>
>>From looking at the code, it looks like contrib/rserv might have evolved
> into erserver. I'm curious what the motivation for starting the new
> slony replication project was - is it intended to address short-comings
> in erserver? There has been some traffic on the list today about the
> pgreplication project, too, but I haven't had a chance to look at it
> yet. Is anybody using it?
The shortcomings of other replication systems was indeed the motivation
for Slony-I. One of the required features for Slony-I is the ability to
install and build up a new slave system without interruption of the
master. Another goal was the ability to inherit other slaves in the case
of promoting one slave to master. Point 1 might not seem too critical,
as there are only few environments that cannot stop their applications
sometimes for a few minutes. But the second problem is way more severe,
because without that ability there is no promotion of a slave to master.
Turning a former slave database into a single standalone system has
nothing to do with promotion to master!
ERserver could be enhanced to do point 1, but I don't see the ability to
satisfy goal #2 with it ever. Neither did I see the ability to add them
to dbmirror.
>
> Of course there's nothing that says there can't be multiple replication
> solutions for postgresql, but as somebody just coming into the
> community, I have NO idea what the relationship between them is, or if
> anybody is even doing replication.
Slony does not and will not fit the needs of anybody who's intending
something like dozens or hundreds of sporadic connecting and replicating
nodes (AKA the salesman on the street). It is designed for data centers
with few but reliably connected systems.
Replication is one of the millenium-buzzwords. But replication is not a
feature, it is many possible solutions for even more different and
possibly interconnected problems. So I would say "there must be multiple
replication solutions for postgresql".
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #
^ permalink raw reply [nested|flat] 131+ messages in thread
* replication
@ 2004-08-06 17:08 Si Chen <schen@graciousstyle.com>
0 siblings, 1 reply; 131+ messages in thread
From: Si Chen @ 2004-08-06 17:08 UTC (permalink / raw)
To: pgsql-general
Hello everyone.
Are there any recommended ways for doing postgresql replication?
Si Chen
^ permalink raw reply [nested|flat] 131+ messages in thread
* Re: replication
@ 2004-08-06 17:55 Joshua D. Drake <jd@commandprompt.com>
parent: Si Chen <schen@graciousstyle.com>
0 siblings, 3 replies; 131+ messages in thread
From: Joshua D. Drake @ 2004-08-06 17:55 UTC (permalink / raw)
To: schen@graciousstyle.com; +Cc: pgsql-general
Hello,
The two main replication products available are:
Slony-I and Mammoth Replicator.
Slony-I: Open Source, trigger based, batch replication.
Mammoth Replicator: Closed Source (source license available), integrated
(no triggers), live and batch replication.
They are both good solutions (I work for the creators of Mammoth
Replicator) that serve different purposes.
Sincerely,
Joshua D. Drake
Si Chen wrote:
> Hello everyone.
>
> Are there any recommended ways for doing postgresql replication?
> Si Chen
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
>
> http://archives.postgresql.org
--
Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC
Postgresql support, programming shared hosting and dedicated hosting.
+1-503-667-4564 - jd@commandprompt.com - http://www.commandprompt.com
Mammoth PostgreSQL Replicator. Integrated Replication for PostgreSQL
Attachments:
[text/x-vcard] jd.vcf (638B, ../../4113C627.9030205@commandprompt.com/2-jd.vcf)
download | inline:
begin:vcard
fn:Joshua D. Drake
n:Drake;Joshua D.
org:Command Prompt, Inc.
adr:;;PO Box 215;Cascade Locks;Oregon;97014;USA
email;internet:jd@commandprompt.com
title:Consultant
tel;work:503-667-4564
tel;fax:503-210-0034
note:Command Prompt, Inc. is the largest and oldest US based commercial PostgreSQL support provider. We provide the only commercially viable integrated PostgreSQL replication solution, but also custom programming, and support. We authored the book Practical PostgreSQL, the procedural language plPHP, and adding trigger capability to plPerl.
x-mozilla-html:FALSE
url:http://www.commandprompt.com/
version:2.1
end:vcard
^ permalink raw reply [nested|flat] 131+ messages in thread
* Re: replication
@ 2004-08-06 21:19 Marc G. Fournier <scrappy@postgresql.org>
parent: Joshua D. Drake <jd@commandprompt.com>
2 siblings, 0 replies; 131+ messages in thread
From: Marc G. Fournier @ 2004-08-06 21:19 UTC (permalink / raw)
To: Joshua D. Drake <jd@commandprompt.com>; +Cc: schen@graciousstyle.com; pgsql-general
On Fri, 6 Aug 2004, Joshua D. Drake wrote:
> Hello,
>
> The two main replication products available are:
>
> Slony-I and Mammoth Replicator.
>
> Slony-I: Open Source, trigger based, batch replication.
>
> Mammoth Replicator: Closed Source (source license available), integrated (no
> triggers), live and batch replication.
>
> They are both good solutions (I work for the creators of Mammoth Replicator)
> that serve different purposes.
eRServer is deployed in over a half dozen commercial enterprises, in
several cases doing replication across WANs ... so there are actually
three "main" ones ...
----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
^ permalink raw reply [nested|flat] 131+ messages in thread
* Re: replication
@ 2004-08-09 13:31 Jan Wieck <JanWieck@Yahoo.com>
parent: Joshua D. Drake <jd@commandprompt.com>
2 siblings, 0 replies; 131+ messages in thread
From: Jan Wieck @ 2004-08-09 13:31 UTC (permalink / raw)
To: Joshua D. Drake <jd@commandprompt.com>; +Cc: schen@graciousstyle.com; pgsql-general
On 8/6/2004 1:55 PM, Joshua D. Drake wrote:
> Hello,
>
> The two main replication products available are:
>
> Slony-I and Mammoth Replicator.
>
> Slony-I: Open Source, trigger based, batch replication.
>
> Mammoth Replicator: Closed Source (source license available), integrated
> (no triggers), live and batch replication.
Out of curiosity, what is the difference between live and batch
replication?
Slony-I has shown recently that it can achieve replication lags down to
a second average, with sporadic spikes up to several seconds on packet
loss in a WAN setup. That was replicating to a virtual machine running
on a notebook and the DB connections ssh-tunneled over two wireless
links and the internet ... not exactly what one would call a production
grade network connection. The server was running a TPC-W ordering mix at
that time, processing about 60,000 transactions per hour resulting in
15,000 row updates per hour (the PHP session data was DB-based and
replicated too). A 10 hour fallback of the replica (the slave system was
moved from Philadelphia to Toronto and back a weekend later :-) ) was
cought up in 3 hours against the continuously running main server over
the WAN, and in about 1.5 hours back in the WLan.
>
> They are both good solutions (I work for the creators of Mammoth
> Replicator) that serve different purposes.
Right (and I am the initial creator of Slony-I). Slony-I as a pure
trigger based approach for example does not aim at fully automatic DDL
replication.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #
^ permalink raw reply [nested|flat] 131+ messages in thread
* Re: replication
@ 2004-08-11 18:37 Vivek Khera <khera@kcilink.com>
parent: Joshua D. Drake <jd@commandprompt.com>
2 siblings, 0 replies; 131+ messages in thread
From: Vivek Khera @ 2004-08-11 18:37 UTC (permalink / raw)
To: pgsql-general
>>>>> "JDD" == Joshua D Drake <jd@commandprompt.com> writes:
JDD> Mammoth Replicator: Closed Source (source license available),
JDD> integrated (no triggers), live and batch replication.
Also, limited platform availability for Mammoth (ie, no FreeBSD
solution.)
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Vivek Khera, Ph.D. Khera Communications, Inc.
Internet: khera@kciLink.com Rockville, MD +1-301-869-4449 x806
AIM: vivekkhera Y!: vivek_khera http://www.khera.org/~vivek/
^ permalink raw reply [nested|flat] 131+ messages in thread
* Replication
@ 2005-06-18 05:44 mojoscoobydoo@comcast.net
0 siblings, 0 replies; 131+ messages in thread
From: mojoscoobydoo@comcast.net @ 2005-06-18 05:44 UTC (permalink / raw)
To: pgsql-general
I have been searching for the ability for replication between postgresql database servers. Many of the solutions That I have seen either work only un*x or requires an expensive commercial license. I am looking something rather short term and maybe for a long term solution.
I came across this project which is Java based:
http://sourceforge.net/projects/daffodilreplica
http://www.daffodildb.com
Has anybody used this particular piece of software? And if so what do they think of it?
Thanks,
Jeffery
^ permalink raw reply [nested|flat] 131+ messages in thread
* Replication
@ 2005-06-18 05:54 Jeffery Reedy <mojoscoobydoo@yahoo.com>
0 siblings, 2 replies; 131+ messages in thread
From: Jeffery Reedy @ 2005-06-18 05:54 UTC (permalink / raw)
To: pgsql-general
I have been searching for the ability for replication between postgresql database servers. Many of the solutions That I have seen either work only un*x or requires an expensive commercial license. I am looking something rather short term and maybe for a long term solution.
I came across this project which is Java based:
http://sourceforge.net/projects/daffodilreplica
http://www.daffodildb.com
Has anybody used this particular piece of software? And if so what do they think of it?
Thanks,
Jeffery
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ permalink raw reply [nested|flat] 131+ messages in thread
* Re: Replication
@ 2005-06-18 14:27 Bruno Wolff III <bruno@wolff.to>
parent: Jeffery Reedy <mojoscoobydoo@yahoo.com>
1 sibling, 0 replies; 131+ messages in thread
From: Bruno Wolff III @ 2005-06-18 14:27 UTC (permalink / raw)
To: Jeffery Reedy <mojoscoobydoo@yahoo.com>; +Cc: pgsql-general
On Fri, Jun 17, 2005 at 22:54:59 -0700,
Jeffery Reedy <mojoscoobydoo@yahoo.com> wrote:
> I have been searching for the ability for replication between postgresql database servers. Many of the solutions That I have seen either work only un*x or requires an expensive commercial license. I am looking something rather short term and maybe for a long term solution.
I am not familiar with daffodil, but if you are interested in a free
replication system, you should at least take a look at Slony.
^ permalink raw reply [nested|flat] 131+ messages in thread
* Re: Replication
@ 2005-06-18 17:26 brew@theMode.com
parent: Jeffery Reedy <mojoscoobydoo@yahoo.com>
1 sibling, 0 replies; 131+ messages in thread
From: brew@theMode.com @ 2005-06-18 17:26 UTC (permalink / raw)
To: pgsql-general
Jeffery.....
> I have been searching for the ability for replication between postgresql
> database servers. Many of the solutions That I have seen either work
> only un*x or requires an expensive commercial license. I am looking
> something rather short term and maybe for a long term solution.
If you don't actually need replication, and your database isn't huge, you
could instead just keep a backup server. You could simply do an automated
pg_dumpall once a day (for instance), followed by an automated ftp,
followed by an automatic load into the backup database.
Guess you'd set it up as a service on windows, under *nix I use ssl rsync
and cron. In the event I have to use my backup website server at another
location (only once, so far) it's read only and only up to date from the
night before. But it's better than a nonworking website.
Of course I have a way to redirect the web requests, too.
Actually, now that I think about it, I put this together for my own use,
in my spare time, using machines I had available already. If I had to do
it for a client I would do it right (with replication, load sharing,
etc.).
This is one way to keep it simple, but it might not meet your needs,
though.
brew
==========================================================================
Strange Brew (brew@theMode.com)
Check out my Stock Option Covered Call website http://www.callpix.com
and my Musician's Online Database Exchange http://www.TheMode.com
==========================================================================
^ permalink raw reply [nested|flat] 131+ messages in thread
* Replication
@ 2005-09-12 11:52 barry@e-rm.co.uk
0 siblings, 4 replies; 131+ messages in thread
From: barry@e-rm.co.uk @ 2005-09-12 11:52 UTC (permalink / raw)
To: pgsql-general
Hi,
I currently have a postgresql 8 system which I want to replicate
(ideally in realtime) with a spare host in order to introduce some
redundancy - eg. if the master server dies then I've got a ready-to-go
backup. Switchover does not have to be automated.
I've looked into commandprompt.com's mammoth system, but it only
supports up to 1000 tables (the documentation doesn't mention this!) -
the database in question has more than 1000 tables, and adds new tables
regularly. Slony-I and pgpool apparently don't support dynamic
schemas, which I'd obviously need, so they're not quite up to the job
either.
I'm currently looking at some sort of hack-job with the WAL archives
(see http://www.issociate.de/board/index.php?t=msg&goto=443099), but
this looks like a slightly flaky approach - have I missed the obvious
solution? Is there any stable software available which can replicate a
large and dynamic number of tables?
Cheers,
Barry
^ permalink raw reply [nested|flat] 131+ messages in thread
* Re: Replication
@ 2005-09-12 13:32 Peter Eisentraut <peter_e@gmx.net>
parent: barry@e-rm.co.uk
3 siblings, 0 replies; 131+ messages in thread
From: Peter Eisentraut @ 2005-09-12 13:32 UTC (permalink / raw)
To: barry@e-rm.co.uk; +Cc: pgsql-general
Am Montag, 12. September 2005 13:52 schrieb barry@e-rm.co.uk:
> I currently have a postgresql 8 system which I want to replicate
Look at DRBD.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
^ permalink raw reply [nested|flat] 131+ messages in thread
* Re: Replication
@ 2005-09-12 15:13 Joshua D. Drake <jd@commandprompt.com>
parent: barry@e-rm.co.uk
3 siblings, 0 replies; 131+ messages in thread
From: Joshua D. Drake @ 2005-09-12 15:13 UTC (permalink / raw)
To: barry@e-rm.co.uk; +Cc: pgsql-general
barry@e-rm.co.uk wrote:
>I've looked into commandprompt.com's mammoth system, but it only
>supports up to 1000 tables (the documentation doesn't mention this!) -
>the database in question has more than 1000 tables, and adds new tables
>regularly. Slony-I and pgpool apparently don't support dynamic
>schemas, which I'd obviously need, so they're not quite up to the job
>either.
>
Actually the theorectical limit for the Mammoth system is 10,000 tables,
we have only tested up to 1000. This is metioned quite clearly on the
website.
It should be noted that if Slony-I won't do what you need then Mammoth
probably
would not either.
Although Mammoth can add new tables on the fly as long as those tables
are empty. If they are not empty they would cause a full sync to occur.
Sincerely,
Joshua D. Drake
>
>I'm currently looking at some sort of hack-job with the WAL archives
>(see http://www.issociate.de/board/index.php?t=msg&goto=443099), but
>this looks like a slightly flaky approach - have I missed the obvious
>solution? Is there any stable software available which can replicate a
>large and dynamic number of tables?
>
>Cheers,
>
>Barry
>
>
>---------------------------(end of broadcast)---------------------------
>TIP 4: Have you searched our list archives?
>
> http://archives.postgresql.org
>
--
Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240
PostgreSQL Replication, Consulting, Custom Programming, 24x7 support
Managed Services, Shared and Dedicated Hosting
Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/
^ permalink raw reply [nested|flat] 131+ messages in thread
* Re: Replication
@ 2005-09-12 22:29 Tatsuo Ishii <t-ishii@sra.co.jp>
parent: barry@e-rm.co.uk
3 siblings, 0 replies; 131+ messages in thread
From: Tatsuo Ishii @ 2005-09-12 22:29 UTC (permalink / raw)
To: barry@e-rm.co.uk; +Cc: pgsql-general
> I currently have a postgresql 8 system which I want to replicate
> (ideally in realtime) with a spare host in order to introduce some
> redundancy - eg. if the master server dies then I've got a ready-to-go
> backup. Switchover does not have to be automated.
>
> I've looked into commandprompt.com's mammoth system, but it only
> supports up to 1000 tables (the documentation doesn't mention this!) -
> the database in question has more than 1000 tables, and adds new tables
> regularly. Slony-I and pgpool apparently don't support dynamic
> schemas, which I'd obviously need, so they're not quite up to the job
> either.
pgpool(without Slony-I) replicates schema changes. And PGCluter too.
--
SRA OSS, Inc. Japan
Tatsuo Ishii
^ permalink raw reply [nested|flat] 131+ messages in thread
* Re: Replication
@ 2005-09-13 02:23 Simon Riggs <simon@2ndquadrant.com>
parent: barry@e-rm.co.uk
3 siblings, 2 replies; 131+ messages in thread
From: Simon Riggs @ 2005-09-13 02:23 UTC (permalink / raw)
To: barry@e-rm.co.uk; pgsql-general
Barry,
You can use PITR to archive transaction logs to a second server that is
kept in standby mode.
This will cope with any number of tables and cope with dynamic changes
to tables.
This is fairly straightforward and very low overhead.
Set archive_command to a program that transfers xlog files to second
server.
Then set restore_command on the second server to a program that loops
until the next file is available.
Switchover time is low.
Best Regards, Simon Riggs
> -----Original Message-----
> From: pgsql-general-owner@postgresql.org
> [mailto:pgsql-general-owner@postgresql.org]On Behalf Of
> barry@e-rm.co.uk
> Sent: 12 September 2005 04:52
> To: pgsql-general@postgresql.org
> Subject: [GENERAL] Replication
>
>
> Hi,
>
> I currently have a postgresql 8 system which I want to replicate
> (ideally in realtime) with a spare host in order to introduce some
> redundancy - eg. if the master server dies then I've got a ready-to-go
> backup. Switchover does not have to be automated.
>
> I've looked into commandprompt.com's mammoth system, but it only
> supports up to 1000 tables (the documentation doesn't mention this!) -
> the database in question has more than 1000 tables, and adds
> new tables
> regularly. Slony-I and pgpool apparently don't support dynamic
> schemas, which I'd obviously need, so they're not quite up to the job
> either.
>
> I'm currently looking at some sort of hack-job with the WAL archives
> (see http://www.issociate.de/board/index.php?t=msg&goto=443099), but
> this looks like a slightly flaky approach - have I missed the obvious
> solution? Is there any stable software available which can
> replicate a
> large and dynamic number of tables?
>
> Cheers,
>
> Barry
>
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 4: Have you searched our list archives?
>
> http://archives.postgresql.org
^ permalink raw reply [nested|flat] 131+ messages in thread
* Re: Replication
@ 2005-09-13 13:54 Tatsuo Ishii <t-ishii@sra.co.jp>
parent: Simon Riggs <simon@2ndquadrant.com>
1 sibling, 1 reply; 131+ messages in thread
From: Tatsuo Ishii @ 2005-09-13 13:54 UTC (permalink / raw)
To: simon@2ndquadrant.com; +Cc: barry@e-rm.co.uk; pgsql-general
> You can use PITR to archive transaction logs to a second server that is
> kept in standby mode.
>
> This will cope with any number of tables and cope with dynamic changes
> to tables.
>
> This is fairly straightforward and very low overhead.
> Set archive_command to a program that transfers xlog files to second
> server.
> Then set restore_command on the second server to a program that loops
> until the next file is available.
> Switchover time is low.
I thought there are some issues of log based replication (I don't
remeber details though). Have they been resolved recently?
--
SRA OSS, Inc. Japan
Tatsuo Ishii
^ permalink raw reply [nested|flat] 131+ messages in thread
* Re: Replication
@ 2005-09-13 15:39 Tom Lane <tgl@sss.pgh.pa.us>
parent: Simon Riggs <simon@2ndquadrant.com>
0 siblings, 0 replies; 131+ messages in thread
From: Tom Lane @ 2005-09-13 15:39 UTC (permalink / raw)
To: Simon Riggs <simon@2ndquadrant.com>; +Cc: Tatsuo Ishii <t-ishii@sra.co.jp>; barry@e-rm.co.uk; pgsql-general
"Simon Riggs" <simon@2ndquadrant.com> writes:
>> From: Tatsuo Ishii [mailto:t-ishii@sra.co.jp]
>> I thought there are some issues of log based replication (I don't
>> remeber details though). Have they been resolved recently?
> Yes, currently log-file based replication is not recommended when the
> transaction rate is either low or extremely variable.
The point being not that it doesn't work, but that it can take a long
time (or an unpredictable amount of time) for transactions to propagate
to the slave machine. You can kluge up a solution for this, ie, write a
cron job to copy the latest WAL segment file across to the slave once
a minute (or whatever your requirement for propagation delay is). But
we haven't gotten a standard solution into the code itself yet.
regards, tom lane
^ permalink raw reply [nested|flat] 131+ messages in thread
* Re: Replication
@ 2005-09-13 15:45 Russ Brown <pickscrape@gmail.com>
parent: Simon Riggs <simon@2ndquadrant.com>
1 sibling, 3 replies; 131+ messages in thread
From: Russ Brown @ 2005-09-13 15:45 UTC (permalink / raw)
To: pgsql-general
Simon Riggs wrote:
> Barry,
>
> You can use PITR to archive transaction logs to a second server that is
> kept in standby mode.
>
> This will cope with any number of tables and cope with dynamic changes
> to tables.
>
> This is fairly straightforward and very low overhead.
> Set archive_command to a program that transfers xlog files to second
> server.
> Then set restore_command on the second server to a program that loops
> until the next file is available.
> Switchover time is low.
>
Apologies for going slighly off topic, but isn't this basically how
MySQL does replication? I ask because one of the arguments against
moving to PostgreSQL in my organisation is 'no replication out of the
box'. But if the above is true it seems that all that is required are a
couple of scripts to handle log transfer and you have a form of
replication out of the box right there.
Or am I missing something?
--
Russ
^ permalink raw reply [nested|flat] 131+ messages in thread
* Re: Replication
@ 2005-09-13 16:43 Csaba Nagy <nagy@ecircle-ag.com>
parent: Russ Brown <pickscrape@gmail.com>
2 siblings, 1 reply; 131+ messages in thread
From: Csaba Nagy @ 2005-09-13 16:43 UTC (permalink / raw)
To: Russ Brown <pickscrape@gmail.com>; +Cc: pgsql-general
Well, AFAICT this kind of replication in postgres is not be named "out
of the box". Setting up the whole thing to work, and test it to really
work reliably is not exactly trivial, and you could have a number of
surprises (like when there's little activity, the last WAL stays at the
server and so the stand-by can be off by a considerable amount of time,
even if in terms of data quantity the difference is not that big). You
must master well scripting to write reliable scripts to handle the
process, though I think there are some examples around, but you still
need to customize them for sure.
What is missing is an easy way to set up the hot stand-by, without
requiring the user to do too much side-work.
I wonder if there is a way to set up a direct link between the standby
and the server and instead of copying files just send directly the WAL
data over by some background process ? The overhead of sending the data
directly should be similar with copying the files. Then the easiest way
to set up a standby would be to start up the stand-by server with some
standby options and giving the server's connection params, and then the
standby should make a special connection to the server requesting a data
dump + WAL from the data dump start on. Would this be reasonably simple
to implement ? I'm not at all familiar with postgres code or the C
language, so this is just wishful thinking.
Cheers,
Csaba.
On Tue, 2005-09-13 at 17:45, Russ Brown wrote:
> Simon Riggs wrote:
> > Barry,
> >
> > You can use PITR to archive transaction logs to a second server that is
> > kept in standby mode.
> >
> > This will cope with any number of tables and cope with dynamic changes
> > to tables.
> >
> > This is fairly straightforward and very low overhead.
> > Set archive_command to a program that transfers xlog files to second
> > server.
> > Then set restore_command on the second server to a program that loops
> > until the next file is available.
> > Switchover time is low.
> >
>
> Apologies for going slighly off topic, but isn't this basically how
> MySQL does replication? I ask because one of the arguments against
> moving to PostgreSQL in my organisation is 'no replication out of the
> box'. But if the above is true it seems that all that is required are a
> couple of scripts to handle log transfer and you have a form of
> replication out of the box right there.
>
> Or am I missing something?
^ permalink raw reply [nested|flat] 131+ messages in thread
* Re: Replication
@ 2005-09-13 16:53 Welty, Richard <richard.welty@bankofamerica.com>
0 siblings, 0 replies; 131+ messages in thread
From: Welty, Richard @ 2005-09-13 16:53 UTC (permalink / raw)
To: Russ Brown <pickscrape@gmail.com>; pgsql-general
Russ Brown wrote:
>Apologies for going slighly off topic, but isn't this basically how
>MySQL does replication?
>Or am I missing something?
in the immortal words of mothers everywhere: "if all your friends
jumped off of a bridge, would you do it too?"
there are a lot of things that are "good enough" for mysql.
richard
^ permalink raw reply [nested|flat] 131+ messages in thread
* Re: Replication
@ 2005-09-13 18:45 Scott Marlowe <smarlowe@g2switchworks.com>
parent: Russ Brown <pickscrape@gmail.com>
2 siblings, 2 replies; 131+ messages in thread
From: Scott Marlowe @ 2005-09-13 18:45 UTC (permalink / raw)
To: Russ Brown <pickscrape@gmail.com>; +Cc: pgsql-general
On Tue, 2005-09-13 at 10:45, Russ Brown wrote:
> Simon Riggs wrote:
> > Barry,
> >
> > You can use PITR to archive transaction logs to a second server that is
> > kept in standby mode.
> >
> > This will cope with any number of tables and cope with dynamic changes
> > to tables.
> >
> > This is fairly straightforward and very low overhead.
> > Set archive_command to a program that transfers xlog files to second
> > server.
> > Then set restore_command on the second server to a program that loops
> > until the next file is available.
> > Switchover time is low.
> >
>
> Apologies for going slighly off topic, but isn't this basically how
> MySQL does replication? I ask because one of the arguments against
> moving to PostgreSQL in my organisation is 'no replication out of the
> box'. But if the above is true it seems that all that is required are a
> couple of scripts to handle log transfer and you have a form of
> replication out of the box right there.
>
> Or am I missing something?
I don't know, but someone in your organization seems to be.
Let me present it as a simple devil's choice, which would you rather
have, proven replication, that works, but requires you to setup a
secondary bit of software / system scripts (like rsync) but is tested
and proven to work, or, an "out of the box" solution that is untested,
unreliable, and possible unsafe for your data?
Chosing a database because it has "out of the box" replication without
paying attention to how it is implemented, how well it works, and what
are the ways it can break is a recipe for (data) disaster.
I've tested slony, and I know that for what we use it for, it's a good
fit and it works well. I've tested MySQL's replication, and it simply
can't do what I need from a replication system. It can't be setup on
the fly on a live system with no down time, and it has reliability
issues that make it a poor choice for a 24/7 enterprise replication
system.
That said, it's a great system for content management replication, where
downtime is fine while setting up replication.
But I wouldn't choose either because it was easier to implement. Being
easy to implement is just sauce on the turkey. I need the meat to be
good or the sauce doesn't matter.
^ permalink raw reply [nested|flat] 131+ messages in thread
* Re: Replication
@ 2005-09-13 19:00 Peter Eisentraut <peter_e@gmx.net>
parent: Russ Brown <pickscrape@gmail.com>
2 siblings, 0 replies; 131+ messages in thread
From: Peter Eisentraut @ 2005-09-13 19:00 UTC (permalink / raw)
To: Russ Brown <pickscrape@gmail.com>; +Cc: pgsql-general
Russ Brown wrote:
> Apologies for going slighly off topic, but isn't this basically how
> MySQL does replication?
The PostgreSQL WAL log stores information on the level of "write these
bytes to disk", the MySQL replication log stores information on the
level of "user called this statement". So in MySQL, inserting the
value of now() into a table might give different results if a slave
runs in a different time zone. So it's sort of the same from the
outside, but the internals are different and yield different
possibilities and restrictions.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
^ permalink raw reply [nested|flat] 131+ messages in thread
* Re: Replication
@ 2005-09-13 20:51 Russ Brown <pickscrape@gmail.com>
parent: Scott Marlowe <smarlowe@g2switchworks.com>
1 sibling, 2 replies; 131+ messages in thread
From: Russ Brown @ 2005-09-13 20:51 UTC (permalink / raw)
To: Scott Marlowe <smarlowe@g2switchworks.com>; +Cc: pgsql-general
Scott Marlowe wrote:
>
> I don't know, but someone in your organization seems to be.
>
Not just my organisation. I'm afraid this is an opinion I've seen in
many places.
> Let me present it as a simple devil's choice, which would you rather
> have, proven replication, that works, but requires you to setup a
> secondary bit of software / system scripts (like rsync) but is tested
> and proven to work, or, an "out of the box" solution that is untested,
> unreliable, and possible unsafe for your data?
>
Why does an "out of the box" solution have to be untested, unreliable
and possibly unsafe for my data?
How about a third choice: you can also use a proven, reliable and tested
replication solution that is included in the core system because the
core system basiclly provides it anyway. It's easy to set up, but (as
with all replication solutions) doesn't fit all purposes.
Depending on my requirements, I may well choose that one.
> Chosing a database because it has "out of the box" replication without
> paying attention to how it is implemented, how well it works, and what
> are the ways it can break is a recipe for (data) disaster.
>
Absolutely, but you're preaching to the converted here. I'm not
discussing which database I would choose. I was simply asking whether
the WAL logs would be utilised to create a simple replication solution
"Out of the box" with very little additional work on the part of the
developers.
> I've tested slony, and I know that for what we use it for, it's a good
> fit and it works well. I've tested MySQL's replication, and it simply
> can't do what I need from a replication system. It can't be setup on
> the fly on a live system with no down time, and it has reliability
> issues that make it a poor choice for a 24/7 enterprise replication
> system.
>
Again, I'm not asking whether MySQL's solution is any good or not. I'm
asking whether the WAL log could be used to provide a simple replication
solution out of the box. I am fully aware that no single replication
solution will fit all circumstances, but if PostgreSQL's core
functionality can provide one such solution anyway, why not add a couple
of scripts to make it all work out of the box and advertise the fact?
> That said, it's a great system for content management replication, where
> downtime is fine while setting up replication.
>
Precicely: one situation where this solution will work well, but nobody
knows about it because it's not pushed as a feature.
> But I wouldn't choose either because it was easier to implement. Being
> easy to implement is just sauce on the turkey. I need the meat to be
> good or the sauce doesn't matter.
>
Indeed. As said above, it has to be reliable, tested etc. I personally
fear a lot of the things our MySQL databases do to our data, and would
very much like to make the switch to PostgreSQL if allowed to do so.
There may be problems with MySQL's 'out of the box' replication
solution, but that doesn't mean that having one at all is a Bad Thing.
I can't help but think that had I just asked about the possibility of
using the WAL log idea for an 'out of the box' replication solution
without mentioning the word 'MySQL', the responses received would have
been very different.
--
Russ
^ permalink raw reply [nested|flat] 131+ messages in thread
* Re: Replication
@ 2005-09-13 22:01 Scott Marlowe <smarlowe@g2switchworks.com>
parent: Russ Brown <pickscrape@gmail.com>
1 sibling, 0 replies; 131+ messages in thread
From: Scott Marlowe @ 2005-09-13 22:01 UTC (permalink / raw)
To: Russ Brown <pickscrape@gmail.com>; +Cc: pgsql-general
On Tue, 2005-09-13 at 15:51, Russ Brown wrote:
> Scott Marlowe wrote:
> > Let me present it as a simple devil's choice, which would you rather
> > have, proven replication, that works, but requires you to setup a
> > secondary bit of software / system scripts (like rsync) but is tested
> > and proven to work, or, an "out of the box" solution that is untested,
> > unreliable, and possible unsafe for your data?
> >
>
> Why does an "out of the box" solution have to be untested, unreliable
> and possibly unsafe for my data?
It doesn't have to be. My main point was that many people assume that
since it's included and works out of the box that it MUST be tested and
reliable. MySQL's replication is not particularly reliable. As someone
who's done some "pull the plug" testing on it and PostgreSQL I can
confidently say that PostgreSQL and it's replication can survive fairly
nasty power / network failure modes, and MySQL's replication and db
engine seem much more prone to problems caused by such scenarios. So,
to me, it's "tested" but most definitely not proven reliable.
> How about a third choice: you can also use a proven, reliable and tested
> replication solution that is included in the core system because the
> core system basiclly provides it anyway. It's easy to set up, but (as
> with all replication solutions) doesn't fit all purposes.
If PostgreSQL provided it, I'd use it. But, I'd rather pick a
replication engine that I know works, having tested it, and wait for it
to be included in the back end at some future date.
> Depending on my requirements, I may well choose that one.
Since my first requirement is reliable replication, MySQL's replication
is out.
> > Chosing a database because it has "out of the box" replication without
> > paying attention to how it is implemented, how well it works, and what
> > are the ways it can break is a recipe for (data) disaster.
> >
>
> Absolutely, but you're preaching to the converted here. I'm not
> discussing which database I would choose. I was simply asking whether
> the WAL logs would be utilised to create a simple replication solution
> "Out of the box" with very little additional work on the part of the
> developers.
I think it's getting there. But like so many things PostgreSQL, it
won't be put into the core until it's considered mature and stable.
> I am fully aware that no single replication
> solution will fit all circumstances, but if PostgreSQL's core
> functionality can provide one such solution anyway, why not add a couple
> of scripts to make it all work out of the box and advertise the fact?
Because it's probably system dependent, i.e. the scripts / C programs
need to work on all the platforms supported by postgresql before it
would get included. If it only worked on Linux and / or BSD, it's not
done.
> > That said, it's a great system for content management replication, where
> > downtime is fine while setting up replication.
> >
>
> Precicely: one situation where this solution will work well, but nobody
> knows about it because it's not pushed as a feature.
Actually I was speaking of MySQL's replication there, in case that
wasn't clear (not sure if it was or not...)
Keep in mind, PITR just came out in release 6 months ago. It's not
really tested thoroughly, and the ways to set it up are probably varied
enough that there's no one way that's considered "Standard" just yet.
> > But I wouldn't choose either because it was easier to implement. Being
> > easy to implement is just sauce on the turkey. I need the meat to be
> > good or the sauce doesn't matter.
> >
>
> Indeed. As said above, it has to be reliable, tested etc. I personally
> fear a lot of the things our MySQL databases do to our data, and would
> very much like to make the switch to PostgreSQL if allowed to do so.
> There may be problems with MySQL's 'out of the box' replication
> solution, but that doesn't mean that having one at all is a Bad Thing.
It's not just what MySQL's db engine is willing to do to your data, it's
how its replication engine may fail and you only find out months after
the fact when the primary goes down that all your data is 6 months or so
out of date.
> I can't help but think that had I just asked about the possibility of
> using the WAL log idea for an 'out of the box' replication solution
> without mentioning the word 'MySQL', the responses received would have
> been very different.
Hmmmm. I would imagine you would have gotten different responses as
well too. Using WAL logs for replication is one subject, MySQL
replication is another. PITR is a new feature that's still be fleshed
out, but is already quite useful. MySQL's replication has a reputation
for dogdy behaviour. So, I can't imagine the two being discussed in the
same way either.
^ permalink raw reply [nested|flat] 131+ messages in thread
* Re: Replication
@ 2005-09-13 23:21 Simon Riggs <simon@2ndquadrant.com>
parent: Tatsuo Ishii <t-ishii@sra.co.jp>
0 siblings, 1 reply; 131+ messages in thread
From: Simon Riggs @ 2005-09-13 23:21 UTC (permalink / raw)
To: Tatsuo Ishii <t-ishii@sra.co.jp>; +Cc: barry@e-rm.co.uk; pgsql-general
> From: Tatsuo Ishii [mailto:t-ishii@sra.co.jp]
> > You can use PITR to archive transaction logs to a second
> server that is
> > kept in standby mode.
> >
> > This will cope with any number of tables and cope with
> dynamic changes
> > to tables.
> >
> > This is fairly straightforward and very low overhead.
> > Set archive_command to a program that transfers xlog files to second
> > server.
> > Then set restore_command on the second server to a program
> that loops
> > until the next file is available.
> > Switchover time is low.
>
> I thought there are some issues of log based replication (I don't
> remeber details though). Have they been resolved recently?
Yes, currently log-file based replication is not recommended when the
transaction rate is either low or extremely variable.
I was regrettably unable to get a patch for that into 8.1
Best Regards, Simon Riggs
^ permalink raw reply [nested|flat] 131+ messages in thread
* Re: Replication
@ 2005-09-14 13:47 Andrew Rawnsley <ronz@investoranalytics.com>
parent: Scott Marlowe <smarlowe@g2switchworks.com>
1 sibling, 0 replies; 131+ messages in thread
From: Andrew Rawnsley @ 2005-09-14 13:47 UTC (permalink / raw)
To: pgsql-general
On 9/13/05 2:45 PM, "Scott Marlowe" <smarlowe@g2switchworks.com> wrote:
> On Tue, 2005-09-13 at 10:45, Russ Brown wrote:
>> Simon Riggs wrote:
>>> Barry,
>>>
>>> You can use PITR to archive transaction logs to a second server that is
>>> kept in standby mode.
>>>
>>> This will cope with any number of tables and cope with dynamic changes
>>> to tables.
>>>
>>> This is fairly straightforward and very low overhead.
>>> Set archive_command to a program that transfers xlog files to second
>>> server.
>>> Then set restore_command on the second server to a program that loops
>>> until the next file is available.
>>> Switchover time is low.
>>>
>>
>> Apologies for going slighly off topic, but isn't this basically how
>> MySQL does replication? I ask because one of the arguments against
>> moving to PostgreSQL in my organisation is 'no replication out of the
>> box'. But if the above is true it seems that all that is required are a
>> couple of scripts to handle log transfer and you have a form of
>> replication out of the box right there.
>>
>> Or am I missing something?
>
> I don't know, but someone in your organization seems to be.
>
> Let me present it as a simple devil's choice, which would you rather
> have, proven replication, that works, but requires you to setup a
> secondary bit of software / system scripts (like rsync) but is tested
> and proven to work, or, an "out of the box" solution that is untested,
> unreliable, and possible unsafe for your data?
>
When I was putting together a fairly complex log-shipping solution in Oracle
(sorry for the O word...), I was presented with that exact choice: use
Oracle's built-in log shipping/recovery mechanism, or design an 'in rsync we
trust' system of scripts. I chose the scripts, and its worked without a burp
for a looong time now. Easy to test, easy to debug, predictable, small
simple parts. Its really not that hard. Keep track of disk space, and make
sure to check the size of the destination file when you move something
around and not just its existence. Not much else to it.
> Chosing a database because it has "out of the box" replication without
> paying attention to how it is implemented, how well it works, and what
> are the ways it can break is a recipe for (data) disaster.
>
We're getting back to the oft-repeated mantra here - replication is hard.
Anyone saying it can be effortless doesn't understand the complexity of the
problem.
> I've tested slony, and I know that for what we use it for, it's a good
> fit and it works well. I've tested MySQL's replication, and it simply
> can't do what I need from a replication system. It can't be setup on
> the fly on a live system with no down time, and it has reliability
> issues that make it a poor choice for a 24/7 enterprise replication
> system.
>
> That said, it's a great system for content management replication, where
> downtime is fine while setting up replication.
>
> But I wouldn't choose either because it was easier to implement. Being
> easy to implement is just sauce on the turkey. I need the meat to be
> good or the sauce doesn't matter.
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: explain analyze is your friend
^ permalink raw reply [nested|flat] 131+ messages in thread
* Re: Replication
@ 2005-09-16 17:09 Scott Ribe <scott_ribe@killerbytes.com>
parent: Russ Brown <pickscrape@gmail.com>
1 sibling, 1 reply; 131+ messages in thread
From: Scott Ribe @ 2005-09-16 17:09 UTC (permalink / raw)
To: Russ Brown <pickscrape@gmail.com>; Scott Marlowe <smarlowe@g2switchworks.com>; +Cc: pgsql-general
> How about a third choice: you can also use a proven, reliable and tested
> replication solution that is included in the core system because the
> core system basiclly provides it anyway.
Sure, but that one is spelled "Sybase", not "MySQL" ;-)
--
Scott Ribe
scott_ribe@killerbytes.com
http://www.killerbytes.com/
(303) 665-7007 voice
^ permalink raw reply [nested|flat] 131+ messages in thread
* Re: Replication
@ 2005-09-16 17:51 Russ Brown <pickscrape@gmail.com>
parent: Scott Ribe <scott_ribe@killerbytes.com>
0 siblings, 1 reply; 131+ messages in thread
From: Russ Brown @ 2005-09-16 17:51 UTC (permalink / raw)
To: pgsql-general
Scott Ribe wrote:
>>How about a third choice: you can also use a proven, reliable and tested
>> replication solution that is included in the core system because the
>>core system basiclly provides it anyway.
>
>
> Sure, but that one is spelled "Sybase", not "MySQL" ;-)
>
>
It's amazing how misunderstood my post was.
My third choice was a hypothetical future version of PostgreSQL,
modified from its current form very slightly to include a form of
replication 'out of the box': a couple of scripts to enable WAL log
transfer and also a solution to the problem of WAL log delay mentioned
by other posters.
I only mentioned MySQL because their 'out of the box' solution involves
transferring the binlogs, which is similar to the method of transferring
the PostgreSQL WAL logs, and it just made me think. That's all. I wasn't
comparing, I wasn't suggesting MySQL is better than PostgreSQL. I wasn't
suggesting that they have the 'ultimate' solution. I wasn't even
suggesting that they have a good solution. It just made me think. That's
all.
Well, I've learned my lesson. Next time I post I'll be sure not to
mention MySQL in any way, shape or form.
--
Russ
^ permalink raw reply [nested|flat] 131+ messages in thread
* Re: Replication
@ 2005-09-16 19:40 Scott Marlowe <smarlowe@g2switchworks.com>
parent: Russ Brown <pickscrape@gmail.com>
0 siblings, 1 reply; 131+ messages in thread
From: Scott Marlowe @ 2005-09-16 19:40 UTC (permalink / raw)
To: Russ Brown <pickscrape@gmail.com>; +Cc: pgsql-general
On Fri, 2005-09-16 at 12:51, Russ Brown wrote:
> Scott Ribe wrote:
> >>How about a third choice: you can also use a proven, reliable and tested
> >> replication solution that is included in the core system because the
> >>core system basiclly provides it anyway.
> >
> >
> > Sure, but that one is spelled "Sybase", not "MySQL" ;-)
> >
> >
>
> It's amazing how misunderstood my post was.
>
> My third choice was a hypothetical future version of PostgreSQL,
> modified from its current form very slightly to include a form of
> replication 'out of the box': a couple of scripts to enable WAL log
> transfer and also a solution to the problem of WAL log delay mentioned
> by other posters.
>
> I only mentioned MySQL because their 'out of the box' solution involves
> transferring the binlogs, which is similar to the method of transferring
> the PostgreSQL WAL logs, and it just made me think. That's all. I wasn't
> comparing, I wasn't suggesting MySQL is better than PostgreSQL. I wasn't
> suggesting that they have the 'ultimate' solution. I wasn't even
> suggesting that they have a good solution. It just made me think. That's
> all.
>
> Well, I've learned my lesson. Next time I post I'll be sure not to
> mention MySQL in any way, shape or form.
Actually, I would just suggest to not hold it up as an example of how
things should be done. That would work for me.
There was a time, 5 to 10 years ago, when MySQL AB spent a LOT of energy
demonizing PostgreSQL to make themselves look better. There were pages
of misinformation in their documentation about how PostgreSQL was
basically crap, and MySQL did everything right, and a lot of people
spent a lot of time debunking that.
MySQL AB now plays better with others, and hasn't engaged in the kind of
character assassination they once did, but there's STILL a sore spot for
most PostgreSQL users and developers there, because they used to have to
spend a lot of energy and time explaining that what was on the MySQL
site was lies and misinformation. A LOT of time. And it did hurt
PostgreSQL, in terms of keeping people away from it.
So, there's an almost automatic response triggered by someone mentioning
how MySQL does things, especially if they're perceived to be holding
MySQL up as an example to the PostgreSQL community on how things should
be done.
In my original post, my main point wasn't just against MySQL, it was
against the philosophy that just because replication is included and
part of the core of a database, it doesn't mean that it's reliable or
well tested. And MySQL is a fine example of that. Their replication
really does have a lot of issues.
So, feel free to mention MySQL, but know that mostly when it's mentioned
here, it's mentioned as an example of how things shouldn't be done. In
terms of coding, marketing, testing, or licensing.
^ permalink raw reply [nested|flat] 131+ messages in thread
* Re: Replication
@ 2005-09-16 20:30 Russ Brown <pickscrape@gmail.com>
parent: Scott Marlowe <smarlowe@g2switchworks.com>
0 siblings, 2 replies; 131+ messages in thread
From: Russ Brown @ 2005-09-16 20:30 UTC (permalink / raw)
To: pgsql-general
Scott Marlowe wrote:
> On Fri, 2005-09-16 at 12:51, Russ Brown wrote:
>
>>Scott Ribe wrote:
>>
>>>>How about a third choice: you can also use a proven, reliable and tested
>>>> replication solution that is included in the core system because the
>>>>core system basiclly provides it anyway.
>>>
>>>
>>>Sure, but that one is spelled "Sybase", not "MySQL" ;-)
>>>
>>>
>>
>>It's amazing how misunderstood my post was.
>>
>>My third choice was a hypothetical future version of PostgreSQL,
>>modified from its current form very slightly to include a form of
>>replication 'out of the box': a couple of scripts to enable WAL log
>>transfer and also a solution to the problem of WAL log delay mentioned
>>by other posters.
>>
>>I only mentioned MySQL because their 'out of the box' solution involves
>>transferring the binlogs, which is similar to the method of transferring
>>the PostgreSQL WAL logs, and it just made me think. That's all. I wasn't
>>comparing, I wasn't suggesting MySQL is better than PostgreSQL. I wasn't
>>suggesting that they have the 'ultimate' solution. I wasn't even
>>suggesting that they have a good solution. It just made me think. That's
>>all.
>>
>>Well, I've learned my lesson. Next time I post I'll be sure not to
>>mention MySQL in any way, shape or form.
>
>
> Actually, I would just suggest to not hold it up as an example of how
> things should be done. That would work for me.
>
I didn't!!!!!!
> There was a time, 5 to 10 years ago, when MySQL AB spent a LOT of energy
> demonizing PostgreSQL to make themselves look better. There were pages
> of misinformation in their documentation about how PostgreSQL was
> basically crap, and MySQL did everything right, and a lot of people
> spent a lot of time debunking that.
>
I remember that time, and I remember being very annoyed about it. I am
still frustrated now by people who will believe the FUD that was spread
at the time and won't even consider PostgreSQL as a result. That is
basically why the company I work for uses MySQL, and simply will not
consider changing, no matter how hard I try to make it happen.
> MySQL AB now plays better with others, and hasn't engaged in the kind of
> character assassination they once did, but there's STILL a sore spot for
> most PostgreSQL users and developers there, because they used to have to
> spend a lot of energy and time explaining that what was on the MySQL
> site was lies and misinformation. A LOT of time. And it did hurt
> PostgreSQL, in terms of keeping people away from it.
>
Indeed. As I say above, that's why my company is staying away from it,
despite my best efforts.
> So, there's an almost automatic response triggered by someone mentioning
> how MySQL does things, especially if they're perceived to be holding
> MySQL up as an example to the PostgreSQL community on how things should
> be done.
>
I've noticed that. I've been reading (and occasionally posting to) this
list for a few years now, and it's the one and only thing about it that
bugs me. Other lists bug me in a lot of ways due to attitudes of some of
the major contributors, but I've always enjoyed this list greatly
primarily *because* of the major contributors (yourself included). It's
educational, friendly and very helpful. I learn a lot from this list and
enjoy the discussion.
This one thing bugs me because I'm not generally an emotionally reactive
person: I prefer to consider things fairly before responding, which is
why I frequently don't respond at all to things if I don't think it
would help matters. I feel that it is an extremely unwise policy to
automatically assume that what your competitors are doing is worse than
what you are doing, and that there's nothing you can learn from them.
That's how you get left behind. That's not to say that there *is* a
great deal that PostgreSQL can learn from MySQL, but one should not
assume that there is nothing.
From my readings on this list the majority of examples of people using
MySQL as an example of how PostgreSQL should be doing things have been
misguided/wrong/trolling etc. However, from time to time a legitimate
example is raised, and in those situations the responses given have
sometimes been disappointing.
> In my original post, my main point wasn't just against MySQL, it was
> against the philosophy that just because replication is included and
> part of the core of a database, it doesn't mean that it's reliable or
> well tested. And MySQL is a fine example of that. Their replication
> really does have a lot of issues.
>
Indeed. But just to stress the point, I wasn't stating that the included
replication in MySQL was any good (though it's not terrible as we're
using it heavily in an extremely high-volume situation with few
problems), I was just bringing up the idea of getting a decent
replication solution included in PostgreSQL for relatively little effort.
> So, feel free to mention MySQL, but know that mostly when it's mentioned
> here, it's mentioned as an example of how things shouldn't be done. In
> terms of coding, marketing, testing, or licensing.
>
I think in future I'll just stick to not mentioning it. :)
Regards,
--
Russ
^ permalink raw reply [nested|flat] 131+ messages in thread
* Re: Replication
@ 2005-09-16 21:01 Matthew Terenzio <matt@jobsforge.com>
parent: Russ Brown <pickscrape@gmail.com>
1 sibling, 0 replies; 131+ messages in thread
From: Matthew Terenzio @ 2005-09-16 21:01 UTC (permalink / raw)
To: pgsql-general
On Sep 16, 2005, at 4:30 PM, Russ Brown wrote:
>> just because replication is included and
>> part of the core of a database, it doesn't mean that it's reliable or
>> well tested.
I just jumped into this thread, and this statement just triggers one
thought.
Many Postgres end users rely on experts like those on this list for the
best advice on how to use Postgres and what might be the best solution
for non-core needs such as replication.
Inclusion does probably make those users feel comfort that the experts
for that particular software or product deems it one of , if not the
best solution for the given problem.
It's not always true and may not be right for this situation, since
replication needs for different situations may vary widely.
But inclusion does imply some type of endorsement.
For instance I feel pretty comfortable with TSeach2 though I don't know
much about. That fact that it comes in the contribs is an endorsement.
I'd be confused if the consensus was that there is a better, as easy to
use and license compatible full text index available and was for some
reason NOT included.
Of course, I'd still ask the list. . .
^ permalink raw reply [nested|flat] 131+ messages in thread
* Re: Replication
@ 2005-09-20 00:10 Bruce Momjian <pgman@candle.pha.pa.us>
parent: Csaba Nagy <nagy@ecircle-ag.com>
0 siblings, 1 reply; 131+ messages in thread
From: Bruce Momjian @ 2005-09-20 00:10 UTC (permalink / raw)
To: Csaba Nagy <nagy@ecircle-ag.com>; +Cc: Russ Brown <pickscrape@gmail.com>; pgsql-general
Added to TODO:
* Allow WAL traffic to be steamed to another server for stand-by
replication
---------------------------------------------------------------------------
Csaba Nagy wrote:
> Well, AFAICT this kind of replication in postgres is not be named "out
> of the box". Setting up the whole thing to work, and test it to really
> work reliably is not exactly trivial, and you could have a number of
> surprises (like when there's little activity, the last WAL stays at the
> server and so the stand-by can be off by a considerable amount of time,
> even if in terms of data quantity the difference is not that big). You
> must master well scripting to write reliable scripts to handle the
> process, though I think there are some examples around, but you still
> need to customize them for sure.
>
> What is missing is an easy way to set up the hot stand-by, without
> requiring the user to do too much side-work.
>
> I wonder if there is a way to set up a direct link between the standby
> and the server and instead of copying files just send directly the WAL
> data over by some background process ? The overhead of sending the data
> directly should be similar with copying the files. Then the easiest way
> to set up a standby would be to start up the stand-by server with some
> standby options and giving the server's connection params, and then the
> standby should make a special connection to the server requesting a data
> dump + WAL from the data dump start on. Would this be reasonably simple
> to implement ? I'm not at all familiar with postgres code or the C
> language, so this is just wishful thinking.
>
> Cheers,
> Csaba.
>
>
>
> On Tue, 2005-09-13 at 17:45, Russ Brown wrote:
> > Simon Riggs wrote:
> > > Barry,
> > >
> > > You can use PITR to archive transaction logs to a second server that is
> > > kept in standby mode.
> > >
> > > This will cope with any number of tables and cope with dynamic changes
> > > to tables.
> > >
> > > This is fairly straightforward and very low overhead.
> > > Set archive_command to a program that transfers xlog files to second
> > > server.
> > > Then set restore_command on the second server to a program that loops
> > > until the next file is available.
> > > Switchover time is low.
> > >
> >
> > Apologies for going slighly off topic, but isn't this basically how
> > MySQL does replication? I ask because one of the arguments against
> > moving to PostgreSQL in my organisation is 'no replication out of the
> > box'. But if the above is true it seems that all that is required are a
> > couple of scripts to handle log transfer and you have a form of
> > replication out of the box right there.
> >
> > Or am I missing something?
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Have you searched our list archives?
>
> http://archives.postgresql.org
>
--
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
^ permalink raw reply [nested|flat] 131+ messages in thread
* Re: Replication
@ 2005-09-20 02:21 Thomas F. O'Connell <tfo@sitening.com>
parent: Bruce Momjian <pgman@candle.pha.pa.us>
0 siblings, 0 replies; 131+ messages in thread
From: Thomas F. O'Connell @ 2005-09-20 02:21 UTC (permalink / raw)
To: Bruce Momjian <pgman@candle.pha.pa.us>; +Cc: pgsql-general
On Sep 19, 2005, at 7:10 PM, Bruce Momjian wrote:
> Added to TODO:
>
> * Allow WAL traffic to be steamed to another server for stand-by
> replication
"steamed" or "streamed"?
:)
--
Thomas F. O'Connell
Co-Founder, Information Architect
Sitening, LLC
Strategic Open Source: Open Your i™
http://www.sitening.com/
110 30th Avenue North, Suite 6
Nashville, TN 37203-6320
615-469-5150
615-469-5151 (fax)
^ permalink raw reply [nested|flat] 131+ messages in thread
* Re: Replication
@ 2005-09-20 14:21 Scott Ribe <scott_ribe@killerbytes.com>
parent: Russ Brown <pickscrape@gmail.com>
1 sibling, 0 replies; 131+ messages in thread
From: Scott Ribe @ 2005-09-20 14:21 UTC (permalink / raw)
To: Russ Brown <pickscrape@gmail.com>; pgsql-general
> Indeed. But just to stress the point, I wasn't stating that the included
> replication in MySQL was any good (though it's not terrible as we're
> using it heavily in an extremely high-volume situation with few
> problems), I was just bringing up the idea of getting a decent
> replication solution included in PostgreSQL for relatively little effort.
No, but IIRC, you didn't state that is was a substandard solution, and, also
IIRC, it really sounded as though you believed it was a good one.
>> So, feel free to mention MySQL, but know that mostly when it's mentioned
>> here, it's mentioned as an example of how things shouldn't be done. In
>> terms of coding, marketing, testing, or licensing.
>>
>
> I think in future I'll just stick to not mentioning it. :)
Probably not necessary; just make it clear whether you're saying "MySQL
claims... and it would be good for Postgres to have its own solution..." or
"MySQL has an actual working full-blown good solution for... that Postgres
would do well to emulate".
--
Scott Ribe
scott_ribe@killerbytes.com
http://www.killerbytes.com/
(303) 665-7007 voice
^ permalink raw reply [nested|flat] 131+ messages in thread
* replication
@ 2008-06-24 06:41 Adrian Moisey <adrian@careerjunction.co.za>
0 siblings, 2 replies; 131+ messages in thread
From: Adrian Moisey @ 2008-06-24 06:41 UTC (permalink / raw)
To: pgsql-general
Hi
We have a 100GB database (16GB dumped) running on 8.2.
Since the bandwidth in South Africa isn't that freely available it is
difficult for us to get a new copy of out DB in our office (our fastest
link in the office is 4Mbps).
What can you recommend for me to get an up to date copy of my DB in the
office with as little transfer as possible.
A few ideas I've been toying with are rsyncing a dump of the db, or
replication.
Any ideas?
--
Adrian Moisey
Systems Administrator | CareerJunction | Your Future Starts Here.
Web: www.careerjunction.co.za | Email: adrian@careerjunction.co.za
Phone: +27 21 686 6820 | Mobile: +27 82 858 7830 | Fax: +27 21 686 6842
^ permalink raw reply [nested|flat] 131+ messages in thread
* Re: replication
@ 2008-06-24 06:53 Henry - Zen Search SA <henry@zen.co.za>
parent: Adrian Moisey <adrian@careerjunction.co.za>
1 sibling, 0 replies; 131+ messages in thread
From: Henry - Zen Search SA @ 2008-06-24 06:53 UTC (permalink / raw)
To: Adrian Moisey <adrian@careerjunction.co.za>; +Cc: pgsql-general
On Tue, June 24, 2008 8:41 am, Adrian Moisey wrote:
> Hi
>
> We have a 100GB database (16GB dumped) running on 8.2.
>
> Since the bandwidth in South Africa isn't that freely available it is
> difficult for us to get a new copy of out DB in our office (our fastest
> link in the office is 4Mbps).
>
> What can you recommend for me to get an up to date copy of my DB in the
> office with as little transfer as possible.
>
> A few ideas I've been toying with are rsyncing a dump of the db, or
> replication.
>
> Any ideas?
Give Slony (http://www.slony.info/) a try - the initial replication of the
entire DB takes a while, thereafter it only replicates changes (as they
happen).
We've been using it successfully (it has it's occasional problems like all
things) for over a year now replicating across a cluster (DB is also about
100GB+).
Regards
Henry
^ permalink raw reply [nested|flat] 131+ messages in thread
* Re: replication
@ 2008-06-25 06:20 Asko Oja <ascoja@gmail.com>
parent: Adrian Moisey <adrian@careerjunction.co.za>
1 sibling, 1 reply; 131+ messages in thread
From: Asko Oja @ 2008-06-25 06:20 UTC (permalink / raw)
To: Adrian Moisey <adrian@careerjunction.co.za>; +Cc: pgsql-general
Hi
Take a look also on Londiste from SkyTools. It is easy to set up and manage.
In addition SkyTools contains other useful scripts and tools.
We use Londiste to replicate data ovwe WAN where walshipping would consume
too much bandwidth.
Asko
On Tue, Jun 24, 2008 at 9:41 AM, Adrian Moisey <adrian@careerjunction.co.za>
wrote:
> Hi
>
> We have a 100GB database (16GB dumped) running on 8.2.
>
> Since the bandwidth in South Africa isn't that freely available it is
> difficult for us to get a new copy of out DB in our office (our fastest link
> in the office is 4Mbps).
>
> What can you recommend for me to get an up to date copy of my DB in the
> office with as little transfer as possible.
>
> A few ideas I've been toying with are rsyncing a dump of the db, or
> replication.
>
> Any ideas?
>
> --
> Adrian Moisey
> Systems Administrator | CareerJunction | Your Future Starts Here.
> Web: www.careerjunction.co.za | Email: adrian@careerjunction.co.za
> Phone: +27 21 686 6820 | Mobile: +27 82 858 7830 | Fax: +27 21 686 6842
>
> --
> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general
>
^ permalink raw reply [nested|flat] 131+ messages in thread
* Re: replication
@ 2008-06-25 11:52 Allan Kamau <allank@sanbi.ac.za>
parent: Asko Oja <ascoja@gmail.com>
0 siblings, 1 reply; 131+ messages in thread
From: Allan Kamau @ 2008-06-25 11:52 UTC (permalink / raw)
To: Adrian Moisey <adrian@careerjunction.co.za>; +Cc: pgsql-general
Initially you may want to get the full dump (this applies also to the
replication option) across to your other site. You may want to bzip2 the
dump file, you may be surprised by the reduction of file size using
bzip2. Try "tar -cjf mydump.sql.tar.bz2 mydump.sql" then transfer it
using scp or place it on an ftp server in your local office, then login
remotely (ssh) to a pc/server on your destination office then issue
"wget -c -t0 http://myftpsite/path/to/mydump.sql";.
Allan.
Asko Oja wrote:
> Hi
>
> Take a look also on Londiste from SkyTools. It is easy to set up and
> manage. In addition SkyTools contains other useful scripts and tools.
> We use Londiste to replicate data ovwe WAN where walshipping would
> consume too much bandwidth.
>
> Asko
>
> On Tue, Jun 24, 2008 at 9:41 AM, Adrian Moisey
> <adrian@careerjunction.co.za <mailto:adrian@careerjunction.co.za>> wrote:
>
> Hi
>
> We have a 100GB database (16GB dumped) running on 8.2.
>
> Since the bandwidth in South Africa isn't that freely available it
> is difficult for us to get a new copy of out DB in our office (our
> fastest link in the office is 4Mbps).
>
> What can you recommend for me to get an up to date copy of my DB
> in the office with as little transfer as possible.
>
> A few ideas I've been toying with are rsyncing a dump of the db,
> or replication.
>
> Any ideas?
>
> --
> Adrian Moisey
> Systems Administrator | CareerJunction | Your Future Starts Here.
> Web: www.careerjunction.co.za <http://www.careerjunction.co.za; |
> Email: adrian@careerjunction.co.za
> <mailto:adrian@careerjunction.co.za>
> Phone: +27 21 686 6820 | Mobile: +27 82 858 7830 | Fax: +27 21 686
> 6842
>
> --
> Sent via pgsql-general mailing list (pgsql-general@postgresql.org
> <mailto:pgsql-general@postgresql.org>)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general
>
>
^ permalink raw reply [nested|flat] 131+ messages in thread
* Re: replication
@ 2008-06-25 12:24 Andrew Sullivan <ajs@commandprompt.com>
parent: Allan Kamau <allank@sanbi.ac.za>
0 siblings, 0 replies; 131+ messages in thread
From: Andrew Sullivan @ 2008-06-25 12:24 UTC (permalink / raw)
To: pgsql-general
On Wed, Jun 25, 2008 at 01:52:00PM +0200, Allan Kamau wrote:
> Initially you may want to get the full dump (this applies also to the
> replication option) across to your other site.
Most of the replication systems I've seen require that _they_ send the
data to the remote site, so copying the data yourself is actually a
waste of bandwidth, since it's all going to get copied anyway. (They
have to do this because that's how they know that they're starting
from a point in time for which they have consistency information.)
You can indeed save on bandwith, however, by tunnelling your postgres
connections through an ssh tunnel that's using compression.
A
--
Andrew Sullivan
ajs@commandprompt.com
+1 503 667 4564 x104
http://www.commandprompt.com/
^ permalink raw reply [nested|flat] 131+ messages in thread
* Replication
@ 2010-11-01 19:53 Jonathan Tripathy <jonnyt@abpni.co.uk>
0 siblings, 2 replies; 131+ messages in thread
From: Jonathan Tripathy @ 2010-11-01 19:53 UTC (permalink / raw)
To: pgsql-general
Hi Everyone,
I'm looking for the best solution for "Hot Standbys" where once the
primary server fails, the standby will take over and act just like the
master did. The standby must support INSERTS and UPDATES as well (once
the master has failed)
Are there any solutions like this? Looking on the Postgresql site, all
the standby solutions seem to be read only..
Thanks
^ permalink raw reply [nested|flat] 131+ messages in thread
* Re: Replication
@ 2010-11-01 20:01 Thomas Kellerer <spam_eater@gmx.net>
parent: Jonathan Tripathy <jonnyt@abpni.co.uk>
1 sibling, 1 reply; 131+ messages in thread
From: Thomas Kellerer @ 2010-11-01 20:01 UTC (permalink / raw)
To: pgsql-general
Jonathan Tripathy wrote on 01.11.2010 20:53:
> Hi Everyone,
>
> I'm looking for the best solution for "Hot Standbys" where once the
> primary server fails, the standby will take over and act just like
> the master did. The standby must support INSERTS and UPDATES as well
> (once the master has failed)
>
> Are there any solutions like this? Looking on the Postgresql site,
> all the standby solutions seem to be read only..
9.0 has streaming replication and "Hot Standby"
http://www.postgresql.org/docs/current/static/hot-standby.html
http://www.postgresql.org/docs/current/static/warm-standby.html#STREAMING-REPLICATION
Regards
Thomas
^ permalink raw reply [nested|flat] 131+ messages in thread
* Re: Replication
@ 2010-11-01 20:12 Jonathan Tripathy <jonnyt@abpni.co.uk>
parent: Thomas Kellerer <spam_eater@gmx.net>
0 siblings, 2 replies; 131+ messages in thread
From: Jonathan Tripathy @ 2010-11-01 20:12 UTC (permalink / raw)
To: Thomas Kellerer <spam_eater@gmx.net>; pgsql-general
On 01/11/10 20:01, Thomas Kellerer wrote:
> Jonathan Tripathy wrote on 01.11.2010 20:53:
>> Hi Everyone,
>>
>> I'm looking for the best solution for "Hot Standbys" where once the
>> primary server fails, the standby will take over and act just like
>> the master did. The standby must support INSERTS and UPDATES as well
>> (once the master has failed)
>>
>> Are there any solutions like this? Looking on the Postgresql site,
>> all the standby solutions seem to be read only..
>
> 9.0 has streaming replication and "Hot Standby"
>
> http://www.postgresql.org/docs/current/static/hot-standby.html
> http://www.postgresql.org/docs/current/static/warm-standby.html#STREAMING-REPLICATION
>
>
> Regards
> Thomas
>
>
>
But does that not only allow "read-only" things to work on the standby?
^ permalink raw reply [nested|flat] 131+ messages in thread
* Re: Replication
@ 2010-11-01 20:21 Scott Marlowe <scott.marlowe@gmail.com>
parent: Jonathan Tripathy <jonnyt@abpni.co.uk>
1 sibling, 1 reply; 131+ messages in thread
From: Scott Marlowe @ 2010-11-01 20:21 UTC (permalink / raw)
To: Jonathan Tripathy <jonnyt@abpni.co.uk>; +Cc: Thomas Kellerer <spam_eater@gmx.net>; pgsql-general
On Mon, Nov 1, 2010 at 2:12 PM, Jonathan Tripathy <jonnyt@abpni.co.uk> wrote:
>
> On 01/11/10 20:01, Thomas Kellerer wrote:
>>
>> Jonathan Tripathy wrote on 01.11.2010 20:53:
>>>
>>> Hi Everyone,
>>>
>>> I'm looking for the best solution for "Hot Standbys" where once the
>>> primary server fails, the standby will take over and act just like
>>> the master did. The standby must support INSERTS and UPDATES as well
>>> (once the master has failed)
>>>
>>> Are there any solutions like this? Looking on the Postgresql site,
>>> all the standby solutions seem to be read only..
>>
>> 9.0 has streaming replication and "Hot Standby"
>>
>> http://www.postgresql.org/docs/current/static/hot-standby.html
>>
>> http://www.postgresql.org/docs/current/static/warm-standby.html#STREAMING-REPLICATION
>>
>> Regards
>> Thomas
>>
>>
>>
> But does that not only allow "read-only" things to work on the standby?
Yep. Generally when to fail over is considered a business decision.
I think only pgpool supports automatic failover but has a lot of
limitations to deal with otherwise.
^ permalink raw reply [nested|flat] 131+ messages in thread
* Re: Replication
@ 2010-11-01 20:26 Thomas Kellerer <spam_eater@gmx.net>
parent: Jonathan Tripathy <jonnyt@abpni.co.uk>
1 sibling, 1 reply; 131+ messages in thread
From: Thomas Kellerer @ 2010-11-01 20:26 UTC (permalink / raw)
To: pgsql-general
Jonathan Tripathy wrote on 01.11.2010 21:12:
>>
>> 9.0 has streaming replication and "Hot Standby"
>>
>> http://www.postgresql.org/docs/current/static/hot-standby.html
>> http://www.postgresql.org/docs/current/static/warm-standby.html#STREAMING-REPLICATION
>>
>>
> But does that not only allow "read-only" things to work on the standby?
>
But you didn't ask for read/write on the standby, only for a standby that can take of the master once the master fails:
"must support INSERTS and UPDATES as well (once the master has failed)"
That's exactly what the hot standby does: As long as it is in standby mode it's read-only.
Once the failover has happened the standby is the new master and will allow read/write access.
Thomas
^ permalink raw reply [nested|flat] 131+ messages in thread
* Re: Replication
@ 2010-11-01 20:28 Jonathan Tripathy <jonnyt@abpni.co.uk>
parent: Scott Marlowe <scott.marlowe@gmail.com>
0 siblings, 0 replies; 131+ messages in thread
From: Jonathan Tripathy @ 2010-11-01 20:28 UTC (permalink / raw)
To: Scott Marlowe <scott.marlowe@gmail.com>; pgsql-general
On 01/11/10 20:21, Scott Marlowe wrote:
> On Mon, Nov 1, 2010 at 2:12 PM, Jonathan Tripathy<jonnyt@abpni.co.uk> wrote:
>> On 01/11/10 20:01, Thomas Kellerer wrote:
>>> Jonathan Tripathy wrote on 01.11.2010 20:53:
>>>> Hi Everyone,
>>>>
>>>> I'm looking for the best solution for "Hot Standbys" where once the
>>>> primary server fails, the standby will take over and act just like
>>>> the master did. The standby must support INSERTS and UPDATES as well
>>>> (once the master has failed)
>>>>
>>>> Are there any solutions like this? Looking on the Postgresql site,
>>>> all the standby solutions seem to be read only..
>>> 9.0 has streaming replication and "Hot Standby"
>>>
>>> http://www.postgresql.org/docs/current/static/hot-standby.html
>>>
>>> http://www.postgresql.org/docs/current/static/warm-standby.html#STREAMING-REPLICATION
>>>
>>> Regards
>>> Thomas
>>>
>>>
>>>
>> But does that not only allow "read-only" things to work on the standby?
> Yep. Generally when to fail over is considered a business decision.
> I think only pgpool supports automatic failover but has a lot of
> limitations to deal with otherwise.
So really Postgresql doesn't have any "Hot Standbys" that once fail-over
has occurred, the system can act as normal? For this, would I have to
looking in Xen or VMWare HA?
I'm guessing the standbys in the "warm-failover" setup allow write
operations?
Thanks
^ permalink raw reply [nested|flat] 131+ messages in thread
* Re: Replication
@ 2010-11-01 20:29 Jonathan Tripathy <jonnyt@abpni.co.uk>
parent: Thomas Kellerer <spam_eater@gmx.net>
0 siblings, 0 replies; 131+ messages in thread
From: Jonathan Tripathy @ 2010-11-01 20:29 UTC (permalink / raw)
To: Thomas Kellerer <spam_eater@gmx.net>; pgsql-general
On 01/11/10 20:26, Thomas Kellerer wrote:
> Jonathan Tripathy wrote on 01.11.2010 21:12:
>>>
>>> 9.0 has streaming replication and "Hot Standby"
>>>
>>> http://www.postgresql.org/docs/current/static/hot-standby.html
>>> http://www.postgresql.org/docs/current/static/warm-standby.html#STREAMING-REPLICATION
>>>
>>>
>>>
>> But does that not only allow "read-only" things to work on the standby?
>>
>
> But you didn't ask for read/write on the standby, only for a standby
> that can take of the master once the master fails:
> "must support INSERTS and UPDATES as well (once the master has failed)"
>
> That's exactly what the hot standby does: As long as it is in standby
> mode it's read-only.
> Once the failover has happened the standby is the new master and will
> allow read/write access.
>
> Thomas
>
>
Ahh!! So in both those links above, once the master has failed, the
standby will support writes (As it not acts like the master)?
Thanks
^ permalink raw reply [nested|flat] 131+ messages in thread
* Re: Replication
@ 2010-11-01 21:10 Vick Khera <vivek@khera.org>
parent: Jonathan Tripathy <jonnyt@abpni.co.uk>
1 sibling, 1 reply; 131+ messages in thread
From: Vick Khera @ 2010-11-01 21:10 UTC (permalink / raw)
To: pgsql-general
On Mon, Nov 1, 2010 at 3:53 PM, Jonathan Tripathy <jonnyt@abpni.co.uk> wrote:
> The standby must support INSERTS and UPDATES as well (once the master has
> failed)
>
> Are there any solutions like this? Looking on the Postgresql site, all the
> standby solutions seem to be read only..
If they are RO it is only while they are replicas, not masters. Once
the server is upgraded to the master role, it becomes RW.
^ permalink raw reply [nested|flat] 131+ messages in thread
* Re: Replication
@ 2010-11-01 22:39 Jonathan Tripathy <jonnyt@abpni.co.uk>
parent: Vick Khera <vivek@khera.org>
0 siblings, 2 replies; 131+ messages in thread
From: Jonathan Tripathy @ 2010-11-01 22:39 UTC (permalink / raw)
To: Vick Khera <vivek@khera.org>; pgsql-general
On 01/11/10 21:10, Vick Khera wrote:
> On Mon, Nov 1, 2010 at 3:53 PM, Jonathan Tripathy<jonnyt@abpni.co.uk> wrote:
>> The standby must support INSERTS and UPDATES as well (once the master has
>> failed)
>>
>> Are there any solutions like this? Looking on the Postgresql site, all the
>> standby solutions seem to be read only..
> If they are RO it is only while they are replicas, not masters. Once
> the server is upgraded to the master role, it becomes RW.
>
So in the "Hot Standby" setup as described in
http://www.postgresql.org/docs/current/static/hot-standby.html , how
would I automatically make the slave a master?
^ permalink raw reply [nested|flat] 131+ messages in thread
* Re: Replication
@ 2010-11-02 01:56 Scott Marlowe <scott.marlowe@gmail.com>
parent: Jonathan Tripathy <jonnyt@abpni.co.uk>
1 sibling, 1 reply; 131+ messages in thread
From: Scott Marlowe @ 2010-11-02 01:56 UTC (permalink / raw)
To: Jonathan Tripathy <jonnyt@abpni.co.uk>; +Cc: Vick Khera <vivek@khera.org>; pgsql-general
On Mon, Nov 1, 2010 at 4:39 PM, Jonathan Tripathy <jonnyt@abpni.co.uk> wrote:
>
> On 01/11/10 21:10, Vick Khera wrote:
>>
>> On Mon, Nov 1, 2010 at 3:53 PM, Jonathan Tripathy<jonnyt@abpni.co.uk>
>> wrote:
>>>
>>> The standby must support INSERTS and UPDATES as well (once the master has
>>> failed)
>>>
>>> Are there any solutions like this? Looking on the Postgresql site, all
>>> the
>>> standby solutions seem to be read only..
>>
>> If they are RO it is only while they are replicas, not masters. Once
>> the server is upgraded to the master role, it becomes RW.
>>
> So in the "Hot Standby" setup as described in
> http://www.postgresql.org/docs/current/static/hot-standby.html , how would I
> automatically make the slave a master?
I think you're looking for this:
http://www.postgresql.org/docs/current/static/warm-standby-failover.html
--
To understand recursion, one must first understand recursion.
^ permalink raw reply [nested|flat] 131+ messages in thread
* Re: Replication
@ 2010-11-02 06:59 Jonathan Tripathy <jonnyt@abpni.co.uk>
parent: Scott Marlowe <scott.marlowe@gmail.com>
0 siblings, 3 replies; 131+ messages in thread
From: Jonathan Tripathy @ 2010-11-02 06:59 UTC (permalink / raw)
To: Scott Marlowe <scott.marlowe@gmail.com>; pgsql-general
On 02/11/10 01:56, Scott Marlowe wrote:
> On Mon, Nov 1, 2010 at 4:39 PM, Jonathan Tripathy<jonnyt@abpni.co.uk> wrote:
>> On 01/11/10 21:10, Vick Khera wrote:
>>> On Mon, Nov 1, 2010 at 3:53 PM, Jonathan Tripathy<jonnyt@abpni.co.uk>
>>> wrote:
>>>> The standby must support INSERTS and UPDATES as well (once the master has
>>>> failed)
>>>>
>>>> Are there any solutions like this? Looking on the Postgresql site, all
>>>> the
>>>> standby solutions seem to be read only..
>>> If they are RO it is only while they are replicas, not masters. Once
>>> the server is upgraded to the master role, it becomes RW.
>>>
>> So in the "Hot Standby" setup as described in
>> http://www.postgresql.org/docs/current/static/hot-standby.html , how would I
>> automatically make the slave a master?
> I think you're looking for this:
> http://www.postgresql.org/docs/current/static/warm-standby-failover.html
>
What is the difference between the "Hot-Standby" and "Warm-Standby"? Is
the only different that the "Hot-Standby" standby servers are read-only,
whereas the "Warm-Standby" standbys can't be queried at all?
Thanks
^ permalink raw reply [nested|flat] 131+ messages in thread
* Re: Replication
@ 2010-11-02 13:18 Vick Khera <vivek@khera.org>
parent: Jonathan Tripathy <jonnyt@abpni.co.uk>
2 siblings, 1 reply; 131+ messages in thread
From: Vick Khera @ 2010-11-02 13:18 UTC (permalink / raw)
To: pgsql-general
On Tue, Nov 2, 2010 at 2:59 AM, Jonathan Tripathy <jonnyt@abpni.co.uk> wrote:
> What is the difference between the "Hot-Standby" and "Warm-Standby"? Is the
> only different that the "Hot-Standby" standby servers are read-only, whereas
> the "Warm-Standby" standbys can't be queried at all?
>
That's the general definition of those two terms as applied to a
database server.
^ permalink raw reply [nested|flat] 131+ messages in thread
* Re: Replication
@ 2010-11-02 13:21 Vick Khera <vivek@khera.org>
parent: Jonathan Tripathy <jonnyt@abpni.co.uk>
1 sibling, 1 reply; 131+ messages in thread
From: Vick Khera @ 2010-11-02 13:21 UTC (permalink / raw)
To: pgsql-general
On Mon, Nov 1, 2010 at 6:39 PM, Jonathan Tripathy <jonnyt@abpni.co.uk> wrote:
> So in the "Hot Standby" setup as described in
> http://www.postgresql.org/docs/current/static/hot-standby.html , how would I
> automatically make the slave a master?
If you plan to make it automatic, be absolutely 1000000% sure that
your automated criteria for doing the switchover is really 1000000%
accurate, else you may end up switching when you didn't really want to
for some temporary failure condition. I've never been able to define
something that perfect so we still only ever do manual switchovers.
Based on your questions, you perhaps should be seeking the advice of a
paid consultant expert in such matters if you really value your data.
^ permalink raw reply [nested|flat] 131+ messages in thread
* Re: Replication
@ 2010-11-02 14:20 Jonathan Tripathy <jonnyt@abpni.co.uk>
parent: Vick Khera <vivek@khera.org>
0 siblings, 0 replies; 131+ messages in thread
From: Jonathan Tripathy @ 2010-11-02 14:20 UTC (permalink / raw)
To: Vick Khera <vivek@khera.org>; pgsql-general
________________________________
From: pgsql-general-owner@postgresql.org on behalf of Vick Khera
Sent: Tue 02/11/2010 13:18
To: pgsql-general
Subject: Re: [GENERAL] Replication
On Tue, Nov 2, 2010 at 2:59 AM, Jonathan Tripathy <jonnyt@abpni.co.uk> wrote:
> What is the difference between the "Hot-Standby" and "Warm-Standby"? Is the
> only different that the "Hot-Standby" standby servers are read-only, whereas
> the "Warm-Standby" standbys can't be queried at all?
>
That's the general definition of those two terms as applied to a
database server.
------------------------------------------------------------------------------------------
Excellent!
In terms of streaming "Warm-Standby" replication, how much data loss will occur? Are we talking seconds, minutes, or hours? Let's assume a lightly used database (maybe 50 update queries an hour) and the master and slave are connected by Gigabit ethernet
Thanks
^ permalink raw reply [nested|flat] 131+ messages in thread
* Re: Replication
@ 2010-11-02 15:20 Dimitri Fontaine <dimitri@2ndQuadrant.fr>
parent: Jonathan Tripathy <jonnyt@abpni.co.uk>
2 siblings, 0 replies; 131+ messages in thread
From: Dimitri Fontaine @ 2010-11-02 15:20 UTC (permalink / raw)
To: Jonathan Tripathy <jonnyt@abpni.co.uk>; +Cc: Scott Marlowe <scott.marlowe@gmail.com>; pgsql-general
Jonathan Tripathy <jonnyt@abpni.co.uk> writes:
> What is the difference between the "Hot-Standby" and "Warm-Standby"? Is the
> only different that the "Hot-Standby" standby servers are read-only, whereas
> the "Warm-Standby" standbys can't be queried at all?
That and the fact that running queries are not canceled at the time you
flick the switch to have your standby a master. The ongoing read-only
traffic is not affected. That's hot.
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
^ permalink raw reply [nested|flat] 131+ messages in thread
* Re: Replication
@ 2010-11-02 17:32 Simon Riggs <simon@2ndQuadrant.com>
parent: Jonathan Tripathy <jonnyt@abpni.co.uk>
2 siblings, 0 replies; 131+ messages in thread
From: Simon Riggs @ 2010-11-02 17:32 UTC (permalink / raw)
To: Jonathan Tripathy <jonnyt@abpni.co.uk>; +Cc: Scott Marlowe <scott.marlowe@gmail.com>; pgsql-general
On Tue, 2010-11-02 at 06:59 +0000, Jonathan Tripathy wrote:
> >>>
> >> So in the "Hot Standby" setup as described in
> >> http://www.postgresql.org/docs/current/static/hot-standby.html , how would I
> >> automatically make the slave a master?
> > I think you're looking for this:
> > http://www.postgresql.org/docs/current/static/warm-standby-failover.html
> >
> What is the difference between the "Hot-Standby" and "Warm-Standby"? Is
> the only different that the "Hot-Standby" standby servers are read-only,
> whereas the "Warm-Standby" standbys can't be queried at all?
The title of the second HTML page is now out of date. So there is no
warm/hot confusion to worry about, just the name of the page and URL.
--
Simon Riggs http://www.2ndQuadrant.com/books/
PostgreSQL Development, 24x7 Support, Training and Services
^ permalink raw reply [nested|flat] 131+ messages in thread
* Re: Replication
@ 2010-11-02 23:16 Craig Ringer <craig@postnewspapers.com.au>
parent: Vick Khera <vivek@khera.org>
0 siblings, 0 replies; 131+ messages in thread
From: Craig Ringer @ 2010-11-02 23:16 UTC (permalink / raw)
To: Vick Khera <vivek@khera.org>; +Cc: pgsql-general
On 02/11/10 21:21, Vick Khera wrote:
> On Mon, Nov 1, 2010 at 6:39 PM, Jonathan Tripathy <jonnyt@abpni.co.uk> wrote:
>> So in the "Hot Standby" setup as described in
>> http://www.postgresql.org/docs/current/static/hot-standby.html , how would I
>> automatically make the slave a master?
>
> If you plan to make it automatic, be absolutely 1000000% sure that
> your automated criteria for doing the switchover is really 1000000%
> accurate, else you may end up switching when you didn't really want to
> for some temporary failure condition. I've never been able to define
> something that perfect so we still only ever do manual switchovers.
^ permalink raw reply [nested|flat] 131+ messages in thread
* Replication
@ 2016-06-02 13:32 Bertrand Paquet <bertrand.paquet@doctolib.fr>
0 siblings, 3 replies; 131+ messages in thread
From: Bertrand Paquet @ 2016-06-02 13:32 UTC (permalink / raw)
To: pgsql-general
Hi,
On an hot standby streaming server, is there any way to know, in SQL, to
know the ip of current master ?
The solution I have is to read the recovery.conf file to find
primary_conninfo, but, it can be false.
Regards,
Bertrand
^ permalink raw reply [nested|flat] 131+ messages in thread
* Re: Replication
@ 2016-06-02 14:16 Melvin Davidson <melvin6925@gmail.com>
parent: Bertrand Paquet <bertrand.paquet@doctolib.fr>
2 siblings, 1 reply; 131+ messages in thread
From: Melvin Davidson @ 2016-06-02 14:16 UTC (permalink / raw)
To: Bertrand Paquet <bertrand.paquet@doctolib.fr>; +Cc: pgsql-general
It's been a few years since I worked with slony, and you did not state
which version of slony or PostgreSQL you are working with, nor did you
indicate the O/S.
That being said, you should be able to formulate a query with a join
between sl_path & sl_node that gives you the information you need.
On Thu, Jun 2, 2016 at 9:32 AM, Bertrand Paquet <bertrand.paquet@doctolib.fr
> wrote:
> Hi,
>
> On an hot standby streaming server, is there any way to know, in SQL, to
> know the ip of current master ?
> The solution I have is to read the recovery.conf file to find
> primary_conninfo, but, it can be false.
>
> Regards,
>
> Bertrand
>
--
*Melvin Davidson*
I reserve the right to fantasize. Whether or not you
wish to share my fantasy is entirely up to you.
^ permalink raw reply [nested|flat] 131+ messages in thread
* Re: Replication
@ 2016-06-02 14:34 Scott Mead <scottm@openscg.com>
parent: Melvin Davidson <melvin6925@gmail.com>
0 siblings, 1 reply; 131+ messages in thread
From: Scott Mead @ 2016-06-02 14:34 UTC (permalink / raw)
To: Melvin Davidson <melvin6925@gmail.com>; +Cc: Bertrand Paquet <bertrand.paquet@doctolib.fr>; pgsql-general
On Thu, Jun 2, 2016 at 10:16 AM, Melvin Davidson <melvin6925@gmail.com>
wrote:
> It's been a few years since I worked with slony, and you did not state
> which version of slony or PostgreSQL you are working with, nor did you
> indicate the O/S.
>
I think OP had pointed to using streaming....
> That being said, you should be able to formulate a query with a join
> between sl_path & sl_node that gives you the information you need.
>
> On Thu, Jun 2, 2016 at 9:32 AM, Bertrand Paquet <
> bertrand.paquet@doctolib.fr> wrote:
>
>> Hi,
>>
>> On an hot standby streaming server, is there any way to know, in SQL, to
>> know the ip of current master ?
>> The solution I have is to read the recovery.conf file to find
>> primary_conninfo, but, it can be false.
>>
>>
I've run into this as well. Only way is recovery.conf.
--Scott
> Regards,
>>
>> Bertrand
>>
>
>
>
> --
> *Melvin Davidson*
> I reserve the right to fantasize. Whether or not you
> wish to share my fantasy is entirely up to you.
>
--
--
Scott Mead
Sr. Architect
*OpenSCG <http://openscg.com>*
http://openscg.com
^ permalink raw reply [nested|flat] 131+ messages in thread
* Re: Replication
@ 2016-06-02 15:02 Sameer Kumar <sameer.kumar@ashnik.com>
parent: Scott Mead <scottm@openscg.com>
0 siblings, 0 replies; 131+ messages in thread
From: Sameer Kumar @ 2016-06-02 15:02 UTC (permalink / raw)
To: Scott Mead <scottm@openscg.com>; Melvin Davidson <melvin6925@gmail.com>; +Cc: Bertrand Paquet <bertrand.paquet@doctolib.fr>; pgsql-general
On Thu, 2 Jun 2016, 10:34 p.m. Scott Mead, <scottm@openscg.com> wrote:
> On Thu, Jun 2, 2016 at 10:16 AM, Melvin Davidson <melvin6925@gmail.com>
> wrote:
>
>> It's been a few years since I worked with slony, and you did not state
>> which version of slony or PostgreSQL you are working with, nor did you
>> indicate the O/S.
>>
>
> I think OP had pointed to using streaming....
>
>
>> That being said, you should be able to formulate a query with a join
>> between sl_path & sl_node that gives you the information you need.
>>
>> On Thu, Jun 2, 2016 at 9:32 AM, Bertrand Paquet <
>> bertrand.paquet@doctolib.fr> wrote:
>>
>>> Hi,
>>>
>>> On an hot standby streaming server, is there any way to know, in SQL, to
>>> know the ip of current master ?
>>> The solution I have is to read the recovery.conf file to find
>>> primary_conninfo, but, it can be false.
>>>
>>>
> I've run into this as well. Only way is recovery.conf.
>
9.6 onward you will have a new view which will facilitate you to query the
replication details on standby.
I have not tried but probably you can check the pid of wal receiver and
find out what host it is connected to (should be possible from network
stats).
> --Scott
>
>
>
>> Regards,
>>>
>>> Bertrand
>>>
>>
>>
>>
>> --
>> *Melvin Davidson*
>> I reserve the right to fantasize. Whether or not you
>> wish to share my fantasy is entirely up to you.
>>
>
>
>
> --
> --
> Scott Mead
> Sr. Architect
> *OpenSCG <http://openscg.com>*
> http://openscg.com
>
--
--
Best Regards
Sameer Kumar | DB Solution Architect
*ASHNIK PTE. LTD.*
101 Cecil Street, #11-11 Tong Eng Building, Singapore 069 533
T: +65 6438 3504 | M: +65 8110 0350 | www.ashnik.com
^ permalink raw reply [nested|flat] 131+ messages in thread
* Re: Replication
@ 2016-06-02 16:39 John R Pierce <pierce@hogranch.com>
parent: Bertrand Paquet <bertrand.paquet@doctolib.fr>
2 siblings, 1 reply; 131+ messages in thread
From: John R Pierce @ 2016-06-02 16:39 UTC (permalink / raw)
To: pgsql-general
On 6/2/2016 6:32 AM, Bertrand Paquet wrote:
> On an hot standby streaming server, is there any way to know, in SQL,
> to know the ip of current master ?
> The solution I have is to read the recovery.conf file to find
> primary_conninfo, but, it can be false.
"The IP" assumes there is only one... hosts can be multihomed,
postgres can be listening on numerous interfaces, there is no 'the IP'
--
john r pierce, recycling bits in santa cruz
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
^ permalink raw reply [nested|flat] 131+ messages in thread
* Re: Replication
@ 2016-06-04 13:58 Vik Fearing <vik@2ndquadrant.fr>
parent: Bertrand Paquet <bertrand.paquet@doctolib.fr>
2 siblings, 1 reply; 131+ messages in thread
From: Vik Fearing @ 2016-06-04 13:58 UTC (permalink / raw)
To: Bertrand Paquet <bertrand.paquet@doctolib.fr>; pgsql-general
On 02/06/16 15:32, Bertrand Paquet wrote:
> Hi,
>
> On an hot standby streaming server, is there any way to know, in SQL, to
> know the ip of current master ?
No.
> The solution I have is to read the recovery.conf file to find
> primary_conninfo,
That is currently the only solution. There are plans to allow SQL
access to the parameters in recovery.conf (or to merge them into
postgresql.conf) but that's not currently possible.
> but, it can be false.
It would only be wrong if recovery.conf has been edited since the stanby
was last restarted.
There are hooks for connections and disconnections of the walreceiver,
so it should be possible and fairly simple to write an extension that
remembers and exposes the primary_conninfo in effect.
--
Vik Fearing +33 6 46 75 15 36
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
^ permalink raw reply [nested|flat] 131+ messages in thread
* Re: Replication
@ 2016-06-04 13:59 Vik Fearing <vik@2ndquadrant.fr>
parent: John R Pierce <pierce@hogranch.com>
0 siblings, 0 replies; 131+ messages in thread
From: Vik Fearing @ 2016-06-04 13:59 UTC (permalink / raw)
To: John R Pierce <pierce@hogranch.com>; pgsql-general
On 02/06/16 18:39, John R Pierce wrote:
> On 6/2/2016 6:32 AM, Bertrand Paquet wrote:
>> On an hot standby streaming server, is there any way to know, in SQL,
>> to know the ip of current master ?
>> The solution I have is to read the recovery.conf file to find
>> primary_conninfo, but, it can be false.
>
> "The IP" assumes there is only one... hosts can be multihomed,
> postgres can be listening on numerous interfaces, there is no 'the IP'
That's nice, but a standby is only connecting to one.
--
Vik Fearing +33 6 46 75 15 36
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
^ permalink raw reply [nested|flat] 131+ messages in thread
* Re: Replication
@ 2016-06-06 07:54 Masahiko Sawada <sawada.mshk@gmail.com>
parent: Vik Fearing <vik@2ndquadrant.fr>
0 siblings, 1 reply; 131+ messages in thread
From: Masahiko Sawada @ 2016-06-06 07:54 UTC (permalink / raw)
To: Vik Fearing <vik@2ndquadrant.fr>; +Cc: Bertrand Paquet <bertrand.paquet@doctolib.fr>; pgsql-general
On Sat, Jun 4, 2016 at 10:58 PM, Vik Fearing <vik@2ndquadrant.fr> wrote:
> On 02/06/16 15:32, Bertrand Paquet wrote:
>> Hi,
>>
>> On an hot standby streaming server, is there any way to know, in SQL, to
>> know the ip of current master ?
>
> No.
>
>> The solution I have is to read the recovery.conf file to find
>> primary_conninfo,
>
> That is currently the only solution. There are plans to allow SQL
> access to the parameters in recovery.conf (or to merge them into
> postgresql.conf) but that's not currently possible.
>
It might not be a right way but how about using pg_read_file()?
postgres(1)=# select regexp_replace(pg_read_file('recovery.conf'),
'.*primary_conninfo = (.*)', '\1');
regexp_replace
---------------------------------------------------
'host=localhost port=5550 application_name=node1'+
(1 row)
You can get the master server information via SQL from standby server.
Regards,
--
Masahiko Sawada
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
^ permalink raw reply [nested|flat] 131+ messages in thread
* Re: Replication
@ 2016-06-06 08:22 Vik Fearing <vik@2ndquadrant.fr>
parent: Masahiko Sawada <sawada.mshk@gmail.com>
0 siblings, 1 reply; 131+ messages in thread
From: Vik Fearing @ 2016-06-06 08:22 UTC (permalink / raw)
To: Masahiko Sawada <sawada.mshk@gmail.com>; +Cc: Bertrand Paquet <bertrand.paquet@doctolib.fr>; pgsql-general
On 06/06/16 09:54, Masahiko Sawada wrote:
> On Sat, Jun 4, 2016 at 10:58 PM, Vik Fearing <vik@2ndquadrant.fr> wrote:
>> On 02/06/16 15:32, Bertrand Paquet wrote:
>>> Hi,
>>>
>>> On an hot standby streaming server, is there any way to know, in SQL, to
>>> know the ip of current master ?
>>
>> No.
>>
>>> The solution I have is to read the recovery.conf file to find
>>> primary_conninfo,
>>
>> That is currently the only solution. There are plans to allow SQL
>> access to the parameters in recovery.conf (or to merge them into
>> postgresql.conf) but that's not currently possible.
>
> It might not be a right way but how about using pg_read_file()?
> postgres(1)=# select regexp_replace(pg_read_file('recovery.conf'),
> '.*primary_conninfo = (.*)', '\1');
> regexp_replace
> ---------------------------------------------------
> 'host=localhost port=5550 application_name=node1'+
>
> (1 row)
>
> You can get the master server information via SQL from standby server.
This is a good idea, but suffers the same problem that Bertrand has with
looking at the file a different way: if the file was changed but the
standby server has not been restarted, it's (potentially) not going to
be the correct information.
--
Vik Fearing +33 6 46 75 15 36
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
^ permalink raw reply [nested|flat] 131+ messages in thread
* Re: Replication
@ 2016-06-06 08:53 Bertrand Paquet <bertrand.paquet@doctolib.fr>
parent: Vik Fearing <vik@2ndquadrant.fr>
0 siblings, 0 replies; 131+ messages in thread
From: Bertrand Paquet @ 2016-06-06 08:53 UTC (permalink / raw)
To: Vik Fearing <vik@2ndquadrant.fr>; +Cc: Masahiko Sawada <sawada.mshk@gmail.com>; pgsql-general
Hi,
Thx you for answering.
Regards,
Bertrand
2016-06-06 10:22 GMT+02:00 Vik Fearing <vik@2ndquadrant.fr>:
> On 06/06/16 09:54, Masahiko Sawada wrote:
> > On Sat, Jun 4, 2016 at 10:58 PM, Vik Fearing <vik@2ndquadrant.fr> wrote:
> >> On 02/06/16 15:32, Bertrand Paquet wrote:
> >>> Hi,
> >>>
> >>> On an hot standby streaming server, is there any way to know, in SQL,
> to
> >>> know the ip of current master ?
> >>
> >> No.
> >>
> >>> The solution I have is to read the recovery.conf file to find
> >>> primary_conninfo,
> >>
> >> That is currently the only solution. There are plans to allow SQL
> >> access to the parameters in recovery.conf (or to merge them into
> >> postgresql.conf) but that's not currently possible.
> >
> > It might not be a right way but how about using pg_read_file()?
> > postgres(1)=# select regexp_replace(pg_read_file('recovery.conf'),
> > '.*primary_conninfo = (.*)', '\1');
> > regexp_replace
> > ---------------------------------------------------
> > 'host=localhost port=5550 application_name=node1'+
> >
> > (1 row)
> >
> > You can get the master server information via SQL from standby server.
>
> This is a good idea, but suffers the same problem that Bertrand has with
> looking at the file a different way: if the file was changed but the
> standby server has not been restarted, it's (potentially) not going to
> be the correct information.
> --
> Vik Fearing +33 6 46 75 15 36
> http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
>
^ permalink raw reply [nested|flat] 131+ messages in thread
* Replication
@ 2019-02-26 09:41 Sonam Sharma <sonams1209@gmail.com>
0 siblings, 3 replies; 131+ messages in thread
From: Sonam Sharma @ 2019-02-26 09:41 UTC (permalink / raw)
To: pgsql-general
Hi,
Can we do master to master replication in Postgres.
Regards,
Sonam
^ permalink raw reply [nested|flat] 131+ messages in thread
* Re: Replication
@ 2019-02-26 10:59 Andreas Kretschmer <andreas@a-kretschmer.de>
parent: Sonam Sharma <sonams1209@gmail.com>
2 siblings, 0 replies; 131+ messages in thread
From: Andreas Kretschmer @ 2019-02-26 10:59 UTC (permalink / raw)
To: pgsql-general@lists.postgresql.org,Sonam Sharma <sonams1209@gmail.com>; pgsql-general
On 26 February 2019 10:41:19 CET, Sonam Sharma <sonams1209@gmail.com> wrote:
>Hi,
>
>Can we do master to master replication in Postgres.
>
Not in core, but with BDR.
Andreas
--
2ndQuadrant - The PostgreSQL Support Company
^ permalink raw reply [nested|flat] 131+ messages in thread
* Re: Replication
@ 2019-02-26 11:39 Filip Rembiałkowski <plk.zuber@gmail.com>
parent: Sonam Sharma <sonams1209@gmail.com>
2 siblings, 0 replies; 131+ messages in thread
From: Filip Rembiałkowski @ 2019-02-26 11:39 UTC (permalink / raw)
To: Sonam Sharma <sonams1209@gmail.com>; +Cc: pgsql-general
No - because there's no "out-of-the box" solution that creates two
replicas, both writable. It's said on
https://www.postgresql.org/docs/11/different-replication-solutions.html
Yes - because with current postgres features (logical rep, partitions,
foreign tables, ...) you can create solutions that effectively, have
more than one origin of truth.
On Tue, Feb 26, 2019 at 10:41 AM Sonam Sharma <sonams1209@gmail.com> wrote:
>
> Hi,
>
> Can we do master to master replication in Postgres.
>
> Regards,
> Sonam
^ permalink raw reply [nested|flat] 131+ messages in thread
* Re: Replication
@ 2019-02-26 11:48 Steve Atkins <steve@blighty.com>
parent: Sonam Sharma <sonams1209@gmail.com>
2 siblings, 0 replies; 131+ messages in thread
From: Steve Atkins @ 2019-02-26 11:48 UTC (permalink / raw)
To: pgsql-general
> On Feb 26, 2019, at 9:41 AM, Sonam Sharma <sonams1209@gmail.com> wrote:
>
> Hi,
>
> Can we do master to master replication in Postgres.
Look at https://bucardo.org/Bucardo/ , BDR (e.g. https://www.2ndquadrant.com/en/resources/postgres-bdr-2ndquadrant/ ), RubyRep or any of the other multimaster solutions at https://wiki.postgresql.org/wiki/Replication,_Clustering,_and_Connection_Pooling#Replication .
You probably don't actually need bidirectional master-master replication, though, and might want to look hard at other ways to do what you want.
Cheers,
Steve
^ permalink raw reply [nested|flat] 131+ messages in thread
* replication
@ 2025-04-25 13:50 Marc Millas <marc.millas@mokadb.com>
0 siblings, 1 reply; 131+ messages in thread
From: Marc Millas @ 2025-04-25 13:50 UTC (permalink / raw)
To: pgsql-general@lists.postgresql.org <pgsql-general@lists.postgresql.org>
Hello,
One of my customers tells me he did a replication with the master on a
debian 10
and the slave on a debian 12, both with a pg13.20, one on a pgdg110+1, the
other a pgdg120.1
is this a good idea ??? (I don't think so...)
thanks,
Marc MILLAS
Senior Architect
+33607850334
^ permalink raw reply [nested|flat] 131+ messages in thread
* Re: replication
@ 2025-04-25 14:19 Achilleas Mantzios - cloud <a.mantzios@cloud.gatewaynet.com>
parent: Marc Millas <marc.millas@mokadb.com>
0 siblings, 0 replies; 131+ messages in thread
From: Achilleas Mantzios - cloud @ 2025-04-25 14:19 UTC (permalink / raw)
To: pgsql-general@lists.postgresql.org
On 4/25/25 14:50, Marc Millas wrote:
> Hello,
>
>
> One of my customers tells me he did a replication with the master on a
> debian 10
> and the slave on a debian 12, both with a pg13.20, one on a pgdg110+1,
> the other a pgdg120.1
>
> is this a good idea ??? (I don't think so...)
Sorry I dont quite get the pgdg110 vs pgdg120 distinction I guess they
each support a different release of debian, but using the same
architecture (e.g. amd64), same on disk structure structure , same
PostgreSQL major version is a minimum for physical replication and you
are 100% safe with that.
In order to be more flexible your client might want to try logical
replication which lifts any of the restrictions mentioned above (if
applicable) and even allows near zero-time upgrades.
>
> thanks,
>
>
> Marc MILLAS
> Senior Architect
> +33607850334
>
>
^ permalink raw reply [nested|flat] 131+ messages in thread
end of thread, other threads:[~2025-04-25 14:19 UTC | newest]
Thread overview: 131+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
1999-04-16 11:44 Replication Natalya S. Makushina <mak@rtsoft.msk.ru>
1999-08-24 06:00 Replication.... =?iso-8859-9?Q?Safa_Pilavc=FD?= <safa.pilavci@rumeli.net>
1999-11-16 16:24 Re: replication Aaron J. Seigo <aaron@gtv.ca>
1999-11-16 17:21 ` Re: [GENERAL] Re: replication Jeff Hoffmann <jeff@propertykey.com>
1999-11-16 18:54 ` Re: [GENERAL] Re: replication Aaron J. Seigo <aaron@gtv.ca>
1999-11-16 19:33 ` Re: [GENERAL] Re: replication Jeff Hoffmann <jeff@propertykey.com>
1999-11-16 20:41 Re: [GENERAL] Re: replication Richard Welsh <rwelsh@OneStepInternet.com>
1999-11-16 22:15 ` Re: [GENERAL] Re: replication Aaron J. Seigo <aaron@gtv.ca>
1999-12-08 08:44 REPLICATION neil d. quiogue <neil@email.com.ph>
2000-04-05 20:48 replication Jenifer Pepling <jpepling@freei.com>
2000-07-11 01:55 Replication XWorkers <xworkers@bangla.net>
2000-09-21 12:52 replication Adam Lang <aalang@rutgersinsurance.com>
2000-09-21 13:14 ` Re: replication Karel Zak <zakkr@zf.jcu.cz>
2000-09-21 13:34 ` Re: replication Daryl Chance <dchance@valuedata.net>
2000-09-21 16:59 ` Re: replication Stephan Szabo <sszabo@megazone23.bigpanda.com>
2000-09-21 17:42 ` Re: replication Adam Lang <aalang@rutgersinsurance.com>
2000-09-21 19:19 ` RE: replication Rob Hutton <rhutton@istmanagement.com>
2000-09-21 18:43 ` Re: replication Adam Lang <aalang@rutgersinsurance.com>
2000-09-21 14:18 ` Re: replication Poul L. Christiansen <poulc@cs.auc.dk>
2000-09-22 07:58 ` Re: replication Elmar Haneke <elmar@haneke.de>
2000-09-22 15:31 ` Re: replication Bruce Guenter <bruceg@em.ca>
2000-09-22 16:03 ` Re: replication Tom Lane <tgl@sss.pgh.pa.us>
2000-09-22 16:08 ` Re: replication Bruce Guenter <bruceg@em.ca>
2000-09-21 17:41 Fw: replication Adam Lang <aalang@rutgersinsurance.com>
2000-09-21 20:17 Re: replication Adam Lang <aalang@rutgersinsurance.com>
2000-09-21 20:19 ` Re: replication Michael Fork <mfork@toledolink.com>
2000-09-21 20:32 ` Re: replication Adam Lang <aalang@rutgersinsurance.com>
2001-01-25 00:18 Replication Ryan Mahoney <ryan@paymentalliance.net>
2001-07-18 20:31 replication? Fran Fabrizio <ffabrizio@mmrd.com>
2001-07-18 21:33 ` Re: replication? Ryan Mahoney <ryan@paymentalliance.net>
2001-07-18 22:28 ` Re: replication? Adam Manock <abmanock@planetcable.net>
2001-07-18 23:12 ` Re: replication? Justin Clift <justin@postgresql.org>
2001-11-15 19:14 Replication Mihai Gheorghiu <tanethq@earthlink.net>
2002-03-01 01:55 Replication George Osvald <mail@okstudio.com.au>
2002-03-01 09:13 ` Holger Marzen <holger@marzen.de>
2002-10-17 22:46 replication Paul <paul@nomail.com>
2002-10-22 15:12 ` Re: replication Andrew Sullivan <andrew@libertyrms.info>
2003-04-20 10:18 replication valter m <maweb@hotmail.com>
2003-12-17 08:15 Replication John Sidney-Woollett <johnsw@wardbrook.com>
2003-12-17 14:22 ` Andrew Rawnsley <ronz@ravensfield.com>
2003-12-18 08:16 ` John Sidney-Woollett <johnsw@wardbrook.com>
2004-02-19 18:10 ` Joshua D. Drake <jd@commandprompt.com>
2003-12-18 20:40 ` Robert Treat <xzilla@users.sourceforge.net>
2003-12-18 21:24 ` Andrew Sullivan <andrew@libertyrms.info>
2003-12-18 21:35 ` John Sidney-Woollett <johnsw@wardbrook.com>
2003-12-31 11:06 Replication ? Andreas <maps.on@gmx.net>
2003-12-31 11:12 ` Re: Replication ? John Sidney-Woollett <johnsw@wardbrook.com>
2004-04-20 09:26 Replication Pailloncy Jean-Gérard <pailloncy@ifrance.com>
2004-04-20 11:51 ` Andrew Sullivan <ajs@crankycanuck.ca>
2004-04-21 15:23 ` Jan Wieck <JanWieck@Yahoo.com>
2004-04-21 17:28 ` Andrew Sullivan <ajs@crankycanuck.ca>
2004-04-21 22:39 ` Uwe C. Schroeder <uwe@oss4u.com>
2004-04-22 02:09 ` Christopher Browne <cbbrowne@acm.org>
2004-04-22 02:08 ` Christopher Browne <cbbrowne@acm.org>
2004-04-22 14:18 ` Michael Chaney <mdchaney@michaelchaney.com>
2004-04-22 18:40 ` Andrew Sullivan <ajs@crankycanuck.ca>
2004-04-22 13:42 Re: Replication Eric Comeau <eric.comeau@signiant.com>
2004-04-26 18:23 ` Andrew Sullivan <ajs@crankycanuck.ca>
2004-06-08 15:31 replication David Parker <dparker@tazznetworks.com>
2004-06-09 17:27 ` Re: replication Jan Wieck <JanWieck@Yahoo.com>
2004-08-06 17:08 replication Si Chen <schen@graciousstyle.com>
2004-08-06 17:55 ` Re: replication Joshua D. Drake <jd@commandprompt.com>
2004-08-06 21:19 ` Re: replication Marc G. Fournier <scrappy@postgresql.org>
2004-08-09 13:31 ` Re: replication Jan Wieck <JanWieck@Yahoo.com>
2004-08-11 18:37 ` Re: replication Vivek Khera <khera@kcilink.com>
2005-06-18 05:44 Replication mojoscoobydoo@comcast.net
2005-06-18 05:54 Replication Jeffery Reedy <mojoscoobydoo@yahoo.com>
2005-06-18 14:27 ` Bruno Wolff III <bruno@wolff.to>
2005-06-18 17:26 ` brew@theMode.com
2005-09-12 11:52 Replication barry@e-rm.co.uk
2005-09-12 13:32 ` Peter Eisentraut <peter_e@gmx.net>
2005-09-12 15:13 ` Joshua D. Drake <jd@commandprompt.com>
2005-09-12 22:29 ` Tatsuo Ishii <t-ishii@sra.co.jp>
2005-09-13 02:23 ` Simon Riggs <simon@2ndquadrant.com>
2005-09-13 13:54 ` Tatsuo Ishii <t-ishii@sra.co.jp>
2005-09-13 23:21 ` Simon Riggs <simon@2ndquadrant.com>
2005-09-13 15:39 ` Tom Lane <tgl@sss.pgh.pa.us>
2005-09-13 15:45 ` Russ Brown <pickscrape@gmail.com>
2005-09-13 16:43 ` Csaba Nagy <nagy@ecircle-ag.com>
2005-09-20 00:10 ` Bruce Momjian <pgman@candle.pha.pa.us>
2005-09-20 02:21 ` Thomas F. O'Connell <tfo@sitening.com>
2005-09-13 18:45 ` Scott Marlowe <smarlowe@g2switchworks.com>
2005-09-13 20:51 ` Russ Brown <pickscrape@gmail.com>
2005-09-13 22:01 ` Scott Marlowe <smarlowe@g2switchworks.com>
2005-09-16 17:09 ` Scott Ribe <scott_ribe@killerbytes.com>
2005-09-16 17:51 ` Russ Brown <pickscrape@gmail.com>
2005-09-16 19:40 ` Scott Marlowe <smarlowe@g2switchworks.com>
2005-09-16 20:30 ` Russ Brown <pickscrape@gmail.com>
2005-09-16 21:01 ` Matthew Terenzio <matt@jobsforge.com>
2005-09-20 14:21 ` Scott Ribe <scott_ribe@killerbytes.com>
2005-09-14 13:47 ` Andrew Rawnsley <ronz@investoranalytics.com>
2005-09-13 19:00 ` Peter Eisentraut <peter_e@gmx.net>
2005-09-13 16:53 Re: Replication Welty, Richard <richard.welty@bankofamerica.com>
2008-06-24 06:41 replication Adrian Moisey <adrian@careerjunction.co.za>
2008-06-24 06:53 ` Re: replication Henry - Zen Search SA <henry@zen.co.za>
2008-06-25 06:20 ` Re: replication Asko Oja <ascoja@gmail.com>
2008-06-25 11:52 ` Re: replication Allan Kamau <allank@sanbi.ac.za>
2008-06-25 12:24 ` Re: replication Andrew Sullivan <ajs@commandprompt.com>
2010-11-01 19:53 Replication Jonathan Tripathy <jonnyt@abpni.co.uk>
2010-11-01 20:01 ` Thomas Kellerer <spam_eater@gmx.net>
2010-11-01 20:12 ` Jonathan Tripathy <jonnyt@abpni.co.uk>
2010-11-01 20:21 ` Scott Marlowe <scott.marlowe@gmail.com>
2010-11-01 20:28 ` Jonathan Tripathy <jonnyt@abpni.co.uk>
2010-11-01 20:26 ` Thomas Kellerer <spam_eater@gmx.net>
2010-11-01 20:29 ` Jonathan Tripathy <jonnyt@abpni.co.uk>
2010-11-01 21:10 ` Vick Khera <vivek@khera.org>
2010-11-01 22:39 ` Jonathan Tripathy <jonnyt@abpni.co.uk>
2010-11-02 01:56 ` Scott Marlowe <scott.marlowe@gmail.com>
2010-11-02 06:59 ` Jonathan Tripathy <jonnyt@abpni.co.uk>
2010-11-02 13:18 ` Vick Khera <vivek@khera.org>
2010-11-02 14:20 ` Jonathan Tripathy <jonnyt@abpni.co.uk>
2010-11-02 15:20 ` Dimitri Fontaine <dimitri@2ndQuadrant.fr>
2010-11-02 17:32 ` Simon Riggs <simon@2ndQuadrant.com>
2010-11-02 13:21 ` Vick Khera <vivek@khera.org>
2010-11-02 23:16 ` Craig Ringer <craig@postnewspapers.com.au>
2016-06-02 13:32 Replication Bertrand Paquet <bertrand.paquet@doctolib.fr>
2016-06-02 14:16 ` Melvin Davidson <melvin6925@gmail.com>
2016-06-02 14:34 ` Scott Mead <scottm@openscg.com>
2016-06-02 15:02 ` Sameer Kumar <sameer.kumar@ashnik.com>
2016-06-02 16:39 ` John R Pierce <pierce@hogranch.com>
2016-06-04 13:59 ` Vik Fearing <vik@2ndquadrant.fr>
2016-06-04 13:58 ` Vik Fearing <vik@2ndquadrant.fr>
2016-06-06 07:54 ` Masahiko Sawada <sawada.mshk@gmail.com>
2016-06-06 08:22 ` Vik Fearing <vik@2ndquadrant.fr>
2016-06-06 08:53 ` Bertrand Paquet <bertrand.paquet@doctolib.fr>
2019-02-26 09:41 Replication Sonam Sharma <sonams1209@gmail.com>
2019-02-26 10:59 ` Andreas Kretschmer <andreas@a-kretschmer.de>
2019-02-26 11:39 ` Filip Rembiałkowski <plk.zuber@gmail.com>
2019-02-26 11:48 ` Steve Atkins <steve@blighty.com>
2025-04-25 13:50 replication Marc Millas <marc.millas@mokadb.com>
2025-04-25 14:19 ` Re: replication Achilleas Mantzios - cloud <a.mantzios@cloud.gatewaynet.com>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox