Ok, i will create an issue.
I got round it changing this
> : rsync -Wa${verbose}${compress} --delete ${sizeonly} \
> : ${stats} rsync://${master_host}:${rsyncd_port}/solr/${name}/
> : ${data_dir}/${name}-wip
for
> : rsync -Wa${verbose}${compress} --delete ${sizeonly} \
> : ${stats} ${master_host}:${master_data_dir}/${name}/
> : ${data_dir}/${name}-wip
I had to remove the rsync:// as it was causing some problems finding the
path and I didn't have much time to investigate. It works with absolute
or relative paths set in the slave's master data folder param.
Why does it need to start an rsyncd in the master in a different port
for each ap, is it not enough to call rsync on master:path?
Thanks for answering,
Galo
Chris Hostetter wrote:
: and I'm finding the same issues as
: https://issues.apache.org/jira/browse/SOLR-188 in the snappuller, I
: haven't looked in other scripts yet.
:
: rsync -Wa${verbose}${compress} --delete ${sizeonly} \
: ${stats} rsync://${master_host}:${rsyncd_port}/solr/${name}/
: ${data_dir}/${name}-wip
that would be a seperate issue from SOLR-188 ... 188 has to do with non
standard URLs, this seems to be an issue with snappuller assuming a
specific rsync path (which if i understand correctly, is relative the
working directory of rsyncd?)
: Is this known or should I log it in JIRA?
please open a new Jira issue ... i'm guessing a new optional param will be
needed for the master's solr_home relative the rsync server.
-Hoss
