Aleksey Tsalolikhin <[email protected]> writes:
> Hi. We're using 1.2.20 right now. It's not the latest version either
> way you look at it. Should we upgrade to 1.2.21 or 2.0.5?
>
> We have 2 replication sets now: the whole shebang, and selected tables
> and sequences.
>
> It's working really well.
>
> Our only pain points are listed below. Would upgrading to 2.0.5
> help with these? Or if there is some other compelling reason to
> move from 1.x branch to 2.x? So far the only difference I was able
> to fathom is that replicating sequences is much much more efficient
> in 2.x. Is there anything else?
>
> Our pain points are:
>
> - the database runs a bit slower slower when replication is enabled.
>
> Slony seems to have quite a bit of overhead:
>
> I see it doing about 890 inserts per second, and same again for
> deletes. that's 1780 SQL ops per second.
>
> By comparison, updates (and slony does not use updates AFAIK so this is
> my application's queries) run about 20 updates per second.
>
> I don't yet understand why we have a 1:89 ratio between updates by the
> application and Slony inserts/deletes. I don't know Slony internals
> well enough yet. But would going to 2.x change that ratio?
> We do replicate sequences.
BTW, Slony *does* do UPDATEs; pulling the little bit from
src/slon/remote_worker.c:
/*
* Add the actual replicating command to the line buffer
*/
line->line_largemem += largemem;
switch (*log_cmdtype)
{
case 'I':
slon_appendquery(&(line->data),
"insert into %s %s;\n",
wd->tab_fqname[log_tableid],
log_cmddata);
num_inserts ++;
break;
case 'U':
slon_appendquery(&(line->data),
"update only %s set
%s;\n",
wd->tab_fqname[log_tableid],
log_cmddata);
num_updates ++;
break;
case 'D':
slon_appendquery(&(line->data),
"delete from only %s where
%s;\n",
wd->tab_fqname[log_tableid],
log_cmddata);
num_deletes ++;
break;
}
The 'U' bit in the middle does updates :-).
Do you have a lot of sequences?
In 1.2, every sequence gets its values updated every time a SYNC is
processed, which means that if you have a bunch that are seldom touched,
they'll lead to quite a few updates travelling around.
In 2.0, the sequence handling is rather lazier; if the value hasn't
changed since the last SYNC, the slon doesn't bother propagating
anything for that sequence.
If you've got 80 sequences, that's 80-ish updates per SYNC that are
present/absent, which could be a big chunk of what you're seeing.
There are also significant changes in 2.0 in how sl_log_1/2 are trimmed,
which should be helpful. But I don't expect that's what you're
observing.
> - sometimes after the slave goes offline, or there is a WAN problem,
> the check_postgres.pl Nagios plug-in (check_slony) reports the slave
> as lagged, even after the slave and master are both online and can
> talk to each other -- restarting the slon master and slave resolves this.
> Otherwise the replication lag time does not decrement / catch up, but
> falls further behind with the clock.
>
> So do we have a good reason to go to 2.x? Or should we let it shake out
> a bit longer?
Well, we've kept releasing 2.0.x versions, which hasn't been a good
thing. But 2.0.5 comes out of having shaken things pretty hard, which
led to >>20 bugs being fixed. And Steve & Jan have both been running a
lot of tests *after* the committing of all the relevant patches; it has
been two weeks since the last bug fix was committed.
This *should* imply pretty good things for 2.0.5.
--
output = reverse("ofni.sailifa.ac" "@" "enworbbc")
Christopher Browne
"Bother," said Pooh, "Eeyore, ready two photon torpedoes and lock
phasers on the Heffalump, Piglet, meet me in transporter room three"
_______________________________________________
Slony1-general mailing list
[email protected]
http://lists.slony.info/mailman/listinfo/slony1-general
