[
https://issues.apache.org/jira/browse/SOLR-433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12620430#action_12620430
]
jonjlee edited comment on SOLR-433 at 8/7/08 9:01 AM:
-----------------------------------------------------------
I'm interested in using this patch to replicate the spell index, but I am not
using multiple cores. The scripts in the patch do not work for single core
setups since it makes an assumptions that the core name will appear in the
rsync path.
I am attaching another version of the patch which makes a few changes:
* snapcleaner, snapshooter, and snappuller are backwards compatible with the
naming convention used by the current scripts
* Fixed a few small bugs where static strings were used instead of the
corresponding variables
* Avoid assuming that an executable will accept a '-c' parameter to specify the
core name. Instead, allow a RunExecutableListener to be conditionally executed
for specified cores. RunExecutableListener now accepts a <arr name="cores">
parameter. You would need to add a listener for each core. For example:
{code}
<listener event="postOptimize" class="core.RunExecutableListener">
<arr name="cores"> <str>core0</str> </arr>
<str name="exe">solr/bin/snapshooter</str>
<str name="dir">.</str>
<arr name="args"> <str>-d /usr/local/solr/core0/data</str> </arr>
</listener>
<listener event="postOptimize" class="core.RunExecutableListener">
<arr name="cores"> <str>core1</str> </arr>
<str name="exe">solr/bin/snapshooter</str>
<str name="dir">.</str>
<arr name="args"> <str>-d /usr/local/solr/core1/data</str> </arr>
</listener>
{code}
(Another reasonable alternative to this might also be to accept variables like
${SOLR_CORE} in <args> and <env> which are resolved by RunExecutableListener.)
* Removed the '-c' parameter from snappuller, replacing it instead with the
'-r' option to specify an rsync module. This allows us to not assume the
location of the core's data path. Instead we would add a new module to
rsyncd.conf for each core. e.g.
{code}
...
[core0]
path = /usr/local/solr/core0/data
comment = core0
[core1]
path = /usr/local/solr/core1/data
comment = core1
...
{code}
then use:
{code}
./snappuller -r core0
{code}
was (Author: jonjlee):
I'm interested in getting using this patch to replicate the spell index,
but I am not using multiple cores. However, the scripts in the patch do not
work for single core setups since the assume that ${core} contains a valid
value. Even specifying -c "" will not work, since the variable is used in
paths.
> MultiCore and SpellChecker replication
> --------------------------------------
>
> Key: SOLR-433
> URL: https://issues.apache.org/jira/browse/SOLR-433
> Project: Solr
> Issue Type: Improvement
> Components: replication, spellchecker
> Affects Versions: 1.3
> Reporter: Otis Gospodnetic
> Attachments: RunExecutableListener.patch, solr-433.patch,
> SOLR-433_unified.patch, spellindexfix.patch
>
>
> With MultiCore functionality coming along, it looks like we'll need to be
> able to:
> A) snapshot each core's index directory, and
> B) replicate any and all cores' complete data directories, not just their
> index directories.
> Pulled from the "spellchecker and multi-core index replication" thread -
> http://markmail.org/message/pj2rjzegifd6zm7m
> Otis:
> I think that makes sense - distribute everything for a given core, not just
> its index. And the spellchecker could then also have its data dir (and only
> index/ underneath really) and be replicated in the same fashion.
> Right?
> Ryan:
> Yes, that was my thought. If an arbitrary directory could be distributed,
> then you could have
> /path/to/dist/index/...
> /path/to/dist/spelling-index/...
> /path/to/dist/foo
> and that would all get put into a snapshot. This would also let you put
> multiple cores within a single distribution:
> /path/to/dist/core0/index/...
> /path/to/dist/core0/spelling-index/...
> /path/to/dist/core0/foo
> /path/to/dist/core1/index/...
> /path/to/dist/core1/spelling-index/...
> /path/to/dist/core1/foo
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
