On Tuesday 06 February 2007 1:36 pm, Andrew Sullivan wrote:
> On Tue, Feb 06, 2007 at 12:58:27PM -0600, Dan Falconer wrote:
> > alll added up to this problem (the inventory changes all happen within a
> > single massive transaction block). The slave appears to be trying to
> > catch
>
> This is your problem. If all those go in one block on the origin,
> then they're more or less guaranteed to go in one block on the
> replica.
>
> How long does the transaction on the origin take? If it takes
> dramatically longer than that on the replica, is there something up
> with the query plans on the replica?
>
> A
After talking to one the techs that's more "in tune" with how our
inventory
system works, I found out that the "one massive transaction block" part was a
lie: it's broken into a single transaction per vendor. That means that the
2.4M rows of changes were done in ~50 transactions. It took the master about
16.5 hours to burn through all of that: I would think the slave database
should be catching-up in spurts, not consistently lagging behind.
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".
Anyway, all that aside: how do I figure out what it's tripping-up on?
The
"_pl_replication.sl_log_2" table is sitting at 10.3M records, and is growing
fairly rapidly. When I initially added the slave node, it took around 4
hours to get completely up-to-date with the master... and now it's falling
mysteriously behind? I'm trying to avoid restarting slony, or
dropping/adding the node, just because I always seem to do that when things
are 99.999% done, thinking it'll save time. :( Any advice on this matter
would be very appreciated.
--
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
