Обсуждение: Replication in main PostgreSQL codebase
Hello all! I apologise in advance if any of my questions are in a FAQ somewhere - I haven't seen them... Does anyone know when (if ever) replication support will be added to the main PostgreSQL codebase? Is there any chance it'll be included in the upcoming 7.5 release? I've taken a look at the replication solutions already available, including the sterling effort made on Slony-I, but we're really looking for integrated, base-level support rather than an add-in. Cheers!
After a long battle with technology, list.pgsql-admin@picton.net ("Matt Browne"), an earthling, wrote:
> I apologise in advance if any of my questions are in a FAQ somewhere - I
> haven't seen them...
>
> Does anyone know when (if ever) replication support will be added to the
> main PostgreSQL codebase? Is there any chance it'll be included in the
> upcoming 7.5 release?
Not much of a chance.
> I've taken a look at the replication solutions already available,
> including the sterling effort made on Slony-I, but we're really
> looking for integrated, base-level support rather than an add-in.
The problem is that "replication" doesn't tend to mean one thing, but
people rather have different ideas of what it means.
Jan Wieck puts it fairly nicely:
"The number of different replication solutions available supports
the theory that ``one size fits all'' is not true when it comes to
database replication."
--
let name="cbbrowne" and tld="acm.org" in name ^ "@" ^ tld;;
http://www.ntlug.org/~cbbrowne/emacs.html
You shouldn't anthropomorphize computers; they don't like it.
On 06 July 2004 16:41, Christopher Browne wrote: > > I've taken a look at the replication solutions already available, > > including the sterling effort made on Slony-I, but we're really > > looking for integrated, base-level support rather than an add-in. > > The problem is that "replication" doesn't tend to mean one > thing, but people rather have different ideas of what it means. I don't necessarily agree with that. It's true that one size hardly ever fits all, especially when it comes to implementation, but I think people have a certain replication feature set in mind when they come across a DBMS that purports to be enterprise-class... ... Just like what's been listed in the 'Urgent' section of the TODO list since (I think) 7.2, in fact. (Except perhaps the more complex features like multi-master replication.) I didn't post my original message to the pgsql-hackers list because I wanted to respect the ominous warning about trying other lists first. Not to discount your comments, Christopher, but is there anyone on this list who could give me an official and authoritative line on the inclusion of in-built replication functionality? Thanks again!
On Tue, 6 Jul 2004, Matt Browne wrote: > On 06 July 2004 16:41, Christopher Browne wrote: >>> I've taken a look at the replication solutions already available, >>> including the sterling effort made on Slony-I, but we're really >>> looking for integrated, base-level support rather than an add-in. >> >> The problem is that "replication" doesn't tend to mean one >> thing, but people rather have different ideas of what it means. > > I don't necessarily agree with that. It's true that one size hardly ever > fits all, especially when it comes to implementation, but I think people > have a certain replication feature set in mind when they come across a DBMS > that purports to be enterprise-class... > > ... Just like what's been listed in the 'Urgent' section of the TODO list > since (I think) 7.2, in fact. (Except perhaps the more complex features like > multi-master replication.) > > I didn't post my original message to the pgsql-hackers list because I wanted > to respect the ominous warning about trying other lists first. > > Not to discount your comments, Christopher, but is there anyone on this list > who could give me an official and authoritative line on the inclusion of > in-built replication functionality? Christopher is correct ... if there was such a thing as an 'end all, be all' replication solution, there wouldn't be a half a dozen different ones out there ... It would be unwise for *anyone* to state "never" as far as inclusion of built-in replication, but since the general consensus is that there is no such thing as the 'all-encompassing solution' for this, the chances of one ever coming about that would be of a scope that would be acceptable to be built-in is next to zero ... ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
Marc G. Fournier wrote:
> Christopher is correct ... if there was such a thing as an 'end all, be
> all' replication solution, there wouldn't be a half a dozen different ones
> out there ...
>
> It would be unwise for *anyone* to state "never" as far as inclusion of
> built-in replication, but since the general consensus is that there is no
> such thing as the 'all-encompassing solution' for this, the chances of one
> ever coming about that would be of a scope that would be acceptable to be
> built-in is next to zero ...
OK, I reworded the replication TODO section and moved it under
Administration:
* Improve replication solutions
o Automatic failover
o Load balancing
o Master/slave replication
o Multi-master replication
o Partition data across servers
o Queries across databases or servers (two-phase commit)
o Allow replication over unreliable or non-persistent links
--
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, 6 Jul 2004 17:07:33 -0300 (ADT), Marc G. Fournier <scrappy@postgresql.org> wrote: > It would be unwise for *anyone* to state "never" as far as inclusion of > built-in replication, but since the general consensus is that there is no > such thing as the 'all-encompassing solution' for this, the chances of one > ever coming about that would be of a scope that would be acceptable to be > built-in is next to zero ... I think what I run into is that while most of us would agree that the "one size fits all" argument is useless from a technical perspective, it's not the technical people that are usually the ones involved here. From a "marketing" perspective, it would be useful if PostgreSQL included at least a single master, single slave replication model that was easily enabled and set up. There is a subclass of the problem that is common to most situations, which is the ability to have a "live" backup. Perhaps the 'dbmirror' component in the 'contrib' directory is enough, and it simply needs to be highlighted. It does meet some subset of the needs out there. Sadly, a lot of problems are simply marketing perceptions :/ Chris -- | Christopher Petrilli | petrilli@gmail.com
Marc G. Fournier wrote: > Christopher is correct ... if there was such a thing as an 'end all, > be all' replication solution, there wouldn't be a half a dozen > different ones out there ... Which ones are you thinking of in your count? I don't get anywhere near half a dozen.
Christopher Browne wrote: > Jan Wieck puts it fairly nicely: > > "The number of different replication solutions available supports > the theory that ``one size fits all'' is not true when it comes to > database replication." The fact that all but one or two replication solutions out there are pretty much dead supports the theory that "one size fits most" is true.
On Tue, 6 Jul 2004, Peter Eisentraut wrote: > Marc G. Fournier wrote: >> Christopher is correct ... if there was such a thing as an 'end all, >> be all' replication solution, there wouldn't be a half a dozen >> different ones out there ... > > Which ones are you thinking of in your count? I don't get anywhere near > half a dozen. erserver, slony, dbmirror are off the top of my head for OSS ones ... then Command Prompt has their replication solution, so that's four ... wasn't there one out of russia? I can't recall the name of it though :( apparently someone is still working on pgreplication ... ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
Marc G. Fournier wrote: > On Tue, 6 Jul 2004, Peter Eisentraut wrote: > > > Marc G. Fournier wrote: > >> Christopher is correct ... if there was such a thing as an 'end all, > >> be all' replication solution, there wouldn't be a half a dozen > >> different ones out there ... > > > > Which ones are you thinking of in your count? I don't get anywhere near > > half a dozen. > > erserver, slony, dbmirror are off the top of my head for OSS ones ... then > Command Prompt has their replication solution, so that's four ... wasn't > there one out of russia? I can't recall the name of it though :( > apparently someone is still working on pgreplication ... And pgcluster, which does multi-master. -- 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
Bruce Momjian wrote: > OK, I reworded the replication TODO section and moved it under > Administration: > > * Improve replication solutions > o Automatic failover The Automatic failover is already available, we use the RH cluster solution and it works really well, we never had a failure till now but all the our simulations ( power off, hardware failure ) are working well. We have almost 3 year of 24/24 7/7 without macro interruption, only fews minutes during the 7.0 -> 7.1 -> ... -> 7.4 upgrades. With the RH solution we are also able to perform the minor upgrades ( 7.4.1 -> 7.4.2 for example ) without one single minute of interruption: 1) Upgrade on passive node2) Relocation service 3) Upgrade on the active node4) Relocation service it would be great from this point of view if the pg_upgrade could handle also the major version upgrade without need to dump, init, reload the db. Regards Gaetano Mendola
Christopher Browne wrote:
> After a long battle with technology, list.pgsql-admin@picton.net ("Matt Browne"), an earthling, wrote:
>
>>I apologise in advance if any of my questions are in a FAQ somewhere - I
>>haven't seen them...
>>
>>Does anyone know when (if ever) replication support will be added to the
>>main PostgreSQL codebase? Is there any chance it'll be included in the
>>upcoming 7.5 release?
>
>
> Not much of a chance.
>
>
>>I've taken a look at the replication solutions already available,
>>including the sterling effort made on Slony-I, but we're really
>>looking for integrated, base-level support rather than an add-in.
>
>
> The problem is that "replication" doesn't tend to mean one thing, but
> people rather have different ideas of what it means.
>
> Jan Wieck puts it fairly nicely:
>
> "The number of different replication solutions available supports
> the theory that ``one size fits all'' is not true when it comes to
> database replication."
We all agree on that, postgres is hiding behind this concept as well
MySQL did till now with stored procedure, referencial integrity, transaction
bla bla bla
Most of the time the first question that I receive is: it's possible replicate
my data in an other database in order to perform heavy queries on it without
affect the master performances? You have to see the faces when the answer is:
with an add-in.
I believe that with the PITR + NT an or more integrated solutions in postgres
are not too far away to be developed
Regards
Gaetano Mendola