what is happening on the subscriber side?

Hi everyone,

Just wanted to look for an explanation regarding what happens on the
subscriber's end of a replication set.  I currently have 4 nodes (1 thru
4), and node 4 also has the "-a <dir>" flag turned on for log shipping (but
I think this is irrelevant)

Occasionally, I will see in test_slony_state_dbi.pl, that one of the
subscribers has really old events or that the provider is lagging behind
the provider, so I decided to harvest some data.  Wrote up a cronjob that
will fetch the average slony lag on node 4 (I could've picked any of them,
but just chose this one because load was lowest).

Basically, I ran this command from the shell every hour:  `psql -tc
"select avg(st_lag_time) from _slony_schema.sl_status" mydb postgres`

Now, I logged it into a file (http://pgsql.privatepaste.com/e4ce8f8f67)
and it shows that the other nodes average > 70 days'  worth of lag at
times.  (see period from May 10 to Jul 09)

There are 3 other replication clusters I tracked, and one of them even
went up to 153 days before dropping right back down to zero.

Could someone explain why this happens, or perhaps more importantly--what
causes the lag to drop from high 70s of days down to 0.  Is it sl_log_{1,2}
rotation?

Sorry, I might be able to find the answer by scouring the logs, but I'm
hoping to find a quick answer here.

Re: what is happening on the subscriber side?

dba@... wrote:
> Hi everyone,
> 
> Just wanted to look for an explanation regarding what happens on the
> subscriber's end of a replication set.  I currently have 4 nodes (1 thru
> 4), and node 4 also has the "-a <dir>" flag turned on for log shipping (but
> I think this is irrelevant)

> 
> Occasionally, I will see in test_slony_state_dbi.pl, that one of the
> subscribers has really old events or that the provider is lagging behind
> the provider, so I decided to harvest some data.  Wrote up a cronjob that
> will fetch the average slony lag on node 4 (I could've picked any of them,
> but just chose this one because load was lowest).
> 
>

> Using Slony 2.0.3, postgres 8.4.2 on CentOS 2.6.18 on all nodes.

1.  You should upgrade right away to 2.0.4.  Slony 2.0.3 has a rather 
serious memory corruption bug.  (the bug was not present in 2.0.2).

