Обсуждение: Replication
Hi folks, Does anyone know a solution for replicating a PG7.2 Database. We'd prefer a bidirectional replication but it doesn't haveto be that way. A simple one-way-rep would match our basic interests as well. The documentation of the eRServer on postgres.comdoes not give very much detailed information about f.e. the integrated features - or I didn't find them. Actually it would be nice to get an open source solution because of the very nice licence model. But our main focus is setto a _stable_ and _performant_ solution. At first we want to replicate from one Master to one slave, but in the near futureit seems that the environment would extend to about five slaves. Thanks for answering! ______________________________________________________________________________ Ab heute wird nichts mehr vergessen! Mit dem Organizer von WEB.DE FreeMail. http://freemail.web.de/features/?mc=021145
On Thu, Jan 23, 2003 at 11:38:25AM +0100, Enrico Ortmann wrote:
>
> Hi folks,
>
> Does anyone know a solution for replicating a PG7.2 Database. We'd
> prefer a bidirectional replication but it doesn't have to be that
> way. A simple one-way-rep would match our basic interests as well.
> The documentation of the eRServer on postgres.com does not give
> very much detailed information about f.e. the integrated features -
> or I didn't find them.
There's not much in the way of integrated features. More or less,
you get (possibly more than one) slave replicated from one master.
The model is async., so there is a gap between the transaction on the
master and it committing on the slave. It's a _small_ gap, but it is
there.
> the very nice licence model. But our main focus is set to a
> _stable_ and _performant_ solution. At first we want to replicate
> from one Master to one slave, but in the near future it seems that
> the environment would extend to about five slaves.
We are currently using eRServer for the .info registry, and starting
next week it will also underpin the .org registry. Dunno if that's
good enough performance for you. It works for us.
A
--
----
Andrew Sullivan 204-4141 Yonge Street
Liberty RMS Toronto, Ontario Canada
<andrew@libertyrms.info> M2P 2A8
+1 416 646 3304 x110
"Andrew Sullivan" <andrew@libertyrms.info> wrote in message news:20030123135353.E4693@mail.libertyrms.com... > We are currently using eRServer for the .info registry, and starting > next week it will also underpin the .org registry. Dunno if that's > good enough performance for you. It works for us. the eRServer is for free or not ? Ciao Gaetano
On Mon, Jan 27, 2003 at 07:38:29PM +0100, Gaetano Mendola wrote:
>
> the eRServer is for free or not ?
"Not", as far as I know. Its baby cousin is in contrib/rserv in the
source tree. I haven't tested it with 7.3, so I don't know whether
it works.
A
--
----
Andrew Sullivan 204-4141 Yonge Street
Liberty RMS Toronto, Ontario Canada
<andrew@libertyrms.info> M2P 2A8
+1 416 646 3304 x110
On Mon, 27 Jan 2003, Andrew Sullivan wrote: > On Mon, Jan 27, 2003 at 07:38:29PM +0100, Gaetano Mendola wrote: > > > > the eRServer is for free or not ? > > "Not", as far as I know. Its baby cousin is in contrib/rserv in the > source tree. I haven't tested it with 7.3, so I don't know whether > it works. Don't ... from everything we have heard, there are a half-dozen companies out there that have taken the time to figure out and get it to work, but nobody has bothered to submit patches back to the project to make it easier/more useful for others ... eRServer is to rserv what running Unix on a PIII is to running it on a 386 ... for v7.4, we are most likely going to move rserv over to gborg ...
I would give /contrib/dbmirror a try. --------------------------------------------------------------------------- Marc G. Fournier wrote: > On Mon, 27 Jan 2003, Andrew Sullivan wrote: > > > On Mon, Jan 27, 2003 at 07:38:29PM +0100, Gaetano Mendola wrote: > > > > > > the eRServer is for free or not ? > > > > "Not", as far as I know. Its baby cousin is in contrib/rserv in the > > source tree. I haven't tested it with 7.3, so I don't know whether > > it works. > > Don't ... from everything we have heard, there are a half-dozen companies > out there that have taken the time to figure out and get it to work, but > nobody has bothered to submit patches back to the project to make it > easier/more useful for others ... > > eRServer is to rserv what running Unix on a PIII is to running it on a 386 > ... for v7.4, we are most likely going to move rserv over to gborg ... > > > ---------------------------(end of broadcast)--------------------------- > TIP 1: subscribe and unsubscribe commands go to majordomo@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
On Mon, 2003-01-27 at 21:10, Marc G. Fournier wrote: > On Mon, 27 Jan 2003, Andrew Sullivan wrote: > > > On Mon, Jan 27, 2003 at 07:38:29PM +0100, Gaetano Mendola wrote: > > > > > > the eRServer is for free or not ? > > > > "Not", as far as I know. Its baby cousin is in contrib/rserv in the > > source tree. I haven't tested it with 7.3, so I don't know whether > > it works. > > Don't ... from everything we have heard, there are a half-dozen companies > out there that have taken the time to figure out and get it to work, but > nobody has bothered to submit patches back to the project to make it > easier/more useful for others ... > > eRServer is to rserv what running Unix on a PIII is to running it on a 386 > ... for v7.4, we are most likely going to move rserv over to gborg ... > Hrmm, this is kind of sad. rserv actually does work pretty well. We use it in a production environment here at OFS on a medium size database cluster. The biggest issue we had was when we created replication id's to use was that we used bigint field type for the id. Which as we all know suck rocks to use in postgres. Once we specifically cast the field to let it use the index the whole thing just magically worked nice and fast. Note that it did work before it just worked a whole lot slower. What problems have been reported with 7.3? Additionally, aren't the eRserver maintainers in theory releasing updates to rserv every year or so? ( At least that's what has been said in the past. ) What problems have people been having getting rserv to work at all? Will LaShell
Вложения
On Tue, 28 Jan 2003, Will LaShell wrote: > Hrmm, this is kind of sad. rserv actually does work pretty well. We use > it in a production environment here at OFS on a medium size database > cluster. I think you are the first person taht I've seen that has admit'd to using it ... other then a few 'build related' issues, I've never seen anyone do anything with it ... > The biggest issue we had was when we created replication id's to use was > that we used bigint field type for the id. Which as we all know suck > rocks to use in postgres. Once we specifically cast the field to let it > use the index the whole thing just magically worked nice and fast. Note > that it did work before it just worked a whole lot slower. > > What problems have been reported with 7.3? The biggest one I've heard: documentation sucks > Additionally, aren't the eRserver maintainers in theory releasing > updates to rserv every year or so? ( At least that's what has been said > in the past. ) Actually, eRServer right now is nowhere near what you are using right now ... over the past few months, its been re-written in Java and is now multi-slave ... I got my first "live" experience with it this past weekend (I did alot of work on the new perl scripts for administrative, but never had time to actually get it live) ... we used PgMarket as a 'test' case for a demo, and setup consisted of: ./ers_setup <args> (sets up master and initial slave) and a foreach loop based on a psql -l on the database to run: ./ers_addtable <tablename> The servers were configured so that if you pull'd the plug out of the master server, everything auto-fail'd over to the slave, so that it was transparent to anyone hitting the site ... we even had the web servers themselves in a failover state ...
Hi folks! Is anybody using pgReplicator? <http://pgreplicator.sourceforge.net/> I've read through the documentation but haven't tried it yet. I'm looking for a solution that can offer asynchronous, update-anywhere replication. Conflict resolution is not an issue. It seems that pgReplicator would do what is needed... cheers Fabian
On Tue, Jan 28, 2003 at 09:59:52AM -0700, Will LaShell wrote:
> What problems have people been having getting rserv to work at all?
In 2001 I tested it for our anticipated load. It worked for me, but
it was not up to the kind of load that we were anticipating. It was
reasonable, however, and I was not able to break it; it just wasn't
up to the load I had to plan for. We also needed multi-salve
replication. We therefore did some work with PostgreSQL, Inc. to
produce a new, somewhat better version of rserv. That's what we
still use in our production systems.
So I have not had problems getting rserv to work, but it wasn't
enough for us. I wouldn't hesitate to recommend it to others,
though: the strategy is sound, and if it meets your needs, it'll
probably do fine (assuming it still works with 7.3; when I was
testing, remember, 7.1.x was the released version). I seem to recall
keeping it busy with several hundred transactions per minute, but
whether that was sustainable I don't know.
A
--
----
Andrew Sullivan 204-4141 Yonge Street
Liberty RMS Toronto, Ontario Canada
<andrew@libertyrms.info> M2P 2A8
+1 416 646 3304 x110
On Tue, 2003-01-28 at 12:42, Fabian Peters wrote: > Hi folks! > > Is anybody using pgReplicator? <http://pgreplicator.sourceforge.net/> > > I've read through the documentation but haven't tried it yet. I'm looking > for a solution that can offer asynchronous, update-anywhere replication. > Conflict resolution is not an issue. It seems that pgReplicator would do > what is needed... > When I looked last it was in a very beta state and noone advised using it for production work. This may have changed though. Usogres also is listed as a viable replication option, but it doesn't work at all, and has even worse documentation. > cheers > > Fabian > Will
Вложения
On Tue, 28 Jan 2003, Will LaShell wrote: > > The biggest one I've heard: documentation sucks > > This truely is an issue, the documentation can be painful, however in > reality there is very little to do with it. Run the master / slave setup > add the tables, and run the replicate. I think perhaps the greatest > documentation work could be done in terms of setup examples, and more > explanation of the arguments to the various scripts. would you be willing to submit such? we're working on packaging up a 7.2.4 for this week, if all goes well, and this would be nice to throw in ... ? > This is excellent! Now the real question is when will we see this type > of functionality released back into the community, or will there be no > future updates of rserv at all? Or? Worst case scenario, eRServer v1.2 (what I'm talking about here) will be released by next Xmas(ish) ... there are some features/enhancements that we are working on right now that will, for our clients, obsolete eRServer v1.2, so if all goes well, releasing it to the community will happen sooner ...
On Tue, 2003-01-28 at 14:12, Andrew Sullivan wrote: > On Tue, Jan 28, 2003 at 09:59:52AM -0700, Will LaShell wrote: > > What problems have people been having getting rserv to work at all? > > In 2001 I tested it for our anticipated load. It worked for me, but > it was not up to the kind of load that we were anticipating. It was > reasonable, however, and I was not able to break it; it just wasn't > up to the load I had to plan for. We also needed multi-salve > replication. We therefore did some work with PostgreSQL, Inc. to > produce a new, somewhat better version of rserv. That's what we > still use in our production systems. > > So I have not had problems getting rserv to work, but it wasn't > enough for us. I wouldn't hesitate to recommend it to others, > though: the strategy is sound, and if it meets your needs, it'll > probably do fine (assuming it still works with 7.3; when I was > testing, remember, 7.1.x was the released version). I seem to recall > keeping it busy with several hundred transactions per minute, but > whether that was sustainable I don't know. > > A I definitely agree with this analysis. The biggest thing with getting rserv to work fast, is using the right replication field id. We elected to use a bigint, created an index only on it and treat it special. If I get inspired I could post up some performance metrics if anyone cares to be interested. I have looked at eRserv in the past, the problem is the price. It's just a bit high to convince the people here to use. Hopefully I can get them to change their minds. Sincerely, Will LaShell
Вложения
On Tue, 2003-01-28 at 11:01, Marc G. Fournier wrote: > On Tue, 28 Jan 2003, Will LaShell wrote: > > > Hrmm, this is kind of sad. rserv actually does work pretty well. We use > > it in a production environment here at OFS on a medium size database > > cluster. > > I think you are the first person taht I've seen that has admit'd to using > it ... other then a few 'build related' issues, I've never seen anyone do > anything with it ... Odd, for a lot of uses at least up to pg version 7.2 it just works well. > > The biggest issue we had was when we created replication id's to use was > > that we used bigint field type for the id. Which as we all know suck > > rocks to use in postgres. Once we specifically cast the field to let it > > use the index the whole thing just magically worked nice and fast. Note > > that it did work before it just worked a whole lot slower. > > > > What problems have been reported with 7.3? > > The biggest one I've heard: documentation sucks This truely is an issue, the documentation can be painful, however in reality there is very little to do with it. Run the master / slave setup add the tables, and run the replicate. I think perhaps the greatest documentation work could be done in terms of setup examples, and more explanation of the arguments to the various scripts. > > Additionally, aren't the eRserver maintainers in theory releasing > > updates to rserv every year or so? ( At least that's what has been said > > in the past. ) > > Actually, eRServer right now is nowhere near what you are using right now > ... over the past few months, its been re-written in Java and is now > multi-slave ... I got my first "live" experience with it this past > weekend (I did alot of work on the new perl scripts for administrative, > but never had time to actually get it live) ... we used PgMarket as a > 'test' case for a demo, and setup consisted of: > > ./ers_setup <args> (sets up master and initial slave) > > and a foreach loop based on a psql -l on the database to run: > > ./ers_addtable <tablename> > > The servers were configured so that if you pull'd the plug out of the > master server, everything auto-fail'd over to the slave, so that it was > transparent to anyone hitting the site ... we even had the web servers > themselves in a failover state ... > This is excellent! Now the real question is when will we see this type of functionality released back into the community, or will there be no future updates of rserv at all? Or? Sincerely, Will LaShell