Steve Singer ssinger at ca.afilias.info
Tue Jan 18 06:20:38 PST 2011
On 11-01-18 08:22 AM, Guillaume Lelarge wrote:
> On Tue, 18 Jan 2011 08:04:18 -0500, Steve Singer<ssinger at ca.afilias.info>
> wrote:
>> On 11-01-18 05:08 AM, Guillaume Lelarge wrote:
>>> Hi,
>>>
>>> I have an issue on Slony 2.0.6 and PostgreSQL 9.0.2. After stopping a
>>> slave, waiting for a few minutes, and then starting the slave again,
> the
>>> sl_status view shows a lag that keeps going up. And even if the lag
> keeps
>>> going up, replication is working on all slaves. The only way to fix
> this
>>> is
>>> to restart the slon daemons.
>>>
>>> Is this behaviour expected? AFAICT, it isn't. At least, it doesn't seem
>>> so
>>> to Peter Geoghegan that asked many times about this issue (see
> "sl_status
>>> incorrectly reports long event lag", "Error - table id 1 has already
> been
>>> assigned", "Problem with Slony-I 2.0.2, sl_status persists", "Why does
>>> sl_status event lag grow, even though events *are* replicated?", "slony
> I
>>> 2.0.3" threads). The usual answer was to stick with the 1.2 branch, but
>>> it
>>> seemed to me that 2.0.6 got rid of many bugs.
>>>
>>> So, is it a bug of the 2.0 branch? or is it an expected behaviour? Any
>>> tips would be great.
>>
>>
>> Are SYNC events being generated on that slave? (examin sl_event on the
>> slave with ev_origin=$slave_id)
>>
>
> Yes, every 10 seconds.
>
>> Are the confirms for those events confirming they have been processed by
>
>> the master making it back to the slave (look at sl_confirm on the slave)
>>
>
> No, the oldest one is around the same time when I stopped the slave.
>

Are the SYNC's from node to making it to your origin?  (do they show up 
in sl_event on the origin).  If yes, do the confirms for those events 
show up in sl_confirm on the origin.  Or in other words are the sync's 
from node 2 making it to the origin?



> FYI, I tried 2.1dev, which, to my happy surprise, use the application_name
> variable. I have the same behaviour but I noticed that one connection is
> not renewed when the slave is up again. It is "slon.node_2_listen" (node 2
> is my slave).
>
>



More information about the Slony1-general mailing list