Docs for snapshots as simple archives#86261
Conversation
|
Pinging @elastic/es-docs (Team:Docs) |
|
Pinging @elastic/es-search (Team:Search) |
|
@elasticmachine run elasticsearch-ci/docs |
|
@elasticmachine update branch |
|
@debadair can you give this a look? Thank you. |
javanna
left a comment
There was a problem hiding this comment.
left a couple of questions, LGTM otherwise
| or to rehydrate parts of it. Access to the data is expected to be infrequent, | ||
| and can therefore happen with limited performance and query capabilities. | ||
|
|
||
| For this, {es} now has the ability to access older snapshot repositories |
| - <<ip,`ip` type>> | ||
| - <<geo-point,`geo_point` type>> | ||
| - <<date,`date` types>>: the date `format` setting on date fields is supported | ||
| in so far as it behaves similarly across these versions. In case it is not, |
There was a problem hiding this comment.
what do you mean with "is supported in so far as it behaves similarly across these versions"?
There was a problem hiding this comment.
We have changed the meaning of various custom date formats / date literals across versions (e.g. year of era becomes week-based year), see https://www.elastic.co/guide/en/elasticsearch/reference/7.17/migrate-to-java-time.html#java-time-migration-incompatible-date-formats
Perhaps I could link to the above for additional context, as well as limit the scope of the problem to "custom date formats".
There was a problem hiding this comment.
sounds good to expand a bit, thanks.
There was a problem hiding this comment.
do you mean "is supported as long as it behaves similarly across versions"?
| can't make sense of the mapping, it falls back to a lightweight import of | ||
| the mapping where the original mapping is stored in the _meta section of | ||
| the imported index's mapping, and relies on the user to put the relevant | ||
| mapping parts manually in place. |
There was a problem hiding this comment.
I wonder if this is enough guidance for users to solve problems when importing the mappings. what's your thinking?
There was a problem hiding this comment.
I can clarify the process a bit more (e.g. user can inspect the original mapping using get mappings API, and use put mappings API to add selected portions back to index). Additionally I would like to ask users to report failures to auto-import mapping to us (but with the expectation that we will treat it as low-priority items to be fixed).
There was a problem hiding this comment.
sounds great, I was also wondering if users know what you mean with "_meta" section. I would have to look it up myself :)
|
The release highlight changelog (cea2469) seems to have been deleted by our automation. I will add it for the backport to 8.3 branch and mark that backport PR then as release highlight. |
| be manually put in place using the <<indices-put-mapping,update mapping>> API, | ||
| copying and adapting relevant sections of the legacy mapping to work with the | ||
| current {es} version. While auto-import is expected to work in most cases, | ||
| failures of doing so should be raised with the Elastic team for future |
| - <<ip,`ip` type>> | ||
| - <<geo-point,`geo_point` type>> | ||
| - <<date,`date` types>>: the date `format` setting on date fields is supported | ||
| in so far as it behaves similarly across these versions. In case it is not, |
There was a problem hiding this comment.
do you mean "is supported as long as it behaves similarly across versions"?
| this field can be updated on legacy indices so that it can be changed by a | ||
| user if need be. | ||
| - <<keyword-field-type,`keyword` type>>: the `normalizer` setting on keyword | ||
| fields is supported in so far as it behaves similarly across these versions. |
There was a problem hiding this comment.
here too "is supported as long as..."
| In case it is not, this field can be updated on legacy indices if need be. | ||
| - <<text-field-type,`text` type>>: scoring capabilities are limited, and all | ||
| queries return constant scores that are equal to 1.0. The `analyzer` | ||
| settings on text fields are supported in so far as they behave similarly |
|
Thanks @javanna! |
Adds documentation for the new snapshots as archive feature. Relates elastic#81210
Adds documentation for the new snapshots as archive feature.
Relates #81210