blob: 743814405fa176b05bd4a3a8212a4f9293d09786 [file] [log] [blame]
= SolrCloud with Legacy Configuration Files
// Licensed to the Apache Software Foundation (ASF) under one
// or more contributor license agreements. See the NOTICE file
// distributed with this work for additional information
// regarding copyright ownership. The ASF licenses this file
// to you under the Apache License, Version 2.0 (the
// "License"); you may not use this file except in compliance
// with the License. You may obtain a copy of the License at
//
// http://www.apache.org/licenses/LICENSE-2.0
//
// Unless required by applicable law or agreed to in writing,
// software distributed under the License is distributed on an
// "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
// KIND, either express or implied. See the License for the
// specific language governing permissions and limitations
// under the License.
If you are migrating from a non-SolrCloud environment to SolrCloud, this information may be helpful.
All of the required configuration is already set up in the sample configurations shipped with Solr. You only need to add the following if you are migrating old configuration files. Do not remove these files and parameters from a new Solr instance if you intend to use Solr in SolrCloud mode.
These properties exist in 3 files: `schema.xml`, `solrconfig.xml`, and `solr.xml`.
. In `schema.xml`, you must have a `\_version_` field defined:
+
[source,xml]
----
<field name="_version_" type="long" indexed="true" stored="true" multiValued="false"/>
----
+
. In `solrconfig.xml`, you must have an `UpdateLog` defined. This should be defined in the `updateHandler` section.
+
[source,xml]
----
<updateHandler>
...
<updateLog>
<str name="dir">${solr.data.dir:}</str>
</updateLog>
...
</updateHandler>
----
+
. The DistributedUpdateProcessor is part of the default update chain and is automatically injected into any of your custom update chains, so you don't actually need to make any changes for this capability. However, should you wish to add it explicitly, you can still add it to the `solrconfig.xml` file as part of an `updateRequestProcessorChain`. For example:
+
[source,xml]
----
<updateRequestProcessorChain name="sample">
<processor class="solr.LogUpdateProcessorFactory" />
<processor class="solr.DistributedUpdateProcessorFactory"/>
<processor class="my.package.UpdateFactory"/>
<processor class="solr.RunUpdateProcessorFactory" />
</updateRequestProcessorChain>
----
+
If you do not want the DistributedUpdateProcessFactory auto-injected into your chain (for example, if you want to use SolrCloud functionality, but you want to distribute updates yourself) then specify the `NoOpDistributingUpdateProcessorFactory` update processor factory in your chain:
+
[source,xml]
----
<updateRequestProcessorChain name="sample">
<processor class="solr.LogUpdateProcessorFactory" />
<processor class="solr.NoOpDistributingUpdateProcessorFactory"/>
<processor class="my.package.MyDistributedUpdateFactory"/>
<processor class="solr.RunUpdateProcessorFactory" />
</updateRequestProcessorChain>
----
+
In the update process, Solr skips updating processors that have already been run on other nodes.
+
For more on the default update request processor chain and options, see
the section <<update-request-processors.adoc#default-update-request-processor-chain,Default Update Request Processor Chain>>.