Manage the search context of underlying "scroll" during reindex api call

(Vchalmel) #1

Hi !
I got search context loss errors during a reindex.

I imagine the reindex api uses a underlying scroll that fails, can I tune it when calling the reindex api ? Something similar to the scroll parameter ?

(Mark Harwood) #2

Without seeing the detail of the errors my guess is that you lost contact with one of the replicas that was servicing your query. The scroll effectively "locks" a point-in-time for your client which means a particular set of files on each shard are preserved from any background merging etc that might otherwise clear these away on a replica. If you fail to return within an allotted time window or the replica becomes disconnected your view is not preserved and we can't continue to scroll through the same files hence the failure.

(Vchalmel) #3

I don't think so, the cluster is very stable.
However there were writings on the index while it was reindexing, isn't that allowed ?

(Mark Harwood) #4

That is permitted. Writes just end up in new segment files that are not in the view scope. Your client may have exceeded the timeout you stated as part of the scroll API which dictates how long its view of the data will be held to service your requests. I'm not sure how a timeout error manifests itself but it could be the loss of shard context you saw.

(Vchalmel) #5

The scroll timeout is part of elastic configuration or defined when calling the reindex api ? Found nothing about it in the manual.

(system) #6