On Tuesday 06 February 2007 3:07 pm, Andrew Sullivan wrote:
> On Tue, Feb 06, 2007 at 02:37:12PM -0600, Dan Falconer wrote:
> > I'm not trying to blame-shift here, but it really seems like
> > the lag is generated from Slony itself. There's a stale
> > connection, initiated by Slony (that's the only thing that connects
> > on the private 192.168.1.x network), which sits idle in
> > transaction. On the master, the query shows as "fetch 100 from
> > LOG;" and shows on the slave as "<IDLE> in transaction".
>
> I think you're suffering from the log bloat problem. I'd try
> stopping slony, performing vacuum analyse on that table, and then
> starting again. But my real guess is that this approach is not going
> to work very well for you. :(
>
> A
I'm confused. It kinda sounds like you're saying "Slony isn't going to
work
very well for me". Previous to my upgrade to 1.2.6 (back in the 1.1.0 days),
Slony worked great for replicating, and it was just average when it came to
rebuilding off the master. Am I missing something here? I don't want to
piss anybody off, but... well, I'm frustrated. And Slony used to be able to
handle the load.
Ever since the DBA thing was dropped on my lap, I've been a huge
supporter of
Slony. I would hate to see my company drop use of Slony because it can't
keep up with our workload: I'm sure the "system" that would take over would
be nothing more than a series of poorly written scripts that continuously
rebuild our slave server. :( Somebody help me out here.
--
Best Regards,
Dan Falconer
"Head Geek",
AvSupport, Inc. (http://www.partslogistics.com)
_______________________________________________
Slony1-general mailing list
[email protected]
http://gborg.postgresql.org/mailman/listinfo/slony1-general
