Fri Jun 1 07:40:00 PDT 2007
- Previous message: [Slony1-general] how can i clean sl_events?
- Next message: [Slony1-general] BUG or NOT in 1.2.9 ?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On 6/1/2007 3:03 AM, open wrote: > I see this in the master's slony log > > stalingrad.xxx.xx = Node 6, it is a this truble node.... My guess on this one would be that your DNS or hosts table on the master returns the wrong IP address for stalingrad.xxx.xx and therefore the slon daemon on the master tries to connect actually to node 2 instead of 6. Jan > > Jun 1 10:23:28 vps137 slon_mmedia[7509]: [662-1] DEBUG4 version for > "host=stalingrad.xxx.xx dbname=multimedia user=postgres port=5432 > password=XXXX" is 80012 > Jun 1 10:23:28 vps137 slon_mmedia[7509]: [663-1] ERROR > remoteListenThread_6: db_getLocalNodeId() returned 2 - wrong database? > Jun 1 10:23:34 vps137 slon_mmedia[7509]: [664-1] DEBUG2 > remoteListenThread_2: queue event 2,133595 SYNC > Jun 1 10:23:34 vps137 slon_mmedia[7509]: [665-1] DEBUG2 > remoteListenThread_2: UNLISTEN > Jun 1 10:23:34 vps137 slon_mmedia[7509]: [666-1] DEBUG2 > remoteWorkerThread_2: Received event 2,133595 SYNC > Jun 1 10:23:34 vps137 slon_mmedia[7509]: [667-1] DEBUG3 calc sync size > - last time: 1 last length: 9861 ideal: 20 proposed size: 3 > Jun 1 10:23:34 vps137 slon_mmedia[7509]: [668-1] DEBUG2 > remoteWorkerThread_2: SYNC 133595 processing > Jun 1 10:23:34 vps137 slon_mmedia[7509]: [669-1] DEBUG2 > remoteWorkerThread_2: no sets need syncing for this event > Jun 1 10:23:34 vps137 slon_mmedia[7509]: [670-1] DEBUG2 > remoteWorkerThread_2: forward confirm 1,128662 received by 3 > Jun 1 10:23:34 vps137 slon_mmedia[7509]: [671-1] DEBUG2 > remoteWorkerThread_2: forward confirm 3,134976 received by 5 > Jun 1 10:23:34 vps137 slon_mmedia[7509]: [672-1] DEBUG2 > remoteListenThread_3: LISTEN > Jun 1 10:23:34 vps137 slon_mmedia[7509]: [673-1] DEBUG2 > remoteWorkerThread_3: forward confirm 2,133595 received by 3 > Jun 1 10:23:38 vps137 slon_mmedia[7509]: [674-1] DEBUG4 version for > "host=stalingrad.xxx.xx dbname=multimedia user=postgres port=5432 > password=XXXX" is 80012 > Jun 1 10:23:38 vps137 slon_mmedia[7509]: [675-1] ERROR > remoteListenThread_6: db_getLocalNodeId() returned 2 - wrong database? > Jun 1 10:23:40 vps137 slon_mmedia[7509]: [676-1] DEBUG2 > remoteListenThread_4: queue event 4,133189 SYNC > Jun 1 10:23:40 vps137 slon_mmedia[7509]: [677-1] DEBUG2 > remoteWorkerThread_4: Received event 4,133189 SYNC > > I'm google' ing "getLocalNodeId() returned 2 - wrong database" and see > to the > src/backend/slony1_funcs.c and src/slon/remote_listen.c > but i don't know WHY and WHAT does it mean "ERROR remoteListenThread_6: > db_getLocalNodeId() returned 2 - wrong database?" > > > > > > Jan Wieck wrote: >> On 5/31/2007 9:44 AM, open wrote: >>>> Check the output of the sl_status view over a couple of minutes. If >>>> the column st_last_event for any of your subscribers is not >>>> advancing, the event confirmations from that node still don't make >>>> it back to the origin and your engineer has more to fix. >>> .....bad news, sl_status looks nornally.... >>> st_last_event increases normally.... >>> have you any ideas ? >> >> Ooops ... my fault ... I meant the column st_received. As it looks to >> me, node 6 is either not replicating, or the confirmations don't make >> it back to the origin. The origin thinks it is stuck on event 69838. >> >> >> Jan >> >> >>> >>> WBR, open. >>> >>> [root at vps135 ~]# psql multimedia postgres -c "select * from >>> _multimedia.sl_status" >>> st_origin | st_received | st_last_event | st_last_event_ts >>> | st_last_received | st_last_received_ts | >>> st_last_received_event_ts | st_lag_num_events | >>> st_lag_time >>> -----------+-------------+---------------+----------------------------+------------------+----------------------------+----------------------------+-------------------+------------------------ >>> >>> 1 | 2 | 125597 | 2007-05-31 17:34:11.315586 >>> | 125596 | 2007-05-31 17:34:00.400391 | 2007-05-31 >>> 17:33:51.299999 | 1 | 00:00:39.454171 >>> 1 | 3 | 125597 | 2007-05-31 17:34:11.315586 >>> | 125597 | 2007-05-31 17:34:12.837879 | 2007-05-31 >>> 17:34:11.315586 | 0 | 00:00:19.438584 >>> 1 | 6 | 125597 | 2007-05-31 17:34:11.315586 >>> | 69838 | 2007-05-24 09:29:13.589914 | 2007-05-24 >>> 09:29:12.580015 | 55759 | 7 days 08:05:18.174155 >>> 1 | 4 | 125597 | 2007-05-31 17:34:11.315586 >>> | 125597 | 2007-05-31 18:23:10.653676 | 2007-05-31 >>> 17:34:11.315586 | 0 | 00:00:19.438584 >>> 1 | 5 | 125597 | 2007-05-31 17:34:11.315586 >>> | 125597 | 2007-05-31 17:33:29.585481 | 2007-05-31 >>> 17:34:11.315586 | 0 | 00:00:19.438584 >>> (5 rows) >>> >>> [root at vps135 ~]# psql multimedia postgres -c "select * from >>> _multimedia.sl_status" >>> st_origin | st_received | st_last_event | st_last_event_ts >>> | st_last_received | st_last_received_ts | >>> st_last_received_event_ts | st_lag_num_events | >>> st_lag_time >>> -----------+-------------+---------------+----------------------------+------------------+----------------------------+----------------------------+-------------------+---------------------------- >>> >>> 1 | 2 | 125598 | 2007-05-31 17:34:31.419948 >>> | 125597 | 2007-05-31 17:34:21.424266 | 2007-05-31 >>> 17:34:11.315586 | 1 | 00:00:28.263841 >>> 1 | 3 | 125598 | 2007-05-31 17:34:31.419948 >>> | 125597 | 2007-05-31 17:34:12.837879 | 2007-05-31 >>> 17:34:11.315586 | 1 | 00:00:28.263841 >>> 1 | 6 | 125598 | 2007-05-31 17:34:31.419948 >>> | 69838 | 2007-05-24 09:29:13.589914 | 2007-05-24 >>> 09:29:12.580015 | 55760 | 7 days 08:05:26.9994119999 >>> 1 | 4 | 125598 | 2007-05-31 17:34:31.419948 >>> | 125598 | 2007-05-31 18:23:31.422288 | 2007-05-31 >>> 17:34:31.419948 | 0 | 00:00:08.159479 >>> 1 | 5 | 125598 | 2007-05-31 17:34:31.419948 >>> | 125597 | 2007-05-31 17:33:29.585481 | 2007-05-31 >>> 17:34:11.315586 | 1 | 00:00:28.263841 >>> (5 rows) >>> >>> [root at vps135 ~]# psql multimedia postgres -c "select * from >>> _multimedia.sl_status" >>> st_origin | st_received | st_last_event | st_last_event_ts >>> | st_last_received | st_last_received_ts | >>> st_last_received_event_ts | st_lag_num_events | >>> st_lag_time >>> -----------+-------------+---------------+----------------------------+------------------+----------------------------+----------------------------+-------------------+------------------------ >>> >>> 1 | 2 | 125618 | 2007-05-31 17:41:12.190197 >>> | 125617 | 2007-05-31 17:41:01.543596 | 2007-05-31 >>> 17:40:52.162198 | 1 | 00:00:31.501594 >>> 1 | 3 | 125618 | 2007-05-31 17:41:12.190197 >>> | 125618 | 2007-05-31 17:41:04.928925 | 2007-05-31 >>> 17:41:12.190197 | 0 | 00:00:11.473595 >>> 1 | 6 | 125618 | 2007-05-31 17:41:12.190197 >>> | 69838 | 2007-05-24 09:29:13.589914 | 2007-05-24 >>> 09:29:12.580015 | 55780 | 7 days 08:12:11.083777 >>> 1 | 4 | 125618 | 2007-05-31 17:41:12.190197 >>> | 125618 | 2007-05-31 18:30:16.192276 | 2007-05-31 >>> 17:41:12.190197 | 0 | 00:00:11.473595 >>> 1 | 5 | 125618 | 2007-05-31 17:41:12.190197 >>> | 125618 | 2007-05-31 17:40:31.441314 | 2007-05-31 >>> 17:41:12.190197 | 0 | 00:00:11.473595 >>> (5 rows) >>> >>> >>> _______________________________________________ >>> Slony1-general mailing list >>> Slony1-general at lists.slony.info >>> http://lists.slony.info/mailman/listinfo/slony1-general >> >> > > _______________________________________________ > Slony1-general mailing list > Slony1-general at lists.slony.info > http://lists.slony.info/mailman/listinfo/slony1-general -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== JanWieck at Yahoo.com #
- Previous message: [Slony1-general] how can i clean sl_events?
- Next message: [Slony1-general] BUG or NOT in 1.2.9 ?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Slony1-general mailing list