From 6d23ee96a99932bedaf658ddd61fd58875656cd4 Mon Sep 17 00:00:00 2001 From: Cassandra Targett Date: Tue, 12 Dec 2017 15:06:59 -0600 Subject: [PATCH] SOLR-11753: add upgrade notes; misc cleanups in other pages --- solr/solr-ref-guide/src/collections-api.adoc | 10 +++-- .../src/solr-upgrade-notes.adoc | 35 ++++++++++++--- .../src/solrcloud-autoscaling-api.adoc | 44 ++++++++++++++----- 3 files changed, 69 insertions(+), 20 deletions(-) diff --git a/solr/solr-ref-guide/src/collections-api.adoc b/solr/solr-ref-guide/src/collections-api.adoc index 784e2cf73f6..23a26a1f5d6 100644 --- a/solr/solr-ref-guide/src/collections-api.adoc +++ b/solr/solr-ref-guide/src/collections-api.adoc @@ -1885,6 +1885,7 @@ Time in seconds to wait until new replicas are created, and until leader replica ==== This operation does not hold necessary locks on the replicas that belong to on the source node. So don't perform other collection operations in this period. ==== + [[movereplica]] == MOVEREPLICA: Move a Replica to a New Node @@ -1913,14 +1914,17 @@ The name of the destination node. This parameter is required. Request ID to track this action which will be <>. [[utilizenode]] -== UTILIZENODE: Utilize a new node +== UTILIZENODE: Utilize a New Node -This command can be used to move some replicas from the existing nodes to a new node or lightly loaded node and reduce the load on them. This uses your autoscaling policies and preferences to identify which replica needs to be moved. It tries to fix any policy violations first and then it tries to move some load off of the most loaded nodes according to the preferences. +This command can be used to move some replicas from the existing nodes to either a new node or a less loaded node to reduce the load on the existing node. + +This uses your autoscaling policies and preferences to identify which replica needs to be moved. It tries to fix any policy violations first and then it tries to move some load off of the most loaded nodes according to the preferences. `/admin/collections?action=UTILIZENODE&node=nodeName` + === UTILIZENODE Parameters -`node`:: The name of the node that needs to be utilized. This parameter is required +`node`:: The name of the node that needs to be utilized. This parameter is required. == Asynchronous Calls diff --git a/solr/solr-ref-guide/src/solr-upgrade-notes.adoc b/solr/solr-ref-guide/src/solr-upgrade-notes.adoc index 30d27bf13e9..05f7ee2e90e 100644 --- a/solr/solr-ref-guide/src/solr-upgrade-notes.adoc +++ b/solr/solr-ref-guide/src/solr-upgrade-notes.adoc @@ -25,7 +25,32 @@ When planning your Solr upgrade, consider the customizations you have made to yo Detailed steps for upgrading a Solr cluster can be found in the section <>. -== Upgrading from Solr 7.0 +== Upgrading from 7.x Releases + +=== Solr 7.2 + +See the https://wiki.apache.org/solr/ReleaseNote72[7.2 Release Notes] for an overview of the main new features in Solr 7.2. + +Users should be aware of the following major changes from v7.1: + +* Starting a query string with <> `{!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 "<>" or "<>". ++ +So, if `defType=edismax` then `q={!myparser ...}` won't work. In that example, put the desired query parser into the `defType` parameter. ++ +Another example is if `deftype=edismax` then `hl.q={!myparser ...}` won't work for the same reason. In this example, either put the desired query parser into the `hl.qparser` parameter or set `hl.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, set `uf=*,\_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 https://wiki.apache.org/solr/ReleaseNote71[7.1 Release Notes] for an overview of the main new features of 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. @@ -39,7 +64,7 @@ More information about the changes to this feature can be found in the section < * Shard and cluster metric reporter configuration now require a class attribute. ** If a reporter configures the `group="shard"` attribute then please also configure the `class="org.apache.solr.metrics.reporters.solr.SolrShardReporter"` attribute. -** If a reporter configures the `group="cluster"` attribute then please also configure the `class="org.apache.solr.metrics.reporters.solr.SolrClusterReporter"` attribute. +** If a reporter configures the `group="cluster"` attribute then please also configure the `class="org.apache.solr.metrics.reporters.solr.SolrClusterReporter"` attribute. + See the section <> for more information. @@ -48,12 +73,12 @@ See the section <> before starting your upgrade. -== Upgrading from Older Versions of Solr +== Upgrading from pre-6.x Versions of Solr Users upgrading from versions of Solr prior to 6.x are strongly encouraged to consult {solr-javadocs}/changes/Changes.html[`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 can be found in the <> section. +A summary of the significant changes between Solr 5.x and Solr 6.0 can be found in the section <>. diff --git a/solr/solr-ref-guide/src/solrcloud-autoscaling-api.adoc b/solr/solr-ref-guide/src/solrcloud-autoscaling-api.adoc index 9d535520cb3..5dd04ed7550 100644 --- a/solr/solr-ref-guide/src/solrcloud-autoscaling-api.adoc +++ b/solr/solr-ref-guide/src/solrcloud-autoscaling-api.adoc @@ -142,10 +142,13 @@ However, since the first node in the first example had more than 1 replica for a In the above example the node with port 8983 has two replicas for `shard1` in violation of our policy. -== Suggestions API == -Suggestions are operations recommended by the system according to the policies and preferences the user has set. Note that the suggestions are made only if there are `violations` to the policies and the collection admin operation would use the preferences to identify the target node. +== Suggestions API +Suggestions are operations recommended by the system according to the policies and preferences the user has set. + +Suggestions are made only if there are `violations` to active policies. The `operation` section of the response uses the defined preferences to identify the target node. + +The API is available at `/admin/autocaling/suggestion`. Here is an example output from a suggestion request: -The API is available at `/admin/autocaling/suggestion` [source,json] ---- { @@ -191,7 +194,7 @@ The API is available at `/admin/autocaling/suggestion` "WARNING":"This response format is experimental. It is likely to change in the future."} ---- -The operation is an actual API call that can be invoked to remedy the current violation +The suggested `operation` is an API call that can be invoked to remedy the current violation. == History API @@ -213,14 +216,31 @@ further insight into e.g., exact operations that were computed and/or executed. Specifically, the following query parameters can be used (they are turned into filter queries, so an implicit AND is applied): -* `trigger` - trigger name -* `eventType` - event type / trigger type (e.g., `nodeAdded`) -* `collection` - collection name involved in event processing -* `stage` - event processing stage -* `action` - trigger action -* `node` - node name that the event refers to -* `beforeAction` - beforeAction stage -* `afterAction` - afterAction stage +`trigger`:: +The name of the trigger. + +`eventType`:: +The event type or trigger type (e.g., `nodeAdded`). + +`collection`:: +The name of the collection involved in event processing. + +`stage`:: +An event processing stage. + +`action`:: +A trigger action. + +`node`:: +A node name that the event refers to. + +`beforeAction`:: +A `beforeAction` stage. + +`afterAction`:: +An `afterAction` stage. + +// TODO someday add an input example also .Example output [source,json]