[
https://issues.apache.org/jira/browse/SOLR-830?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12647345#action_12647345
]
Steven Rowe commented on SOLR-830:
----------------------------------
Bill, I ran the following script on a Linux box against a remote Solaris 2.8
box, with Perl 5.8.0 installed, on which I created the set of empty directories
you listed:
{code}
master_host=remotesolaris
master_data_dir=/tmp/solrtest
snap_name=`ssh -o StrictHostKeyChecking=no ${master_host} \
"perl -e 'chdir q|${master_data_dir}|; print ((sort grep
{/^snapshot[.][1-9][0-9]{13}$/} <*>)[-1])'"`
echo ${snap_name}
{code}
N.B.: I had to change the quoting boundary character around ${master_data_dir},
from '/' to '|', since ${master_data_dir} contains '/' characters -- I think
'|' is really unlikely to be a pathname component.
It worked for me both with and without the '\' before the '$' -- I get the
following output from the script:
snapshot.20081113113700
> snappuller picks bad snapshot name
> ----------------------------------
>
> Key: SOLR-830
> URL: https://issues.apache.org/jira/browse/SOLR-830
> Project: Solr
> Issue Type: Bug
> Components: replication (scripts)
> Affects Versions: 1.2, 1.3
> Reporter: Hoss Man
> Assignee: Bill Au
> Fix For: 1.3.1
>
>
> as mentioned on the mailing list...
> http://www.nabble.com/FileNotFoundException-on-slave-after-replication---script-bug--to20111313.html#a20111313
> {noformat}
> We're seeing strange behavior on one of our slave nodes after replication.
> When the new searcher is created we see FileNotFoundExceptions in the log
> and the index is strangely invalid/corrupted.
> We may have identified the root cause but wanted to run it by the community.
> We figure there is a bug in the snappuller shell script, line 181:
> snap_name=`ssh -o StrictHostKeyChecking=no ${master_host} "ls
> ${master_data_dir}|grep 'snapshot\.'|grep -v wip|sort -r|head -1"`
> This line determines the directory name of the latest snapshot to download
> to the slave from the master. Problem with this line is that it grab the
> temporary work directory of a snapshot in progress. Those temporary
> directories are prefixed with "temp" and as far as I can tell should never
> get pulled from the master so its easy to disambiguate. It seems that this
> temp directory, if it exists will be the newest one so if present it will be
> the one replicated: FAIL.
> {noformat}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
