In my previous post, I submitted the shell script I was calling w/ 
command_on_logarchive.  Does anyone have any idea why it wouldn't would 
run in some cases?  In my test it only seemed to call the script when a 
sync archive came from a node that is an origin for a set...


JP Fletcher wrote:
> Christopher Browne wrote:
>> JP Fletcher <jpfletch at ca.afilias.info> writes:
>>  
>>> I'm experimenting with logshipping (v.1.2.11) and am using, for the
>>> first time, the option in the slon conf file:
>>>
>>> command_on_logarchive
>>>
>>> I created a shell script that this command calls which applies syncs
>>> archives after they are written:
>>>
>>>   
>>> command_on_logarchive="/opt/clusters/cluster1_slony/archive/apply_archive.sh" 
>>>
>>>
>>> My cluster has four nodes, not counting the log shipped replica, 8141,
>>> 8142, 8143, and 8194.  Node 8194 is the provider to the logshipped
>>> node, so I only configured 'command_on_logarchive' for the slon
>>> servicing this node, my assumption is that this is correct.  Nodes
>>> 8143, and 8141 are origins for sets.
>>>
>>> When I started things up, everything appeared to be fine.  The slon
>>> successfully applied 37 archives, each originating on either node 8141
>>> or 8143.  The 38th archive, however, and several subsequent archives
>>> originated on node 8142.  The slon made no attempt to apply these
>>> archives.  This left the archive counter  on 37.  The next archive the
>>> slon attempted to apply was from node 8143, and  expected the  archive
>>> counter to be on 48, which of course it was not, and everything went
>>> pear-shaped.   I have three questions:
>>>
>>> 1.  Should I have expected the command_on_logarchive option to work,
>>> and if so, did i do something wrong?
>>>     
>>
>> Hopefully apply_archive.sh looked something like:
>>
>> #!/bin/sh
>> PGBINDIR=????
>> ${PGBINDIR}/slony_logshipper $1
>>
>> That might be hoped to work, although not quite right yet in 1.2.11
>>   
>
> #!/bin/bash
>
> SQL_ARCHIVE=$1
>
> /opt/dbs/pgsql81_slonytest/bin/psql -h yrg-testbed2 -p 9533 -U slony 
> -f $SQL_ARCHIVE cluster1_logship >> 
> /opt/clusters/cluster1_slony/archive/apply_archive.log 2>&1
>
> if [ $? != 0 ]; then
>
>   echo "Failed to apply archive $SQL_ARCHIVE >> 
> /opt/clusters/cluster1_slony/archive/apply_archive.log 2>&1"
>   exit 1
>  fi
>
> mv $SQL_ARCHIVE $SQL_ARCHIVE.applied
>
>> :-(.
>>
>>  
>>> 2.  Why does the slon not try to apply archives from node8142?
>>>     
>>
>> slon shouldn't; I think you're meaning the slony_logshipper...
>>   
>
> Yes, of course you're correct, but it doesn't look like the shell 
> script was even run for these files.
>>  
>>> 3.  Why are there archives from a node that is not active (no events
>>> should have originated on 8142, and no archive files exist for the
>>> other non-origin node)?
>>>     
>>
>> The node that isn't active should have very few, very infrequent,
>> archives that are devoid of actual content (beyond the headers).
>>
>> It is expected that there *will* be some events coming from other
>> nodes, as every node does generate events, even if infrequently.
>>
>> The behaviour will change a bit in 1.2.12; Jan just committed some
>> changes at the end of last week to fix up the handling of sequencing
>> of the archives, which turned out to be (sigh) troublesome.
>>   
>
>


-- 
JP Fletcher
Database Administrator
Afilias Canada
voice: 416.646.3304 ext. 4123
fax: 416.646.3305
mobile: 416.561.4763
jpfletch at ca.afilias.info