|
|
@@ -13,6 +13,13 @@ latest 1.x version of Elasticsearch first, in order to upgrade your indices or
|
|
|
to delete the old indices. Elasticsearch will not start in the presence of old
|
|
|
indices.
|
|
|
|
|
|
+[float]
|
|
|
+=== Network binds to localhost only
|
|
|
+
|
|
|
+Elasticsearch now binds to the loopback interface by default (usually
|
|
|
+`127.0.0.1` or `::1`). The `network.host` setting can be specified to change
|
|
|
+this behavior.
|
|
|
+
|
|
|
[float]
|
|
|
=== Elasticsearch migration plugin
|
|
|
|
|
|
@@ -20,999 +27,32 @@ We have provided the https://github.com/elastic/elasticsearch-migration[Elastics
|
|
|
to help you detect any issues that you may have when upgrading to
|
|
|
Elasticsearch 2.0. Please install and run the plugin *before* upgrading.
|
|
|
|
|
|
-=== Mapping
|
|
|
-
|
|
|
-
|
|
|
-Remove file based default mappings #10870 (issue: #10620)
|
|
|
-Validate dynamic mappings updates on the master node. #10634 (issues: #8650, #8688)
|
|
|
-Remove the ability to have custom per-field postings and doc values formats. #9741 (issue: #8746)
|
|
|
-Remove support for new indexes using path setting in object/nested fields or index_name in any field #9570 (issue: #6677)
|
|
|
-Remove index_analyzer setting to simplify analyzer logic #9451 (issue: #9371)
|
|
|
-Remove type level default analyzers #9430 (issues: #8874, #9365)
|
|
|
-Add doc values support to boolean fields. #7961 (issues: #4678, #7851)
|
|
|
-
|
|
|
-
|
|
|
-A number of changes have been made to mappings to remove ambiguity and to
|
|
|
-ensure that conflicting mappings cannot be created.
|
|
|
-
|
|
|
-==== Conflicting field mappings
|
|
|
-
|
|
|
-Fields with the same name, in the same index, in different types, must have
|
|
|
-the same mapping, with the exception of the <<copy-to>>, <<dynamic>>,
|
|
|
-<<enabled>>, <<ignore-above>>, <<include-in-all>>, and <<properties>>
|
|
|
-parameters, which may have different settings per field.
|
|
|
-
|
|
|
-[source,js]
|
|
|
----------------
|
|
|
-PUT my_index
|
|
|
-{
|
|
|
- "mappings": {
|
|
|
- "type_one": {
|
|
|
- "properties": {
|
|
|
- "name": { <1>
|
|
|
- "type": "string"
|
|
|
- }
|
|
|
- }
|
|
|
- },
|
|
|
- "type_two": {
|
|
|
- "properties": {
|
|
|
- "name": { <1>
|
|
|
- "type": "string",
|
|
|
- "analyzer": "english"
|
|
|
- }
|
|
|
- }
|
|
|
- }
|
|
|
- }
|
|
|
-}
|
|
|
----------------
|
|
|
-<1> The two `name` fields have conflicting mappings and will prevent Elasticsearch
|
|
|
- from starting.
|
|
|
-
|
|
|
-Elasticsearch will not start in the presence of conflicting field mappings.
|
|
|
-These indices must be deleted or reindexed using a new mapping.
|
|
|
-
|
|
|
-The `ignore_conflicts` option of the put mappings API has been removed.
|
|
|
-Conflicts can't be ignored anymore.
|
|
|
-
|
|
|
-==== Fields cannot be referenced by short name
|
|
|
-
|
|
|
-A field can no longer be referenced using its short name. Instead, the full
|
|
|
-path to the field is required. For instance:
|
|
|
-
|
|
|
-[source,js]
|
|
|
----------------
|
|
|
-PUT my_index
|
|
|
-{
|
|
|
- "mappings": {
|
|
|
- "my_type": {
|
|
|
- "properties": {
|
|
|
- "title": { "type": "string" }, <1>
|
|
|
- "name": {
|
|
|
- "properties": {
|
|
|
- "title": { "type": "string" }, <2>
|
|
|
- "first": { "type": "string" },
|
|
|
- "last": { "type": "string" }
|
|
|
- }
|
|
|
- }
|
|
|
- }
|
|
|
- }
|
|
|
- }
|
|
|
-}
|
|
|
----------------
|
|
|
-<1> This field is referred to as `title`.
|
|
|
-<2> This field is referred to as `name.title`.
|
|
|
-
|
|
|
-Previously, the two `title` fields in the example above could have been
|
|
|
-confused with each other when using the short name `title`.
|
|
|
-
|
|
|
-=== Type name prefix removed
|
|
|
-
|
|
|
-Previously, two fields with the same name in two different types could
|
|
|
-sometimes be disambiguated by prepending the type name. As a side effect, it
|
|
|
-would add a filter on the type name to the relevant query. This feature was
|
|
|
-ambiguous -- a type name could be confused with a field name -- and didn't
|
|
|
-work everywhere e.g. aggregations.
|
|
|
-
|
|
|
-Instead, fields should be specified with the full path, but without a type
|
|
|
-name prefix. If you wish to filter by the `_type` field, either specify the
|
|
|
-type in the URL or add an explicit filter.
|
|
|
-
|
|
|
-The following example query in 1.x:
|
|
|
-
|
|
|
-[source,js]
|
|
|
-----------------------------
|
|
|
-GET my_index/_search
|
|
|
-{
|
|
|
- "query": {
|
|
|
- "match": {
|
|
|
- "my_type.some_field": "quick brown fox"
|
|
|
- }
|
|
|
- }
|
|
|
-}
|
|
|
-----------------------------
|
|
|
-
|
|
|
-would be rewritten in 2.0 as:
|
|
|
-
|
|
|
-[source,js]
|
|
|
-----------------------------
|
|
|
-GET my_index/my_type/_search <1>
|
|
|
-{
|
|
|
- "query": {
|
|
|
- "match": {
|
|
|
- "some_field": "quick brown fox" <2>
|
|
|
- }
|
|
|
- }
|
|
|
-}
|
|
|
-----------------------------
|
|
|
-<1> The type name can be specified in the URL to act as a filter.
|
|
|
-<2> The field name should be specified without the type prefix.
|
|
|
-
|
|
|
-==== Field names may not contain dots
|
|
|
-
|
|
|
-In 1.x, it was possible to create fields with dots in their name, for
|
|
|
-instance:
|
|
|
-
|
|
|
-[source,js]
|
|
|
-----------------------------
|
|
|
-PUT my_index
|
|
|
-{
|
|
|
- "mappings": {
|
|
|
- "my_type": {
|
|
|
- "properties": {
|
|
|
- "foo.bar": { <1>
|
|
|
- "type": "string"
|
|
|
- },
|
|
|
- "foo": {
|
|
|
- "properties": {
|
|
|
- "bar": { <1>
|
|
|
- "type": "string"
|
|
|
- }
|
|
|
- }
|
|
|
- }
|
|
|
- }
|
|
|
- }
|
|
|
- }
|
|
|
-}
|
|
|
-----------------------------
|
|
|
-<1> These two fields cannot be distinguised as both are referred to as `foo.bar`.
|
|
|
-
|
|
|
-You can no longer create fields with dots in the name.
|
|
|
-
|
|
|
-==== Type names may not start with a dot
|
|
|
-
|
|
|
-In 1.x, Elasticsearch would issue a warning if a type name included a dot,
|
|
|
-e.g. `my.type`. Now that type names are no longer used to distinguish between
|
|
|
-fields in differnt types, this warning has been relaxed: type names may now
|
|
|
-contain dots, but they may not *begin* with a dot. The only exception to this
|
|
|
-is the special `.percolator` type.
|
|
|
-
|
|
|
-==== Types may no longer be deleted
|
|
|
-
|
|
|
-In 1.x it was possible to delete a type mapping, along with all of the
|
|
|
-documents of that type, using the delete mapping API. This is no longer
|
|
|
-supported, because remnants of the fields in the type could remain in the
|
|
|
-index, causing corruption later on.
|
|
|
-
|
|
|
-==== Type meta-fields
|
|
|
-
|
|
|
-The <<mapping-fields,meta-fields>> associated with had configuration options
|
|
|
-removed, to make them more reliable:
|
|
|
-
|
|
|
-* `_id` configuration can no longer be changed. If you need to sort, use the <<mapping-uid-field,`_uid`>> field instead.
|
|
|
-* `_type` configuration can no longer be changed.
|
|
|
-* `_index` configuration can no longer be changed.
|
|
|
-* `_routing` configuration is limited to marking routing as required.
|
|
|
-* `_field_names` configuration is limited to disabling the field.
|
|
|
-* `_size` configuration is limited to enabling the field.
|
|
|
-* `_timestamp` configuration is limited to enabling the field, setting format and default value.
|
|
|
-* `_boost` has been removed.
|
|
|
-* `_analyzer` has been removed.
|
|
|
-
|
|
|
-Importantly, *meta-fields can no longer be specified as part of the document
|
|
|
-body.* Instead, they must be specified in the query string parameters. For
|
|
|
-instance, in 1.x, the `routing` could be specified as follows:
|
|
|
-
|
|
|
-[source,json]
|
|
|
------------------------------
|
|
|
-PUT my_index
|
|
|
-{
|
|
|
- "mappings": {
|
|
|
- "my_type": {
|
|
|
- "_routing": {
|
|
|
- "path": "group" <1>
|
|
|
- },
|
|
|
- "properties": {
|
|
|
- "group": { <1>
|
|
|
- "type": "string"
|
|
|
- }
|
|
|
- }
|
|
|
- }
|
|
|
- }
|
|
|
-}
|
|
|
-
|
|
|
-PUT my_index/my_type/1 <2>
|
|
|
-{
|
|
|
- "group": "foo"
|
|
|
-}
|
|
|
------------------------------
|
|
|
-<1> This 1.x mapping tells Elasticsearch to extract the `routing` value from the `group` field in the document body.
|
|
|
-<2> This indexing request uses a `routing` value of `foo`.
|
|
|
-
|
|
|
-In 2.0, the routing must be specified explicitly:
|
|
|
-
|
|
|
-[source,json]
|
|
|
------------------------------
|
|
|
-PUT my_index
|
|
|
-{
|
|
|
- "mappings": {
|
|
|
- "my_type": {
|
|
|
- "_routing": {
|
|
|
- "required": true <1>
|
|
|
- },
|
|
|
- "properties": {
|
|
|
- "group": {
|
|
|
- "type": "string"
|
|
|
- }
|
|
|
- }
|
|
|
- }
|
|
|
- }
|
|
|
-}
|
|
|
-
|
|
|
-PUT my_index/my_type/1?routing=bar <2>
|
|
|
-{
|
|
|
- "group": "foo"
|
|
|
-}
|
|
|
------------------------------
|
|
|
-<1> Routing can be marked as required to ensure it is not forgotten during indexing.
|
|
|
-<2> This indexing request uses a `routing` value of `bar`.
|
|
|
-
|
|
|
-==== Other mapping changes
|
|
|
-
|
|
|
-* The setting `index.mapping.allow_type_wrapper` has been removed. Documents should always be sent without the type as the root element.
|
|
|
-* The `binary` field does not support the `compress` and `compress_threshold` options anymore.
|
|
|
-
|
|
|
-
|
|
|
-
|
|
|
-
|
|
|
-=== Networking
|
|
|
-
|
|
|
-Elasticsearch now binds to the loopback interface by default (usually 127.0.0.1
|
|
|
-or ::1), the setting `network.host` can be specified to change this behavior.
|
|
|
-
|
|
|
-=== Rivers removal
|
|
|
-
|
|
|
-Elasticsearch does not support rivers anymore. While we had first planned to
|
|
|
-keep them around to ease migration, keeping support for rivers proved to be
|
|
|
-challenging as it conflicted with other important changes that we wanted to
|
|
|
-bring to 2.0 like synchronous dynamic mappings updates, so we eventually
|
|
|
-decided to remove them entirely. See
|
|
|
-https://www.elastic.co/blog/deprecating_rivers for more background about why
|
|
|
-we are moving away from rivers.
|
|
|
-
|
|
|
-=== Indices API
|
|
|
-
|
|
|
-The <<alias-retrieving, get alias api>> will, by default produce an error response
|
|
|
-if a requested index does not exist. This change brings the defaults for this API in
|
|
|
-line with the other Indices APIs. The <<multi-index>> options can be used on a request
|
|
|
-to change this behavior
|
|
|
-
|
|
|
-`GetIndexRequest.features()` now returns an array of Feature Enums instead of an array of String values.
|
|
|
-
|
|
|
-The following deprecated methods have been removed:
|
|
|
-
|
|
|
-* `GetIndexRequest.addFeatures(String[])` - Please use `GetIndexRequest.addFeatures(Feature[])` instead
|
|
|
-* `GetIndexRequest.features(String[])` - Please use `GetIndexRequest.features(Feature[])` instead
|
|
|
-* `GetIndexRequestBuilder.addFeatures(String[])` - Please use `GetIndexRequestBuilder.addFeatures(Feature[])` instead
|
|
|
-* `GetIndexRequestBuilder.setFeatures(String[])` - Please use `GetIndexRequestBuilder.setFeatures(Feature[])` instead
|
|
|
-
|
|
|
-=== Partial fields
|
|
|
-
|
|
|
-Partial fields were deprecated since 1.0.0beta1 in favor of <<search-request-source-filtering,source filtering>>.
|
|
|
-
|
|
|
-=== More Like This
|
|
|
-
|
|
|
-The More Like This API and the More Like This Field query have been removed in
|
|
|
-favor of the <<query-dsl-mlt-query, More Like This Query>>.
|
|
|
-
|
|
|
-The parameter `percent_terms_to_match` has been removed in favor of
|
|
|
-`minimum_should_match`.
|
|
|
-
|
|
|
-=== Routing
|
|
|
-
|
|
|
-The default hash function that is used for routing has been changed from djb2 to
|
|
|
-murmur3. This change should be transparent unless you relied on very specific
|
|
|
-properties of djb2. This will help ensure a better balance of the document counts
|
|
|
-between shards.
|
|
|
-
|
|
|
-In addition, the following node settings related to routing have been deprecated:
|
|
|
-
|
|
|
-[horizontal]
|
|
|
-
|
|
|
-`cluster.routing.operation.hash.type`::
|
|
|
-
|
|
|
- This was an undocumented setting that allowed to configure which hash function
|
|
|
- to use for routing. `murmur3` is now enforced on new indices.
|
|
|
-
|
|
|
-`cluster.routing.operation.use_type`::
|
|
|
-
|
|
|
- This was an undocumented setting that allowed to take the `_type` of the
|
|
|
- document into account when computing its shard (default: `false`). `false` is
|
|
|
- now enforced on new indices.
|
|
|
-
|
|
|
-=== Async replication
|
|
|
-
|
|
|
-The `replication` parameter has been removed from all CRUD operations (index,
|
|
|
-update, delete, bulk). These operations are now synchronous
|
|
|
-only, and a request will only return once the changes have been replicated to
|
|
|
-all active shards in the shard group.
|
|
|
-
|
|
|
-=== Store
|
|
|
-
|
|
|
-The `memory` / `ram` store (`index.store.type`) option was removed in Elasticsearch 2.0.
|
|
|
-
|
|
|
-=== Term Vectors API
|
|
|
-
|
|
|
-Usage of `/_termvector` is deprecated, and replaced in favor of `/_termvectors`.
|
|
|
-
|
|
|
-=== Script fields
|
|
|
-
|
|
|
-Script fields in 1.x were only returned as a single value. So even if the return
|
|
|
-value of a script used to be list, it would be returned as an array containing
|
|
|
-a single value that is a list too, such as:
|
|
|
-
|
|
|
-[source,js]
|
|
|
----------------
|
|
|
-"fields": {
|
|
|
- "my_field": [
|
|
|
- [
|
|
|
- "v1",
|
|
|
- "v2"
|
|
|
- ]
|
|
|
- ]
|
|
|
-}
|
|
|
----------------
|
|
|
-
|
|
|
-In elasticsearch 2.x, scripts that return a list of values are considered as
|
|
|
-multivalued fields. So the same example would return the following response,
|
|
|
-with values in a single array.
|
|
|
-
|
|
|
-[source,js]
|
|
|
----------------
|
|
|
-"fields": {
|
|
|
- "my_field": [
|
|
|
- "v1",
|
|
|
- "v2"
|
|
|
- ]
|
|
|
-}
|
|
|
----------------
|
|
|
-
|
|
|
-=== Main API
|
|
|
-
|
|
|
-Previously, calling `GET /` was giving back the http status code within the json response
|
|
|
-in addition to the actual HTTP status code. We removed `status` field in json response.
|
|
|
-
|
|
|
-=== Java API
|
|
|
-
|
|
|
-`org.elasticsearch.index.queries.FilterBuilders` has been removed as part of the merge of
|
|
|
-queries and filters. These filters are now available in `QueryBuilders` with the same name.
|
|
|
-All methods that used to accept a `FilterBuilder` now accept a `QueryBuilder` instead.
|
|
|
-
|
|
|
-In addition some query builders have been removed or renamed:
|
|
|
-
|
|
|
-* `commonTerms(...)` renamed with `commonTermsQuery(...)`
|
|
|
-* `queryString(...)` renamed with `queryStringQuery(...)`
|
|
|
-* `simpleQueryString(...)` renamed with `simpleQueryStringQuery(...)`
|
|
|
-* `textPhrase(...)` removed
|
|
|
-* `textPhrasePrefix(...)` removed
|
|
|
-* `textPhrasePrefixQuery(...)` removed
|
|
|
-* `filtered(...)` removed. Use `filteredQuery(...)` instead.
|
|
|
-* `inQuery(...)` removed.
|
|
|
-
|
|
|
-=== Aggregations
|
|
|
-
|
|
|
-The `date_histogram` aggregation now returns a `Histogram` object in the response, and the `DateHistogram` class has been removed. Similarly
|
|
|
-the `date_range`, `ipv4_range`, and `geo_distance` aggregations all return a `Range` object in the response, and the `IPV4Range`, `DateRange`,
|
|
|
-and `GeoDistance` classes have been removed. The motivation for this is to have a single response API for the Range and Histogram aggregations
|
|
|
-regardless of the type of data being queried. To support this some changes were made in the `MultiBucketAggregation` interface which applies
|
|
|
-to all bucket aggregations:
|
|
|
-
|
|
|
-* The `getKey()` method now returns `Object` instead of `String`. The actual object type returned depends on the type of aggregation requested
|
|
|
-(e.g. the `date_histogram` will return a `DateTime` object for this method whereas a `histogram` will return a `Number`).
|
|
|
-* A `getKeyAsString()` method has been added to return the String representation of the key.
|
|
|
-* All other `getKeyAsX()` methods have been removed.
|
|
|
-* The `getBucketAsKey(String)` methods have been removed on all aggregations except the `filters` and `terms` aggregations.
|
|
|
-
|
|
|
-The `histogram` and the `date_histogram` aggregation now support a simplified `offset` option that replaces the previous `pre_offset` and
|
|
|
-`post_offset` rounding options. Instead of having to specify two separate offset shifts of the underlying buckets, the `offset` option
|
|
|
-moves the bucket boundaries in positive or negative direction depending on its argument.
|
|
|
-
|
|
|
-The `date_histogram` options for `pre_zone` and `post_zone` are replaced by the `time_zone` option. The behavior of `time_zone` is
|
|
|
-equivalent to the former `pre_zone` option. Setting `time_zone` to a value like "+01:00" now will lead to the bucket calculations
|
|
|
-being applied in the specified time zone but In addition to this, also the `pre_zone_adjust_large_interval` is removed because we
|
|
|
-now always return dates and bucket keys in UTC.
|
|
|
-
|
|
|
-Both the `histogram` and `date_histogram` aggregations now have a default `min_doc_count` of `0` instead of `1` previously.
|
|
|
-
|
|
|
-`include`/`exclude` filtering on the `terms` aggregation now uses the same syntax as regexp queries instead of the Java syntax. While simple
|
|
|
-regexps should still work, more complex ones might need some rewriting. Also, the `flags` parameter is not supported anymore.
|
|
|
-
|
|
|
-=== Terms filter lookup caching
|
|
|
-
|
|
|
-The terms filter lookup mechanism does not support the `cache` option anymore
|
|
|
-and relies on the filesystem cache instead. If the lookup index is not too
|
|
|
-large, it is recommended to make it replicated to all nodes by setting
|
|
|
-`index.auto_expand_replicas: 0-all` in order to remove the network overhead as
|
|
|
-well.
|
|
|
-
|
|
|
-=== Delete by query
|
|
|
-
|
|
|
-The meaning of the `_shards` headers in the delete by query response has changed. Before version 2.0 the `total`,
|
|
|
-`successful` and `failed` fields in the header are based on the number of primary shards. The failures on replica
|
|
|
-shards aren't being kept track of. From version 2.0 the stats in the `_shards` header are based on all shards
|
|
|
-of an index. The http status code is left unchanged and is only based on failures that occurred while executing on
|
|
|
-primary shards.
|
|
|
-
|
|
|
-=== Delete api with missing routing when required
|
|
|
-
|
|
|
-Delete api requires a routing value when deleting a document belonging to a type that has routing set to required in its
|
|
|
-mapping, whereas previous elasticsearch versions would trigger a broadcast delete on all shards belonging to the index.
|
|
|
-A `RoutingMissingException` is now thrown instead.
|
|
|
-
|
|
|
-
|
|
|
-==== Default date format now is `strictDateOptionalTime`
|
|
|
-
|
|
|
-Instead of `dateOptionalTime` the new default date format now is `strictDateOptionalTime`,
|
|
|
-which is more strict in parsing dates. This means, that dates now need to have a four digit year,
|
|
|
-a two-digit month, day, hour, minute and second. This means, you may need to preprend a part of the date
|
|
|
-with a zero to make it conform or switch back to the old `dateOptionalTime` format.
|
|
|
-
|
|
|
-==== Date format does not support unix timestamps by default
|
|
|
-
|
|
|
-In earlier versions of elasticsearch, every timestamp was always tried to be parsed as
|
|
|
-as unix timestamp first. This means, even when specifying a date format like
|
|
|
-`dateOptionalTime`, one could supply unix timestamps instead of a ISO8601 formatted
|
|
|
-date.
|
|
|
-
|
|
|
-This is not supported anymore. If you want to store unix timestamps, you need to specify
|
|
|
-the appropriate formats in the mapping, namely `epoch_second` or `epoch_millis`.
|
|
|
-
|
|
|
-In addition the `numeric_resolution` mapping parameter is ignored. Use the
|
|
|
-`epoch_second` and `epoch_millis` date formats instead.
|
|
|
-
|
|
|
-==== Source field limitations
|
|
|
-The `_source` field could previously be disabled dynamically. Since this field
|
|
|
-is a critical piece of many features like the Update API, it is no longer
|
|
|
-possible to disable.
|
|
|
-
|
|
|
-The options for `compress` and `compress_threshold` have also been removed.
|
|
|
-The source field is already compressed. To minimize the storage cost,
|
|
|
-set `index.codec: best_compression` in index settings.
|
|
|
-
|
|
|
-==== Boolean fields
|
|
|
-
|
|
|
-Boolean fields used to have a string fielddata with `F` meaning `false` and `T`
|
|
|
-meaning `true`. They have been refactored to use numeric fielddata, with `0`
|
|
|
-for `false` and `1` for `true`. As a consequence, the format of the responses of
|
|
|
-the following APIs changed when applied to boolean fields: `0`/`1` is returned
|
|
|
-instead of `F`/`T`:
|
|
|
-
|
|
|
- - <<search-request-fielddata-fields,fielddata fields>>
|
|
|
- - <<search-request-sort,sort values>>
|
|
|
- - <<search-aggregations-bucket-terms-aggregation,terms aggregations>>
|
|
|
-
|
|
|
-In addition, terms aggregations use a custom formatter for boolean (like for
|
|
|
-dates and ip addresses, which are also backed by numbers) in order to return
|
|
|
-the user-friendly representation of boolean fields: `false`/`true`:
|
|
|
-
|
|
|
-[source,js]
|
|
|
----------------
|
|
|
-"buckets": [
|
|
|
- {
|
|
|
- "key": 0,
|
|
|
- "key_as_string": "false",
|
|
|
- "doc_count": 42
|
|
|
- },
|
|
|
- {
|
|
|
- "key": 1,
|
|
|
- "key_as_string": "true",
|
|
|
- "doc_count": 12
|
|
|
- }
|
|
|
-]
|
|
|
----------------
|
|
|
-
|
|
|
-==== Murmur3 Fields
|
|
|
-Fields of type `murmur3` can no longer change `doc_values` or `index` setting.
|
|
|
-They are always stored with doc values, and not indexed.
|
|
|
-
|
|
|
-==== Config based mappings
|
|
|
-The ability to specify mappings in configuration files has been removed. To specify
|
|
|
-default mappings that apply to multiple indexes, use index templates.
|
|
|
-
|
|
|
-The following settings are no longer valid:
|
|
|
-
|
|
|
-* `index.mapper.default_mapping_location`
|
|
|
-* `index.mapper.default_percolator_mapping_location`
|
|
|
-
|
|
|
-=== Codecs
|
|
|
-
|
|
|
-It is no longer possible to specify per-field postings and doc values formats
|
|
|
-in the mappings. This setting will be ignored on indices created before
|
|
|
-elasticsearch 2.0 and will cause mapping parsing to fail on indices created on
|
|
|
-or after 2.0. For old indices, this means that new segments will be written
|
|
|
-with the default postings and doc values formats of the current codec.
|
|
|
-
|
|
|
-It is still possible to change the whole codec by using the `index.codec`
|
|
|
-setting. Please however note that using a non-default codec is discouraged as
|
|
|
-it could prevent future versions of Elasticsearch from being able to read the
|
|
|
-index.
|
|
|
-
|
|
|
-=== Scripting settings
|
|
|
-
|
|
|
-Removed support for `script.disable_dynamic` node setting, replaced by
|
|
|
-fine-grained script settings described in the <<enable-dynamic-scripting,scripting docs>>.
|
|
|
-The following setting previously used to enable dynamic scripts:
|
|
|
-
|
|
|
-[source,yaml]
|
|
|
----------------
|
|
|
-script.disable_dynamic: false
|
|
|
----------------
|
|
|
-
|
|
|
-can be replaced with the following two settings in `elasticsearch.yml` that
|
|
|
-achieve the same result:
|
|
|
-
|
|
|
-[source,yaml]
|
|
|
----------------
|
|
|
-script.inline: on
|
|
|
-script.indexed: on
|
|
|
----------------
|
|
|
-
|
|
|
-=== Script parameters
|
|
|
-
|
|
|
-Deprecated script parameters `id`, `file`, `scriptField`, `script_id`, `script_file`,
|
|
|
-`script`, `lang` and `params`. The <<modules-scripting,new script API syntax>> should be used in their place.
|
|
|
-
|
|
|
-The deprecated script parameters have been removed from the Java API so applications using the Java API will
|
|
|
-need to be updated.
|
|
|
-
|
|
|
-=== Groovy scripts sandbox
|
|
|
-
|
|
|
-The groovy sandbox and related settings have been removed. Groovy is now a non
|
|
|
-sandboxed scripting language, without any option to turn the sandbox on.
|
|
|
-
|
|
|
-=== Plugins making use of scripts
|
|
|
-
|
|
|
-Plugins that make use of scripts must register their own script context through
|
|
|
-`ScriptModule`. Script contexts can be used as part of fine-grained settings to
|
|
|
-enable/disable scripts selectively.
|
|
|
-
|
|
|
-=== Thrift and memcached transport
|
|
|
-
|
|
|
-The thrift and memcached transport plugins are no longer supported. Instead, use
|
|
|
-either the HTTP transport (enabled by default) or the node or transport Java client.
|
|
|
-
|
|
|
-=== `search_type=count` deprecation
|
|
|
-
|
|
|
-The `count` search type has been deprecated. All benefits from this search type can
|
|
|
-now be achieved by using the `query_then_fetch` search type (which is the
|
|
|
-default) and setting `size` to `0`.
|
|
|
-
|
|
|
-=== The count api internally uses the search api
|
|
|
-
|
|
|
-The count api is now a shortcut to the search api with `size` set to 0. As a
|
|
|
-result, a total failure will result in an exception being returned rather
|
|
|
-than a normal response with `count` set to `0` and shard failures.
|
|
|
-
|
|
|
-=== JSONP support
|
|
|
-
|
|
|
-JSONP callback support has now been removed. CORS should be used to access Elasticsearch
|
|
|
-over AJAX instead:
|
|
|
-
|
|
|
-[source,yaml]
|
|
|
----------------
|
|
|
-http.cors.enabled: true
|
|
|
-http.cors.allow-origin: /https?:\/\/localhost(:[0-9]+)?/
|
|
|
----------------
|
|
|
-
|
|
|
-=== CORS allowed origins
|
|
|
-
|
|
|
-The CORS allowed origins setting, `http.cors.allow-origin`, no longer has a default value. Previously, the default value
|
|
|
-was `*`, which would allow CORS requests from any origin and is considered insecure. The `http.cors.allow-origin` setting
|
|
|
-should be specified with only the origins that should be allowed, like so:
|
|
|
-
|
|
|
-[source,yaml]
|
|
|
----------------
|
|
|
-http.cors.allow-origin: /https?:\/\/localhost(:[0-9]+)?/
|
|
|
----------------
|
|
|
-
|
|
|
-=== Cluster state REST api
|
|
|
-
|
|
|
-The cluster state api doesn't return the `routing_nodes` section anymore when
|
|
|
-`routing_table` is requested. The newly introduced `routing_nodes` flag can
|
|
|
-be used separately to control whether `routing_nodes` should be returned.
|
|
|
-
|
|
|
-=== Query DSL
|
|
|
-
|
|
|
-Change to ranking behaviour: single-term queries on numeric fields now score in the same way as string fields (use of IDF, norms if enabled).
|
|
|
-Previously, term queries on numeric fields were deliberately prevented from using the usual Lucene scoring logic and this behaviour was undocumented and, to some, unexpected.
|
|
|
-If the introduction of scoring to numeric fields is undesirable for your query clauses the fix is simple: wrap them in a `constant_score` or use a `filter` expression instead.
|
|
|
-
|
|
|
-The `filtered` query is deprecated. Instead you should use a `bool` query with
|
|
|
-a `must` clause for the query and a `filter` clause for the filter. For instance
|
|
|
-the below query:
|
|
|
-
|
|
|
-[source,js]
|
|
|
----------------
|
|
|
-{
|
|
|
- "filtered": {
|
|
|
- "query": {
|
|
|
- // query
|
|
|
- },
|
|
|
- "filter": {
|
|
|
- // filter
|
|
|
- }
|
|
|
- }
|
|
|
-}
|
|
|
----------------
|
|
|
-can be replaced with
|
|
|
-[source,js]
|
|
|
----------------
|
|
|
-{
|
|
|
- "bool": {
|
|
|
- "must": {
|
|
|
- // query
|
|
|
- },
|
|
|
- "filter": {
|
|
|
- // filter
|
|
|
- }
|
|
|
- }
|
|
|
-}
|
|
|
----------------
|
|
|
-and will produce the same scores.
|
|
|
-
|
|
|
-The `fuzzy_like_this` and `fuzzy_like_this_field` queries have been removed.
|
|
|
-
|
|
|
-The `limit` filter is deprecated and becomes a no-op. You can achieve similar
|
|
|
-behaviour using the <<search-request-body,terminate_after>> parameter.
|
|
|
-
|
|
|
-`or` and `and` on the one hand and `bool` on the other hand used to have
|
|
|
-different performance characteristics depending on the wrapped filters. This is
|
|
|
-fixed now, as a consequence the `or` and `and` filters are now deprecated in
|
|
|
-favour or `bool`.
|
|
|
-
|
|
|
-The `execution` option of the `terms` filter is now deprecated and ignored if
|
|
|
-provided.
|
|
|
-
|
|
|
-The `_cache` and `_cache_key` parameters of filters are deprecated in the REST
|
|
|
-layer and removed in the Java API. In case they are specified they will be
|
|
|
-ignored. Instead filters are always used as their own cache key and elasticsearch
|
|
|
-makes decisions by itself about whether it should cache filters based on how
|
|
|
-often they are used.
|
|
|
-
|
|
|
-Java plugins that register custom queries can do so by using the
|
|
|
-`IndicesQueriesModule#addQuery(Class<? extends QueryParser>)` method. Other
|
|
|
-ways to register custom queries are not supported anymore.
|
|
|
-
|
|
|
-==== Query/filter merge
|
|
|
-
|
|
|
-Elasticsearch no longer makes a difference between queries and filters in the
|
|
|
-DSL; it detects when scores are not needed and automatically optimizes the
|
|
|
-query to not compute scores and optionally caches the result.
|
|
|
-
|
|
|
-As a consequence the `query` filter serves no purpose anymore and is deprecated.
|
|
|
-
|
|
|
-=== Timezone for date field
|
|
|
-
|
|
|
-Specifying the `time_zone` parameter on queries or aggregations of `date` type fields
|
|
|
-must now be either an ISO 8601 UTC offset, or a timezone id. For example, the value
|
|
|
-`+1:00` must now be `+01:00`.
|
|
|
-
|
|
|
-=== Snapshot and Restore
|
|
|
-
|
|
|
-Locations of the shared file system repositories and the URL repositories with `file:` URLs has to be now registered
|
|
|
-using `path.repo` setting. The `path.repo` setting can contain one or more repository locations:
|
|
|
-
|
|
|
-[source,yaml]
|
|
|
----------------
|
|
|
-path.repo: ["/mnt/daily", "/mnt/weekly"]
|
|
|
----------------
|
|
|
-
|
|
|
-If the repository location is specified as an absolute path it has to start with one of the locations
|
|
|
-specified in `path.repo`. If the location is specified as a relative path, it will be resolved against the first
|
|
|
-location specified in the `path.repo` setting.
|
|
|
-
|
|
|
-URL repositories with `http:`, `https:`, and `ftp:` URLs has to be whitelisted by specifying allowed URLs in the
|
|
|
-`repositories.url.allowed_urls` setting. This setting supports wildcards in the place of host, path, query, and
|
|
|
-fragment. For example:
|
|
|
-
|
|
|
-[source,yaml]
|
|
|
------------------------------------
|
|
|
-repositories.url.allowed_urls: ["http://www.example.org/root/*", "https://*.mydomain.com/*?*#*"]
|
|
|
------------------------------------
|
|
|
-
|
|
|
-The obsolete parameters `expand_wildcards_open` and `expand_wildcards_close` are no longer
|
|
|
-supported by the snapshot and restore operations. These parameters have been replaced by
|
|
|
-a single `expand_wildcards` parameter. See <<multi-index,the multi-index docs>> for more.
|
|
|
-
|
|
|
-=== `_shutdown` API
|
|
|
-
|
|
|
-The `_shutdown` API has been removed without a replacement. Nodes should be managed via operating
|
|
|
-systems and the provided start/stop scripts.
|
|
|
-
|
|
|
-=== Analyze API
|
|
|
-
|
|
|
-* The Analyze API return 0 as first Token's position instead of 1.
|
|
|
-* The `text()` method on `AnalyzeRequest` now returns `String[]` instead of `String`.
|
|
|
-
|
|
|
-=== Multiple data.path striping
|
|
|
-
|
|
|
-Previously, if the `data.path` setting listed multiple data paths, then a
|
|
|
-shard would be ``striped'' across all paths by writing a whole file to each
|
|
|
-path in turn (in accordance with the `index.store.distributor` setting). The
|
|
|
-result was that the files from a single segment in a shard could be spread
|
|
|
-across multiple disks, and the failure of any one disk could corrupt multiple
|
|
|
-shards.
|
|
|
-
|
|
|
-This striping is no longer supported. Instead, different shards may be
|
|
|
-allocated to different paths, but all of the files in a single shard will be
|
|
|
-written to the same path.
|
|
|
-
|
|
|
-If striping is detected while starting Elasticsearch 2.0.0 or later, all of
|
|
|
-the files belonging to the same shard will be migrated to the same path. If
|
|
|
-there is not enough disk space to complete this migration, the upgrade will be
|
|
|
-cancelled and can only be resumed once enough disk space is made available.
|
|
|
-
|
|
|
-The `index.store.distributor` setting has also been removed.
|
|
|
-
|
|
|
-=== Hunspell dictionary configuration
|
|
|
-
|
|
|
-The parameter `indices.analysis.hunspell.dictionary.location` has been removed,
|
|
|
-and `<path.conf>/hunspell` is always used.
|
|
|
-
|
|
|
-=== Java API Transport API construction
|
|
|
-
|
|
|
-The `TransportClient` construction code has changed, it now uses the builder
|
|
|
-pattern. Instead of using:
|
|
|
-
|
|
|
-[source,java]
|
|
|
---------------------------------------------------
|
|
|
-Settings settings = Settings.settingsBuilder()
|
|
|
- .put("cluster.name", "myClusterName").build();
|
|
|
-Client client = new TransportClient(settings);
|
|
|
---------------------------------------------------
|
|
|
-
|
|
|
-Use:
|
|
|
-
|
|
|
-[source,java]
|
|
|
---------------------------------------------------
|
|
|
-Settings settings = Settings.settingsBuilder()
|
|
|
- .put("cluster.name", "myClusterName").build();
|
|
|
-Client client = TransportClient.builder().settings(settings).build();
|
|
|
---------------------------------------------------
|
|
|
-
|
|
|
-=== Logging
|
|
|
-
|
|
|
-Log messages are now truncated at 10,000 characters. This can be changed in the
|
|
|
-`logging.yml` configuration file.
|
|
|
-
|
|
|
-[float]
|
|
|
-=== Removed `top_children` query
|
|
|
-
|
|
|
-The `top_children` query has been removed in favour of the `has_child` query. The `top_children` query wasn't always faster
|
|
|
-than the `has_child` query and the `top_children` query was often inaccurate. The total hits and any aggregations in the
|
|
|
-same search request will likely be off if `top_children` was used.
|
|
|
-
|
|
|
-=== Removed file based index templates
|
|
|
-Index templates can no longer be configured on disk. Use the `_template` API instead.
|
|
|
-
|
|
|
-[float]
|
|
|
-=== Removed `id_cache` from stats apis
|
|
|
-
|
|
|
-Removed `id_cache` metric from nodes stats, indices stats and cluster stats apis. This metric has also been removed
|
|
|
-from the shards cat, indices cat and nodes cat apis. Parent/child memory is now reported under fielddata, because it
|
|
|
-has internally be using fielddata for a while now.
|
|
|
-
|
|
|
-To just see how much parent/child related field data is taking, the `fielddata_fields` option can be used on the stats
|
|
|
-apis. Indices stats example:
|
|
|
-
|
|
|
-[source,js]
|
|
|
---------------------------------------------------
|
|
|
-curl -XGET "http://localhost:9200/_stats/fielddata?pretty&human&fielddata_fields=_parent"
|
|
|
---------------------------------------------------
|
|
|
-
|
|
|
-Parent/child is using field data for the `_parent` field since version `1.1.0`, but the memory stats for the `_parent`
|
|
|
-field were still shown under `id_cache` metric in the stats apis for backwards compatible reasons between 1.x versions.
|
|
|
-
|
|
|
-Before version `1.1.0` the parent/child had its own in-memory data structures for id values in the `_parent` field.
|
|
|
-
|
|
|
-[float]
|
|
|
-=== Removed `id_cache` from clear cache api
|
|
|
-
|
|
|
-Removed `id_cache` option from the clear cache apis. The `fielddata` option should be used to clear `_parent` field
|
|
|
-from fielddata.
|
|
|
-
|
|
|
-[float]
|
|
|
-=== Highlighting
|
|
|
-
|
|
|
-The default value for the `require_field_match` option is `true` rather than
|
|
|
-`false`, meaning that the highlighters will take the fields that were queried
|
|
|
-into account by default. That means for instance that highlighting any field
|
|
|
-when querying the `_all` field will produce no highlighted snippets by default,
|
|
|
-given that the match was on the `_all` field only. Querying the same fields
|
|
|
-that need to be highlighted is the cleaner solution to get highlighted snippets
|
|
|
-back. Otherwise `require_field_match` option can be set to `false` to ignore
|
|
|
-field names completely when highlighting.
|
|
|
-
|
|
|
-The postings highlighter doesn't support the `require_field_match` option
|
|
|
-anymore, it will only highlight fields that were queried.
|
|
|
-
|
|
|
-The `match` query with type set to `match_phrase_prefix` is not supported by the
|
|
|
-postings highlighter. No highlighted snippets will be returned.
|
|
|
-
|
|
|
-[float]
|
|
|
-=== Parent/child
|
|
|
-
|
|
|
-Parent/child has been rewritten completely to reduce memory usage and to execute
|
|
|
-`has_child` and `has_parent` queries faster and more efficient. The `_parent` field
|
|
|
-uses doc values by default. The refactored and improved implementation is only active
|
|
|
-for indices created on or after version 2.0.
|
|
|
-
|
|
|
-In order to benefit for all performance and memory improvements we recommend to reindex all
|
|
|
-indices that have the `_parent` field created before was upgraded to 2.0.
|
|
|
-
|
|
|
-The following breaks in backwards compatability have been made on indices with the `_parent` field
|
|
|
-created on or after clusters with version 2.0:
|
|
|
-* The `type` option on the `_parent` field can only point to a parent type that doesn't exist yet,
|
|
|
- so this means that an existing type/mapping can no longer become a parent type.
|
|
|
-* The `has_child` and `has_parent` queries can no longer be use in alias filters.
|
|
|
-
|
|
|
-=== Meta fields returned under the top-level json object
|
|
|
-
|
|
|
-When selecting meta fields such as `_routing` or `_timestamp`, the field values
|
|
|
-are now directly put as a top-level property of the json objet, instead of being
|
|
|
-put under `fields` like regular stored fields.
|
|
|
-
|
|
|
-[source,sh]
|
|
|
----------------
|
|
|
-curl -XGET 'localhost:9200/test/_search?fields=_timestamp,foo'
|
|
|
----------------
|
|
|
-
|
|
|
-[source,js]
|
|
|
----------------
|
|
|
-{
|
|
|
- [...]
|
|
|
- "hits": {
|
|
|
- "total": 1,
|
|
|
- "max_score": 1,
|
|
|
- "hits": [
|
|
|
- {
|
|
|
- "_index": "test",
|
|
|
- "_type": "test",
|
|
|
- "_id": "1",
|
|
|
- "_score": 1,
|
|
|
- "_timestamp": 10000000,
|
|
|
- "fields": {
|
|
|
- "foo" : [ "bar" ]
|
|
|
- }
|
|
|
- }
|
|
|
- ]
|
|
|
- }
|
|
|
-}
|
|
|
----------------
|
|
|
-
|
|
|
-=== Settings for resource watcher have been renamed
|
|
|
-
|
|
|
-The setting names for configuring the resource watcher have been renamed
|
|
|
-to prevent clashes with the watcher plugin
|
|
|
-
|
|
|
-* `watcher.enabled` is now `resource.reload.enabled`
|
|
|
-* `watcher.interval` is now `resource.reload.interval`
|
|
|
-* `watcher.interval.low` is now `resource.reload.interval.low`
|
|
|
-* `watcher.interval.medium` is now `resource.reload.interval.medium`
|
|
|
-* `watcher.interval.high` is now `resource.reload.interval.high`
|
|
|
-
|
|
|
-=== Percolator stats
|
|
|
-
|
|
|
-Changed the `percolate.getTime` stat (total time spent on percolating) to `percolate.time` state.
|
|
|
-
|
|
|
-=== Plugin Manager for official plugins
|
|
|
-
|
|
|
-Some of the elasticsearch official plugins have been moved to elasticsearch repository and will be released at the
|
|
|
-same time as elasticsearch itself, using the same version number.
|
|
|
-
|
|
|
-In that case, the plugin manager can now use a simpler form to identify an official plugin. Instead of:
|
|
|
-
|
|
|
-[source,sh]
|
|
|
----------------
|
|
|
-bin/plugin install elasticsearch/plugin_name/version
|
|
|
----------------
|
|
|
-
|
|
|
-You can use:
|
|
|
-
|
|
|
-[source,sh]
|
|
|
----------------
|
|
|
-bin/plugin install plugin_name
|
|
|
----------------
|
|
|
-
|
|
|
-The plugin manager will recognize this form and will be able to download the right version for your elasticsearch
|
|
|
-version.
|
|
|
-
|
|
|
-For older versions of elasticsearch, you still have to use the older form.
|
|
|
-
|
|
|
-For the record, official plugins which can use this new simplified form are:
|
|
|
-
|
|
|
-* elasticsearch-analysis-icu
|
|
|
-* elasticsearch-analysis-kuromoji
|
|
|
-* elasticsearch-analysis-phonetic
|
|
|
-* elasticsearch-analysis-smartcn
|
|
|
-* elasticsearch-analysis-stempel
|
|
|
-* elasticsearch-cloud-aws
|
|
|
-* elasticsearch-cloud-azure
|
|
|
-* elasticsearch-cloud-gce
|
|
|
-* elasticsearch-delete-by-query
|
|
|
-* elasticsearch-lang-javascript
|
|
|
-* elasticsearch-lang-python
|
|
|
-
|
|
|
-=== `/bin/elasticsearch` version needs `-V` parameter
|
|
|
-
|
|
|
-Due to switching to elasticsearchs internal command line parsing
|
|
|
-infrastructure for the pluginmanager and the elasticsearch start up
|
|
|
-script, the `-v` parameter now stands for `--verbose`, where as `-V` or
|
|
|
-`--version` can be used to show the Elasticsearch version and exit.
|
|
|
-
|
|
|
-=== `/bin/elasticsearch` dynamic parameters must come after static ones
|
|
|
-
|
|
|
-If you are setting configuration options like cluster name or node name via
|
|
|
-the commandline, you have to ensure, that the static options like pid file
|
|
|
-path or daemonizing always come first, like this
|
|
|
-
|
|
|
-```
|
|
|
-/bin/elasticsearch -d -p /tmp/foo.pid --http.cors.enabled=true --http.cors.allow-origin='*'
|
|
|
+include::migrate_2_0/removals.asciidoc[]
|
|
|
|
|
|
-```
|
|
|
+include::migrate_2_0/striping.asciidoc[]
|
|
|
|
|
|
-For a list of those static parameters, run `/bin/elasticsearch -h`
|
|
|
+include::migrate_2_0/mapping.asciidoc[]
|
|
|
|
|
|
-=== Aliases
|
|
|
+include::migrate_2_0/crud.asciidoc[]
|
|
|
|
|
|
-Fields used in alias filters no longer have to exist in the mapping upon alias creation time. Alias filters are now
|
|
|
-parsed at request time and then the fields in filters are resolved from the mapping, whereas before alias filters were
|
|
|
-parsed at alias creation time and the parsed form was kept around in memory.
|
|
|
+include::migrate_2_0/query_dsl.asciidoc[]
|
|
|
|
|
|
+include::migrate_2_0/search.asciidoc[]
|
|
|
|
|
|
-=== _analyze API
|
|
|
+include::migrate_2_0/aggs.asciidoc[]
|
|
|
|
|
|
-The `prefer_local` has been removed from the _analyze api. The _analyze api is a light operation and the caller shouldn't
|
|
|
-be concerned about whether it executes on the node that receives the request or another node.
|
|
|
+include::migrate_2_0/parent_child.asciidoc[]
|
|
|
|
|
|
-=== Shadow replicas
|
|
|
+include::migrate_2_0/scripting.asciidoc[]
|
|
|
|
|
|
-The `node.enable_custom_paths` setting has been removed and replaced by the
|
|
|
-`path.shared_data` setting to allow shadow replicas with custom paths to work
|
|
|
-with the security manager. For example, if your previous configuration had:
|
|
|
+include::migrate_2_0/index_apis.asciidoc[]
|
|
|
|
|
|
-```
|
|
|
-node.enable_custom_paths: true
|
|
|
-```
|
|
|
+include::migrate_2_0/snapshot_restore.asciidoc[]
|
|
|
|
|
|
-And you created an index using shadow replicas with `index.data_path` set to
|
|
|
-`/opt/data/my_index` with the following:
|
|
|
+include::migrate_2_0/packaging.asciidoc[]
|
|
|
|
|
|
-[source,js]
|
|
|
---------------------------------------------------
|
|
|
-curl -XPUT 'localhost:9200/my_index' -d '
|
|
|
-{
|
|
|
- "index" : {
|
|
|
- "number_of_shards" : 1,
|
|
|
- "number_of_replicas" : 4,
|
|
|
- "data_path": "/opt/data/my_index",
|
|
|
- "shadow_replicas": true
|
|
|
- }
|
|
|
-}'
|
|
|
---------------------------------------------------
|
|
|
+include::migrate_2_0/settings.asciidoc[]
|
|
|
|
|
|
-For 2.0, you will need to set `path.shared_data` to a parent directory of the
|
|
|
-index's data_path, so:
|
|
|
+include::migrate_2_0/stats.asciidoc[]
|
|
|
|
|
|
-```
|
|
|
-path.shared_data: /opt/data
|
|
|
-```
|
|
|
+include::migrate_2_0/java.asciidoc[]
|
Clinton Gormley