honeymoose
/
OpenSearch
mirror of https://github.com/honeymoose/OpenSearch.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Remove Outdated Documentation On Snapshots (#59358) (#59585) 

* We now have concurrent repository operations so the one at a time limit does not apply any longer
* Initialization was never slow solely due to loading information about all existing snaphots (though this contributed)
but also because two cluster state updates and a few writes to the repository had to happen before initialization could return
   * Repo data necessary for a snapshot create operation is now cached on heap so loading it is effectively instant
   * Snapshot initialization is just a single CS update now
   * Initialization does no writes to the repository whatsoever
* Fixed missing `repository`
This commit is contained in:
Armin Braun 2020-07-15 07:49:18 +02:00 committed by GitHub
parent 4bb91b61e8
commit ecf97e9415
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 2 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

7
docs/reference/snapshot-restore/apis/create-snapshot-api.asciidoc
View File

@ -45,11 +45,11 @@ cluster, as well as the cluster state. You can change this behavior by
specifying a list of data streams and indices to back up in the body of the
snapshot request.
NOTE: You must register a snapshot before performing snapshot and restore operations. Use the <<put-snapshot-repo-api,put snapshot repository API>> to register new repositories and update existing ones.
NOTE: You must register a snapshot repository before performing snapshot and restore operations. Use the <<put-snapshot-repo-api,put snapshot repository API>> to register new repositories and update existing ones.
The snapshot process is incremental. When creating a snapshot, {es} analyzes the list of files that are already stored in the repository and copies only files that were created or changed since the last snapshot. This process allows multiple snapshots to be preserved in the repository in a compact form.
The snapshot process is executed in non-blocking fashion, so all indexing and searching operations can run concurrently against the data stream or index that {es} is snapshotting. Only one snapshot process can run in the cluster at any time.
The snapshot process is executed in non-blocking fashion, so all indexing and searching operations can run concurrently against the data stream or index that {es} is snapshotting.
A snapshot represents a point-in-time view of the moment when the snapshot was created. No records that were added to a data stream or index after the snapshot process started will be present in the snapshot.
@ -124,9 +124,6 @@ If `true`, allows taking a partial snapshot of indices with unavailable shards.
If `true`, the request returns a response when the snapshot is complete.
If `false`, the request returns a response when the snapshot initializes.
Defaults to `false`.
+
NOTE: During snapshot initialization, information about all
previous snapshots is loaded into memory. In large repositories, this load time can cause requests to take several seconds (or even minutes) to return a response, even if the `wait_for_completion` parameter is `false`.
[[create-snapshot-api-example]]
==== {api-examples-title}