On Mon, Apr 06, 2009 at 09:07:05PM -0700, Lists wrote:
> Can you point me in the direction of the documentation for tuning it? I
> don't see anything in the documentation for tuning for write load.
No, exactly. As I said, it's a pain. The main thing you need to do
is to make sure that your set size is just right for your workload.
The only way to get this right, unhappily, is trial and error and a
bunch of oral-tradition rules of thumb. It's one of the weakest parts
of Slony from a user's point of view, IMO, but nobody's ever offered
to do the work to make really good tuning tools.
> Recently I had a problem with "duplicate key" errors on the slave, which
> shouldn't be possible since they keys are the same.
> I've just noticed in the documentation that
>
> The Duplicate Key Violation
> <http://www.slony.info/documentation/faq.html#DUPKEY> bug has helped
> track down a number of rather obscure PostgreSQL race conditions, so
> that in modern versions of Slony-I and PostgreSQL, there should be
> little to worry about.
>
> so that may no longer be an issue. However I experienced with this the
> latest Slony (as of late last year) and Postgresql 8.3.
That problem was quite an old one. "8.3" doesn't tell me very much,
but the issues should be covered there anyway. It is of course
logically possible that there is a bug. Often, however, the duplicate
key violations I've seen turn out to be from operator error. There
are a _lot_ of sharp, pointy bits in Slony administration, and it's
nearly trivial to make an apparently innocuous error that causes you
this sort of big pain.
> Also the dupe key error linked appears to be duplicate key of slony
> meta-data were as this was a duplicate key of one of my table's primary
> key.
This really ought to be impossible -- Slony just speaks standard SQL
statements between nodes. But I won't say there's no possible bug
there. Your best bet is the Slony list. It's a smallish community,
though, so you don't always get the response as fast as you want.
A
--
Andrew Sullivan
ajs@crankycanuck.ca