lucene-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Erick Erickson (Confluence)" <conflue...@apache.org>
Subject [CONF] Apache Solr Reference Guide > Moving to the New solr.xml Format
Date Wed, 24 Jul 2013 01:06:00 GMT
Space: Apache Solr Reference Guide (https://cwiki.apache.org/confluence/display/solr)
Page: Moving to the New solr.xml Format (https://cwiki.apache.org/confluence/display/solr/Moving+to+the+New+solr.xml+Format)

Change Comment:
---------------------------------------------------------------------
Added example of legacy and discovery mode XML

Edited by Erick Erickson:
---------------------------------------------------------------------
Migration from old-style {{solr.xml}} to core discovery is very straightforward. First, modify
the {{solr.xml}} file from the [legacy format|Legacy solr.xml Configuration] to the [discovery
format|Format of solr.xml].

In general there is a direct analog from the legacy format to the new format _except_ there
is no {{<cores>}} element nor are there any {{<core>}} elements in discovery-based
Solr.

h2. Startup

In Solr 4.4 and on, the presence of a {{<cores>}} child element of the {{<solr>}}
element in the {{solr.xml}} file signals a legacy version of {{solr.xml}}, and cores are expected
to be defined as they have been historically. Depending on whether a {{<cores>}} element
is discovered, {{solr.xml}} is parsed as either a legacy or discovery file and errors are
thrown in the log if legacy and discovery modes are mixed in {{solr.xml}}.

h2. Moving {{<core>}} definitions.

To migrate to discovery-based {{solr.xml}}, remove all of the {{<core>}} elements and
the enclosing {{<cores>}} element from {{solr.xml}}. See the pages linked above for
examples of migrating other attributes. Then, in the instanceDir for each core create a {{core.properties}}
file. _This file can be empty if all defaults are acceptable_. In particular, the {{instanceDir}}
is assumed to be the directory in which the {{core.properties}} file is discovered. The data
directory will be in a directory called "data" directly below. If the file is completely empty,
the name of the core is assumed to be the name of the folder in which the {{core.properties}}
file was discovered.

As mentioned elsewhere, the tree structure that the cores are in is arbitrary, with the exception
that the directories containing the {{core.properties}} files must share a common root, but
that root may be many levels up the tree. Note that supporting a root for the cores that is
not a child of {{SOLR_HOME}} is supported through properties in {{solr.xml}}. However, only
_one_ root is possible, there is no provision presently for specifying multiple roots.

The only restriction on the tree structure is that cores may not be children of other cores;
enumeration stops descending _down_ the tree when the first {{core.properties}} file is discovered.
Siblings of the directory in which the {{core.properties}} file is discovered are still walked,
only stopping recursing down the sibling when a {{core.properties}} file is found.

h2. Example

Here's an example of what a legacy {{solr.xml}} file might look like and the equivalent discovery-based
{{solr.xml}} and {{core.properties}} files:
{code:xml|borderStyle=solid|borderColor=#666666}
<solr persistent="${solr.xml.persist:false}">
  <cores adminPath="/admin/cores" defaultCoreName="collection1" host="127.0.0.1" hostPort="${hostPort:8983}"
         hostContext="${hostContext:solr}" zkClientTimeout="${solr.zkclienttimeout:30000}"
shareSchema="${shareSchema:false}"
         genericCoreNodeNames="${genericCoreNodeNames:true}">
    <core name="core1" instanceDir="core1" shard="${shard:}" collection="${collection:core1}"
config="${solrconfig:solrconfig.xml}" schema="${schema:schema.xml}" coreNodeName="${coreNodeName:}"/>
    <core name="core2" instanceDir="core2" />
    <shardHandlerFactory name="shardHandlerFactory" class="HttpShardHandlerFactory">
      <int name="socketTimeout">${socketTimeout:120000}</int>
      <int name="connTimeout">${connTimeout:15000}</int>
    </shardHandlerFactory>
  </cores>
</solr>

{code}

The new-style {{solr.xml}} might look like what is below. Note that adminPath, defaultCoreName
are not supported in discovery-based solr.xml.

{code:xml|borderStyle=solid|borderColor=#666666}
<solr>
  <solrcloud>
    <str name="host">127.0.0.1</str>
    <int name="hostPort">${hostPort:8983}</int>
    <str name="hostContext">${hostContext:solr}</str>
    <int name="zkClientTimeout">${solr.zkclienttimeout:30000}</str>
    <str name="shareSchema">${shareSchema:false}</str>
    <str name="genericCoreNodeNames">${genericCoreNodeNames:true}</str>
  </solrcloud>

  <shardHandlerFactory name="shardHandlerFactory" class="HttpShardHandlerFactory">
    <int name="socketTimeout">${socketTimeout:120000}</int>
    <int name="connTimeout">${connTimeout:15000}</int>
  </shardHandlerFactory>
{code}

In each of "core1" and "core2" directories, there would be a {{core.properties}} file that
might look like these. Note that note that instanceDir is not supported, it is assumed to
be the directory in which core.properties is found.

core1:

{code:xml|borderStyle=solid|borderColor=#666666}
name=core1
shard=${shard:}
collection=${collection:core1}
config=${solrconfig:solrconfig.xml}
schema=${schema:schema.xml}
coreNodeName=${coreNodeName:}
{code}

core2:

{code:xml|borderStyle=solid|borderColor=#666666}
name=core2
{code}

In fact, the core2 {{core.properties}} file could even be empty and the name would default
to the directory in which the {{core.properties}} file was found.

{scrollbar}


Stop watching space: https://cwiki.apache.org/confluence/users/removespacenotification.action?spaceKey=solr
Change email notification preferences: https://cwiki.apache.org/confluence/users/editmyemailsettings.action


    

Mime
View raw message