Tue Jan 18 06:20:38 PST 2011
- Previous message: [Slony1-general] sl_status not updated, despite replication working (slony 2.0.6)
- Next message: [Slony1-general] sl_status not updated, despite replication working (slony 2.0.6)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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). > >
- Previous message: [Slony1-general] sl_status not updated, despite replication working (slony 2.0.6)
- Next message: [Slony1-general] sl_status not updated, despite replication working (slony 2.0.6)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Slony1-general mailing list