You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: specification/_global/open_point_in_time/OpenPointInTimeRequest.ts
+36-8Lines changed: 36 additions & 8 deletions
Original file line number
Diff line number
Diff line change
@@ -33,13 +33,40 @@ import { Duration } from '@_types/Time'
33
33
* between searches are only visible to the more recent point in time.
34
34
*
35
35
* A point in time must be opened explicitly before being used in search requests.
36
-
* The `keep_alive` parameter tells Elasticsearch how long it should persist.
36
+
*
37
+
* A subsequent search request with the `pit` parameter must not specify `index`, `routing`, or `preference` values as these parameters are copied from the point in time.
38
+
*
39
+
* Just like regular searches, you can use `from` and `size` to page through point in time search results, up to the first 10,000 hits.
40
+
* If you want to retrieve more hits, use PIT with `search_after`.
41
+
*
42
+
* IMPORTANT: The open point in time request and each subsequent search request can return different identifiers; always use the most recently received ID for the next search request.
43
+
*
44
+
* When a PIT that contains shard failures is used in a search request, the missing are always reported in the search response as a `NoShardAvailableActionException` exception.
45
+
* To get rid of these exceptions, a new PIT needs to be created so that shards missing from the previous PIT can be handled, assuming they become available in the meantime.
46
+
*
47
+
* **Keeping point in time alive**
48
+
*
49
+
* The `keep_alive` parameter, which is passed to a open point in time request and search request, extends the time to live of the corresponding point in time.
50
+
* The value does not need to be long enough to process all data — it just needs to be long enough for the next request.
51
+
*
52
+
* Normally, the background merge process optimizes the index by merging together smaller segments to create new, bigger segments.
53
+
* Once the smaller segments are no longer needed they are deleted.
54
+
* However, open point-in-times prevent the old segments from being deleted since they are still in use.
55
+
*
56
+
* TIP: Keeping older segments alive means that more disk space and file handles are needed.
57
+
* Ensure that you have configured your nodes to have ample free file handles.
58
+
*
59
+
* Additionally, if a segment contains deleted or updated documents then the point in time must keep track of whether each document in the segment was live at the time of the initial search request.
60
+
* Ensure that your nodes have sufficient heap space if you have many open point-in-times on an index that is subject to ongoing deletes or updates.
61
+
* Note that a point-in-time doesn't prevent its associated indices from being deleted.
62
+
* You can check how many point-in-times (that is, search contexts) are open with the nodes stats API.
0 commit comments