The following notes describe changes to Solr in recent releases that you should be aware of before upgrading.
These notes highlight the biggest changes that may impact the largest number of implementations. It is not a comprehensive list of all changes to Solr in any release.
When planning your Solr upgrade, consider the customizations you have made to your system and review the CHANGES.txt
file found in your Solr package. That file includes all the changes and updates that may effect your existing implementation.
Detailed steps for upgrading a Solr cluster are in the section Upgrading a Solr Cluster.
Upgrading to 7.x Releases
Solr 7.3
See the 7.3 Release Notes for an overview of the main new features in Solr 7.3.
When upgrading to Solr 7.3, users should be aware of the following major changes from v7.2:
-
Collections created without specifying a configset name have used a copy of the
_default
configset since Solr 7.0. Before 7.3, the copied configset was named the same as the collection name, but from 7.3 onwards it will be named with a new ".AUTOCREATED" suffix. This is to prevent overwriting custom configset names. -
The
rq
parameter used with Learning to Rank rerank query parsing no longer considers thedefType
parameter. See Running a Rerank Query for more information about this parameter. -
The default value of
autoReplicaFailoverWaitAfterExpiration
, used with the AutoAddReplicas feature, has increased to 120 seconds from the previous default of 30 seconds. This affects how soon Solr adds new replicas to replace the replicas on nodes which have either crashed or shutdown. -
The default Solr log file size and number of backups have been raised to 32MB and 10 respectively. See the section Configuring Logging for more information about how to configure logging.
-
The old Leader-In-Recovery implementation (implemented in Solr 4.9) is now deprecated and replaced. Solr will support rolling upgrades from old 7.x versions of Solr to future 7.x releases until the last release of the 7.x major version.
This means to upgrade to Solr 8 in the future, you will need to be on Solr 7.3 or higher.
-
Replicas which are not up-to-date are no longer allowed to become leader. Use the FORCELEADER command of the Collections API to allow these replicas become leader.
-
The behaviour of the autoscaling system will now pause all triggers from execution between the start of actions and the end of a cool down period. The triggers will resume after the cool down period expires. Previously, the cool down period was a fixed period started after actions for a trigger event completed and during this time all triggers continued to run but any events were rejected and tried later.
-
The throttling mechanism used to limit the rate of autoscaling events processed has been removed. This deprecates the
actionThrottlePeriodSeconds
setting in theset-properties
Autoscaling API which is now non-operational. Use thetriggerCooldownPeriodSeconds
parameter instead to pause event processing. -
If you are using the spatial JTS library with Solr, you must upgrade to 1.15.0. This new version of JTS is now dual-licensed to include a BSD style license. See the section on Spatial Search for more information.
-
The top-level
<highlighting>
element insolrconfig.xml
is now officially deprecated in favour of the equivalent<searchComponent>
syntax. This element has been out of use in default Solr installations for several releases already.
Solr 7.2
See the 7.2 Release Notes for an overview of the main new features in Solr 7.2.
When upgrading to Solr 7.2, users should be aware of the following major changes from v7.1:
-
Starting a query string with local parameters
{!myparser …}
is used to switch from one query parser to another, and is intended for use by Solr system developers, not end users doing searches. To reduce negative side-effects of unintended hack-ability, Solr now limits the cases when local parameters will be parsed to only contexts in which the default parser is "lucene" or "func".So, if
defType=edismax
thenq={!myparser …}
won’t work. In that example, put the desired query parser into thedefType
parameter.Another example is if
deftype=edismax
thenhl.q={!myparser …}
won’t work for the same reason. In this example, either put the desired query parser into thehl.qparser
parameter or sethl.qparser=lucene
. Most users won’t run into these cases but some will need to change.If you must have full backwards compatibility, use
luceneMatchVersion=7.1.0
or an earlier version. -
The eDisMax parser by default no longer allows subqueries that specify a Solr parser using either local parameters, or the older
_query_
magic field trick.For example,
{!prefix f=myfield v=enterp}
or_query_:"{!prefix f=myfield v=enterp}"
are not supported by default any longer. If you want to allow power-users to do this, setuf=* query
or some other value that includes_query_
.If you need full backwards compatibility for the time being, use
luceneMatchVersion=7.1.0
or something earlier.
Solr 7.1
See the 7.1 Release Notes for an overview of the main new features of Solr 7.1.
When upgrading to Solr 7.1, users should be aware of the following major changes from v7.0:
-
The feature to automatically add replicas if a replica goes down, previously available only when storing indexes in HDFS, has been ported to the autoscaling framework. Due to this,
autoAddReplicas
is now available to all users even if their indexes are on local disks.Existing users of this feature should not have to change anything. However, they should note these changes:
-
Behavior: Changing the
autoAddReplicas
property from disabled (false
) to enabled (true
) using MODIFYCOLLECTION API no longer replaces down replicas for the collection immediately. Instead, replicas are only added if a node containing them went down whileautoAddReplicas
was enabled. The parametersautoReplicaFailoverBadNodeExpiration
andautoReplicaFailoverWorkLoopDelay
are no longer used. -
Deprecations: Enabling/disabling autoAddReplicas cluster-wide with the API will be deprecated; use suspend/resume trigger APIs with
name=".auto_add_replicas"
instead.More information about the changes to this feature can be found in the section SolrCloud Automatically Adding Replicas.
-
-
Shard and cluster metric reporter configuration now require a class attribute.
-
If a reporter configures the
group="shard"
attribute then please also configure theclass="org.apache.solr.metrics.reporters.solr.SolrShardReporter"
attribute. -
If a reporter configures the
group="cluster"
attribute then please also configure theclass="org.apache.solr.metrics.reporters.solr.SolrClusterReporter"
attribute.See the section Shard and Cluster Reporters for more information.
-
-
All Stream Evaluators in
solrj.io.eval
have been refactored to have a simpler and more robust structure. This simplifies and condenses the code required to implement a new Evaluator and makes it much easier for evaluators to handle differing data types (primitives, objects, arrays, lists, and so forth). -
In the ReplicationHandler, the
master.commitReserveDuration
sub-element is deprecated. Instead please configure a directcommitReserveDuration
element for use in all modes (master, slave, cloud). -
The
RunExecutableListener
was removed for security reasons. If you want to listen to events caused by updates, commits, or optimize, write your own listener as native Java class as part of a Solr plugin. -
In the XML query parser (
defType=xmlparser
or{!xmlparser … }
) the resolving of external entities is now disallowed by default.
Upgrading to 7.x from Any 6.x Release
The upgrade from Solr 6.x to Solr 7.0 introduces several major changes that you should be aware of before upgrading. Please do a thorough review of the section Major Changes in Solr 7 before starting your upgrade.
Upgrading to 7.x from pre-6.x Versions of Solr
Users upgrading from versions of Solr prior to 6.x are strongly encouraged to consult CHANGES.txt
for the details of all changes since the version they are upgrading from.
A summary of the significant changes between Solr 5.x and Solr 6.0 is in the section Major Changes from Solr 5 to Solr 6.
We welcome feedback on Solr documentation. However, we cannot provide application support via comments. If you need help, please send a message to the Solr User mailing list.