2. What you describe sounds like bug 127 
(http://bugs.slony.info/bugzilla/show_bug.cgi?id=127) which is present 
in any recent 1.2.x version and in all currently released 2.0.x versions 
but has been fixed in git and is planned to be included in 2.0.5

> 
> Much appreciated!
> --Richard

slony1-2.0.x ready for production?

Would you consider slony1-2.0.4 as ready for production use?  i recall a thread from December indicating
that 2.0.3 was not ready for production use.

---
Jeff Frost <jeff@...>
CTO, PostgreSQL Experts, Inc.
Phone: 1-888-PG-EXPRT x506
FAX: 415-762-5122
http://www.pgexperts.com/ 

Re: slony1-2.0.x ready for production?

On 3 September 2010 00:30, Jeff Frost <jeff@...> wrote:
> Would you consider slony1-2.0.4 as ready for production use?  i recall a thread from December
indicating that 2.0.3 was not ready for production use.
>

That was due to a bug that broke replication that wasn't caught during
the release candidate process. Slony 2.0.4 is unaffected (in fact,
Slony 2.0.4 is, as far as I know, exactly the same but for the fact
that it's unaffected).
--

-- 
Regards,
Peter Geoghegan

Re: slony1-2.0.x ready for production?

Jeff Frost wrote:
> Would you consider slony1-2.0.4 as ready for production use?  i recall a thread from December indicating
that 2.0.3 was not ready for production use.
> 

We hope to be able to tag a release candidate for 2.0.5 sometime next 
week.  We plan on giving  2.0.5 (once it is released) a thumbs up for 
production use internally.

During the past few months we have done a fair amount testing of slony 
and review of old bugs.  The release notes in progress for 2.0.5 
(http://git.postgresql.org/gitweb?p=slony1-engine.git;a=blob;f=RELEASE;h=ee95676bb946a9310e189d99ba3828763e1542fd;hb=d747d9c97beeace62a1798e9b81807ca5727de3c)
should give you a sense of what we have fixed since 2.0.4 and that 
should help you make a decision on if you can live with 2.0.4 for your 
purposes.  A lot of the issues listed aren't unique to 2.0.x but are 
also present in 1.2.x if you where to look for them.

I'm going to encourage you (and others) to find some time to do your own 
testing of the release candidate.

Hope that helps.

> ---
> Jeff Frost <jeff@...>
> CTO, PostgreSQL Experts, Inc.
> Phone: 1-888-PG-EXPRT x506
> FAX: 415-762-5122
> http://www.pgexperts.com/ 
> 
> 

setting up replicating system between OS's

Hi,

so here's the situation: I've got a Slony cluster running between a
unix master and a linux slave. These are running Slony version 1.2.21.
Now I want to add a second slave on a Windows machine as well, but
from looking on the official Slony web page I can see there're no Win
binary installers for version 1.2.21. What should I do? Do I have to
change to another Slony version on the machines already in the Slony
cluster?

--

-- 
Ulas Albayrak
ulas.albayrak@...

Re: setting up replicating system between OS's

On 08/09/2010 12:57, Ulas Albayrak wrote:

> so here's the situation: I've got a Slony cluster running between a
> unix master and a linux slave. These are running Slony version 1.2.21.
> Now I want to add a second slave on a Windows machine as well, but
> from looking on the official Slony web page I can see there're no Win
> binary installers for version 1.2.21. What should I do? Do I have to
> change to another Slony version on the machines already in the Slony
> cluster?

The easiest way to get Slony for Windows is probably via the 
StackBuilder application which comes with the One-Click installer for 
Windows, built by EnterpriseDB.

Ray.

--

-- 
Raymond O'Donnell :: Galway :: Ireland
rod@...

Fwd: setting up replicating system between OS's

That was my initial idea but Stackbuilder on my Win machine only
offers Slony-I version 2.0.4-1. As far as I know all machines in a
cluster needs to be running the same verision of Slony?

On Wed, Sep 8, 2010 at 2:53 PM, Raymond O'Donnell <rod@...> wrote:
> On 08/09/2010 12:57, Ulas Albayrak wrote:
>
>> so here's the situation: I've got a Slony cluster running between a
>> unix master and a linux slave. These are running Slony version 1.2.21.
>> Now I want to add a second slave on a Windows machine as well, but
>> from looking on the official Slony web page I can see there're no Win
>> binary installers for version 1.2.21. What should I do? Do I have to
>> change to another Slony version on the machines already in the Slony
>> cluster?
>
> The easiest way to get Slony for Windows is probably via the StackBuilder
> application which comes with the One-Click installer for Windows, built by
> EnterpriseDB.
>
> Ray.
>
> --
> Raymond O'Donnell :: Galway :: Ireland
> rod@...
>

--
Ulas Albayrak
ulas.albayrak@...

Fwd: setting up replicating system between OS's

That was my initial idea but Stackbuilder on my Win machine only
offers Slony-I version 2.0.4-1. As far as I know all machines in a
cluster needs to be running the same verision of Slony?

On Wed, Sep 8, 2010 at 2:53 PM, Raymond O'Donnell <rod@...> wrote:
> On 08/09/2010 12:57, Ulas Albayrak wrote:
>
>> so here's the situation: I've got a Slony cluster running between a
>> unix master and a linux slave. These are running Slony version 1.2.21.
>> Now I want to add a second slave on a Windows machine as well, but
>> from looking on the official Slony web page I can see there're no Win
>> binary installers for version 1.2.21. What should I do? Do I have to
>> change to another Slony version on the machines already in the Slony
>> cluster?
>
> The easiest way to get Slony for Windows is probably via the StackBuilder
> application which comes with the One-Click installer for Windows, built by
> EnterpriseDB.
>
> Ray.
>
> --
> Raymond O'Donnell :: Galway :: Ireland
> rod@...
>

--
Ulas Albayrak
ulas.albayrak@...

Re: setting up replicating system between OS's

> The easiest way to get Slony for Windows is probably via the 
> StackBuilder application which comes with the One-Click installer for 
> Windows, built by EnterpriseDB.

That won't solve the version mismatch problem though.

--

-- 
Greg Sabino Mullane greg@...
End Point Corporation
PGP Key: 0x14964AC8

_______________________________________________
Slony1-general mailing list
Slony1-general@...
http://lists.slony.info/mailman/listinfo/slony1-general