Update on replication
Update on replication:
We have several things happening with Postgres-R replication:
o Someone is porting the 7.2-based Postgres-R code to 7.3
o Darren and I are in discussion with the Spread folks,
attempting to get a more BSD-friendly license from them
o People are evaluating the Postgres-R approach and comparing
it to more traditional 2-phase commit replication.
With these things moving forward, we will be in a much better position
to get synchronous replication integrated in PostgreSQL.
--
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 19073Import Notes
Reply to msg id not found: 20021215213816.A31448@cnds.jhu.edu
o People are evaluating the Postgres-R approach and comparing
it to more traditional 2-phase commit replication.
Not that the Postgres-R approach can replace 2-phase commit methods.
2PC is still needed for support with external transaction managers (XA
drivers for JDBC).
--
Rod Taylor <rbt@rbt.ca>
PGP Key: http://www.rbt.ca/rbtpub.asc
Rod Taylor wrote:
-- Start of PGP signed section.
o People are evaluating the Postgres-R approach and comparing
it to more traditional 2-phase commit replication.Not that the Postgres-R approach can replace 2-phase commit methods.
2PC is still needed for support with external transaction managers (XA
drivers for JDBC).
Yes, good point. Let me add that eventually, I think we will have:
sync replication (Postgres-R?)
async replication, using PITR
PITR
two-phase commit for distributed transactions
--
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
On Tue, Dec 17, 2002 at 12:56:45PM -0500, Bruce Momjian wrote:
Update on replication:
We have several things happening with Postgres-R replication:
o Someone is porting the 7.2-based Postgres-R code to 7.3
You mean 7.4devel?
With these things moving forward, we will be in a much better position
to get synchronous replication integrated in PostgreSQL.
What about asynchronous (triggered?) replication? Is something like
rserv or dbmirror going to be moved to main?
--
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"Porque francamente, si para saber manejarse a uno mismo hubiera que
rendir examen... �Qui�n es el machito que tendr�a carnet?" (Mafalda)
Alvaro Herrera wrote:
On Tue, Dec 17, 2002 at 12:56:45PM -0500, Bruce Momjian wrote:
Update on replication:
We have several things happening with Postgres-R replication:
o Someone is porting the 7.2-based Postgres-R code to 7.3
You mean 7.4devel?
Sorry, right.
With these things moving forward, we will be in a much better position
to get synchronous replication integrated in PostgreSQL.What about asynchronous (triggered?) replication? Is something like
rserv or dbmirror going to be moved to main?
I think eventually we will have some async replication in the main
server, probably using PITR logs in some way.
--
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
I just got my copy of SysAdmin Magazine and was surprised to see an
article about Usogres -- The PostgreSQL Replication Tool.
I don't remember seeing it mentioned on this or the General list. Though
I just started reading the article and don't have a firm grasp on it yet,
I do remember a discussion of replication using this technique - described
in the first two paragraphs.
Fyi,
Rod
--
"Open Source Software - Sometimes you get more than you paid for..."
Roderick A. Anderson wrote:
I just got my copy of SysAdmin Magazine and was surprised to see an
article about Usogres -- The PostgreSQL Replication Tool.I don't remember seeing it mentioned on this or the General list. Though
I just started reading the article and don't have a firm grasp on it yet,
I do remember a discussion of replication using this technique - described
in the first two paragraphs.
I saw Usogres when I was first in Japan. Interesting in that is
intercepts queries and passes them two different servers.
--
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
On Tue, 17 Dec 2002, Alvaro Herrera wrote:
What about asynchronous (triggered?) replication? Is something like
rserv or dbmirror going to be moved to main?
From what I've been able to tell *so far*, Postgres-R is going to preclude
the ability for either to work ... Vadim is currently reviewing the code,
and based on his assessment of whether or not that is the case, I'm going
to be pushing for postgres-r to be its own project/fork of PostgreSQL,
like RedHat Database ...
Marc G. Fournier wrote:
On Tue, 17 Dec 2002, Alvaro Herrera wrote:
What about asynchronous (triggered?) replication? Is something like
rserv or dbmirror going to be moved to main?From what I've been able to tell *so far*, Postgres-R is going to preclude
the ability for either to work ... Vadim is currently reviewing the code,
and based on his assessment of whether or not that is the case, I'm going
to be pushing for postgres-r to be its own project/fork of PostgreSQL,
like RedHat Database ...
How is Postgres-R going to prevent async replication from also being
adopted in CVS?
--
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 19073ooops, sorry, that was what I meant (its been one of those days *grin*)
On Tue, 17 Dec 2002, Mikheev, Vadim wrote:
Show quoted text
From what I've been able to tell *so far*, Postgres-R is
going to preclude the ability for either to work ...
Vadim is currently reviewing the code,Not the code, just Darren' pdf ("slide show" -:()
and discussion in hackers' list._____________________________________________________
Sector Data, LLC, is not affiliated with Sector, Inc., or SIAC
Import Notes
Reply to msg id not found: 3705826352029646A3E91C53F7189E32518728@sectorbase2.sectorbase.comReference msg id not found: 3705826352029646A3E91C53F7189E32518728@sectorbase2.sectorbase.com | Resolved by subject fallback
Not the code, just Darren' pdf ("slide show" -:()
and discussion in hackers' list.
You might want to read this paper. Its not very long, and
will give you much more insite on the postgres-r work.
http://www.cs.mcgill.ca/~kemme/papers/vldb00.html
Darren
Import Notes
Resolved by subject fallback
"Marc G. Fournier" <scrappy@hub.org> writes:
On Tue, 17 Dec 2002, Alvaro Herrera wrote:
What about asynchronous (triggered?) replication? Is something like
rserv or dbmirror going to be moved to main?
From what I've been able to tell *so far*, Postgres-R is going to preclude
the ability for either to work ...
Why do you say that? If it can't coexist with other solutions, then it
surely will not be accepted, but I can't think of any reason why it
would preclude other approaches.
regards, tom lane
On Tue, 17 Dec 2002, Tom Lane wrote:
"Marc G. Fournier" <scrappy@hub.org> writes:
On Tue, 17 Dec 2002, Alvaro Herrera wrote:
What about asynchronous (triggered?) replication? Is something like
rserv or dbmirror going to be moved to main?From what I've been able to tell *so far*, Postgres-R is going to preclude
the ability for either to work ...
Why do you say that? If it can't coexist with other solutions, then it
surely will not be accepted, but I can't think of any reason why it
would preclude other approaches.
Okay, if this is the case, that does change things somewhat, but Bruce
seems to indiate that co-existance will be a problem:
========
Show quoted text
On Tue, 17 Dec 2002, Bruce Momjian wrote:
The other concern is how does integrating Postgres-R affect the ability to
investigate other solutions?As I said, I don't doubt taht there are aspects of Postgres-R that would
benefit the server as a whole, and those bits-n-pieces should be looked at
on an individual basis, but to just slap it in completely and hope that it
doesn't cause problems for alternative solutions is kinda irresponsible
...It certainly will cause problems with other replication solutions.
When I said:
It certainly will cause problems with other replication solutions.
I meant it would cause other solutions to be less desirable, meaning. as
you said, "affect the ability to investigate other solutions?" With a
working solution, others may be less likely to investigate because
Postgres-R will be our official solution. (I believe that was your
major negative point.) However, with the hooks already there, people
may be _more_ likely to investigate solutions, so there is really no way
to know.
---------------------------------------------------------------------------
Marc G. Fournier wrote:
On Tue, 17 Dec 2002, Tom Lane wrote:
"Marc G. Fournier" <scrappy@hub.org> writes:
On Tue, 17 Dec 2002, Alvaro Herrera wrote:
What about asynchronous (triggered?) replication? Is something like
rserv or dbmirror going to be moved to main?From what I've been able to tell *so far*, Postgres-R is going to preclude
the ability for either to work ...
Why do you say that? If it can't coexist with other solutions, then it
surely will not be accepted, but I can't think of any reason why it
would preclude other approaches.Okay, if this is the case, that does change things somewhat, but Bruce
seems to indiate that co-existance will be a problem:========
On Tue, 17 Dec 2002, Bruce Momjian wrote:
The other concern is how does integrating Postgres-R affect the ability to
investigate other solutions?As I said, I don't doubt taht there are aspects of Postgres-R that would
benefit the server as a whole, and those bits-n-pieces should be looked at
on an individual basis, but to just slap it in completely and hope that it
doesn't cause problems for alternative solutions is kinda irresponsible
...It certainly will cause problems with other replication solutions.
---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?
--
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 19073On Tue, 17 Dec 2002, Bruce Momjian wrote:
I meant it would cause other solutions to be less desirable, meaning. as
you said, "affect the ability to investigate other solutions?" With a
working solution, others may be less likely to investigate because
Postgres-R will be our official solution. (I believe that was your
major negative point.) However, with the hooks already there, people
may be _more_ likely to investigate solutions, so there is really no way
to know.
Okay, but if we are just adding hooks to allow Postgres-R to tie in, can't
those hooks be done in such a way as to be loadable, not compiled in?
Marc G. Fournier wrote:
On Tue, 17 Dec 2002, Alvaro Herrera wrote:
What about asynchronous (triggered?) replication? Is something like
rserv or dbmirror going to be moved to main?From what I've been able to tell *so far*, Postgres-R is going to preclude
the ability for either to work ... Vadim is currently reviewing the code,
and based on his assessment of whether or not that is the case, I'm going
to be pushing for postgres-r to be its own project/fork of PostgreSQL,
like RedHat Database ...How is Postgres-R going to prevent async replication from also being
adopted in CVS?
As far as I know, all trigger based async replication solutions have a
limitation. They do not handle high load (and probably cannot handle
large objects. am I correct?). I think we should move to other async
replication soltions, such as PostgreSQL-R or (not yet existing)
transaction log based replications.
--
Tatsuo Ishii
I just got my copy of SysAdmin Magazine and was surprised to see an
article about Usogres -- The PostgreSQL Replication Tool.I don't remember seeing it mentioned on this or the General list. Though
I just started reading the article and don't have a firm grasp on it yet,
I do remember a discussion of replication using this technique - described
in the first two paragraphs.
Glad to hear that. Usogres was developed in Japan and pretty popular
ammong Japanese PostgreSQL community.
BTW, there is a commercial product called QueryMaster, which takes
similar approach to Usogres. It copies the input query and distribute
to multiple PostgreSQL servers. As long as one of a server is working,
users even do not notice some of them are failing.
--
Tatsuo Ishii
On Wed, 18 Dec 2002, Tatsuo Ishii wrote:
I just got my copy of SysAdmin Magazine and was surprised to see an
article about Usogres -- The PostgreSQL Replication Tool.I don't remember seeing it mentioned on this or the General list. Though
I just started reading the article and don't have a firm grasp on it yet,
I do remember a discussion of replication using this technique - described
in the first two paragraphs.Glad to hear that. Usogres was developed in Japan and pretty popular
ammong Japanese PostgreSQL community.BTW, there is a commercial product called QueryMaster, which takes
similar approach to Usogres. It copies the input query and distribute
to multiple PostgreSQL servers. As long as one of a server is working,
users even do not notice some of them are failing.
How come these solutions are such well kept secrets? I've heard of
neither in relation to past discussions about replication, or have I just
missed them? :(
On Tue, 2002-12-17 at 19:38, Marc G. Fournier wrote:
On Wed, 18 Dec 2002, Tatsuo Ishii wrote:
I just got my copy of SysAdmin Magazine and was surprised to see an
article about Usogres -- The PostgreSQL Replication Tool.I don't remember seeing it mentioned on this or the General list. Though
I just started reading the article and don't have a firm grasp on it yet,
I do remember a discussion of replication using this technique - described
in the first two paragraphs.Glad to hear that. Usogres was developed in Japan and pretty popular
ammong Japanese PostgreSQL community.BTW, there is a commercial product called QueryMaster, which takes
similar approach to Usogres. It copies the input query and distribute
to multiple PostgreSQL servers. As long as one of a server is working,
users even do not notice some of them are failing.How come these solutions are such well kept secrets? I've heard of
neither in relation to past discussions about replication, or have I just
missed them? :(
Good questions. I've heard of Usogres, more or less in passing, but
heard it didn't work very well. Also heard that it wasn't reliable or a
serious solution. I seem to remember hearing that it only worked on
much older versions of PostgreSQL. Of course, I'm not attempting to
assert any true to what I've heard but since it's being talking about,
perhaps someone can clarify how well it REALLY works. Perhaps even
provide some more details on it?
Never heard of QueryMaster. Perhaps someone would like to talk a little
more about that as well?
--
Greg Copeland <greg@copelandconsulting.net>
Copeland Computer Consulting
On Tue, 17 Dec 2002, Greg Copeland wrote:
On Tue, 2002-12-17 at 19:38, Marc G. Fournier wrote:
On Wed, 18 Dec 2002, Tatsuo Ishii wrote:
I just got my copy of SysAdmin Magazine and was surprised to see an
article about Usogres -- The PostgreSQL Replication Tool.I don't remember seeing it mentioned on this or the General list. Though
I just started reading the article and don't have a firm grasp on it yet,
I do remember a discussion of replication using this technique - described
in the first two paragraphs.Glad to hear that. Usogres was developed in Japan and pretty popular
ammong Japanese PostgreSQL community.BTW, there is a commercial product called QueryMaster, which takes
similar approach to Usogres. It copies the input query and distribute
to multiple PostgreSQL servers. As long as one of a server is working,
users even do not notice some of them are failing.How come these solutions are such well kept secrets? I've heard of
neither in relation to past discussions about replication, or have I just
missed them? :(Good questions. I've heard of Usogres, more or less in passing, but
heard it didn't work very well. Also heard that it wasn't reliable or a
serious solution. I seem to remember hearing that it only worked on
much older versions of PostgreSQL. Of course, I'm not attempting to
assert any true to what I've heard but since it's being talking about,
perhaps someone can clarify how well it REALLY works. Perhaps even
provide some more details on it?Never heard of QueryMaster. Perhaps someone would like to talk a little
more about that as well?
Just checked on Usogres, and it appears to be relatively up to date, in
that it is known to work up to 7.2.1:
http://usogres.good-day.net/working.php3
Searching Google for QueryMaster finds a few Japanese sites, but I can't
read Japanese :(
Tatsuo, can you help?
