This commit changes the date handling. First and foremost Elasticsearch
does not try to convert every date to a unix timestamp first and then
uses the configured date. This now allows for dates like `2015121212` to
be parsed correctly.
Instead it is now explicit by adding a `epoch_second` and `epoch_millis`
date format. This also means, that the default date format now is
`epoch_millis||dateOptionalTime` to remain backwards compatible.
Closes#5328
Relates #10971
Each shard repository consists of snapshot file for each snapshot - this file contains a map between original physical file that is snapshotted and its representation in repository. This data includes original filename, checksum and length. When a new snapshot is created, elasticsearch needs to read all these snapshot files to figure which file are already present in the repository and which files still have to be copied there. This change adds a new index file that contains all this information combined into a single file. So, if a repository has 1000 snapshots with 1000 shards elasticsearch will only need to read 1000 blobs (one per shard) instead of 1,000,000 to delete a snapshot. This change should also improve snapshot creation speed on repositories with large number of snapshot and high latency.
Fixes#8958
Some settings may be considered sensitive, such as passwords, and storing them
in the configuration file on disk is not good from a security perspective. This change
allows settings to have a special value, `${prompt::text}` or `${prompt::secret}`, to
indicate that elasticsearch should prompt the user for the actual value on startup.
This only works when started in the foreground. In cases where elasticsearch is started
as a service or in the background, an exception will be thrown.
Closes#10838
Currently, when trying to determine if a location is within one of the configured repository
paths, we compare the root path against a normalized path but the root path is never
normalized so the check may incorrectly fail. This change normalizes the root path and
compares it to the other normalized path.
Relates to #11426
documentaiton
Change log entries, add convenience methods, unit tests
Correct allocation decision messages to display used space
Missed a word
Correct displayed threshold value
A `_parent` field can only point to a type that doesn't exist yet.
The validation that checks this relied on have all mappings in the
MapperService. The issue is that this check is performed on the
elected master node and it may not have the IndexService at all
to perform this check. In that case it creates a temporary IndexService and
MapperService to perform mapping validation, but only the mappings
that are part of the put index call are created, not the already existing mappings.
Because of that the `_parent` field validation can't be performed.
By changing the validation to rely on the cluster state's IndexMetaData instead
we can get around the issue with the IndexService/MapperService on the elected
master node. The IndexMetaData always holds the MappingMetaData instances
for all types.
When the dfs phase runs a SearchContext is created on each node that has a shard
for this query. When the query phase (or query and fetch phase) failed that SearchContext
was released only if the query was actually executed on the node. If for example
the query was rejected because the thread pool queue was full then the search context
was not released.
This commit adds a dedicated call for releasing the SearchContext in this case.
In addition, we must set the docIdsToLoad to null in case the fetch phase failed, otherwise
search contexts might not be released in releaseIrrelevantSearchContexts.
closes#11400