Shrink Index APIedit

Resize Requestedit

The Shrink API requires a ResizeRequest instance. A ResizeRequest requires two string arguments:

ResizeRequest request = new ResizeRequest("target_index","source_index"); 

The target index (first argument) to shrink the source index (second argument) into

Optional argumentsedit

The following arguments can optionally be provided:

request.timeout(TimeValue.timeValueMinutes(2)); 
request.timeout("2m"); 

Timeout to wait for the all the nodes to acknowledge the index is opened as a TimeValue

Timeout to wait for the all the nodes to acknowledge the index is opened as a String

request.masterNodeTimeout(TimeValue.timeValueMinutes(1)); 
request.masterNodeTimeout("1m"); 

Timeout to connect to the master node as a TimeValue

Timeout to connect to the master node as a String

request.setWaitForActiveShards(2); 
request.setWaitForActiveShards(ActiveShardCount.DEFAULT); 

The number of active shard copies to wait for before the shrink index API returns a response, as an int

The number of active shard copies to wait for before the shrink index API returns a response, as an ActiveShardCount

request.setCopySettings(true); 

Use true to copy the settings from the source index to the target index. This cannot be false. If this method is not used, default behavior is not to copy. This parameter will be removed in 8.0.0.

request.getTargetIndexRequest().settings(Settings.builder()
        .put("index.number_of_shards", 2) 
        .putNull("index.routing.allocation.require._name")); 

The settings to apply to the target index, which include the number of shards to create for it

Remove the allocation requirement copied from the source index

request.getTargetIndexRequest().alias(new Alias("target_alias")); 

The aliases to associate the target index with

Synchronous Executionedit

When executing a ResizeRequest in the following manner, the client waits for the ResizeResponse to be returned before continuing with code execution:

ResizeResponse resizeResponse = client.indices().shrink(request, RequestOptions.DEFAULT);

Synchronous calls may throw an IOException in case of either failing to parse the REST response in the high-level REST client, the request times out or similar cases where there is no response coming back from the server.

In cases where the server returns a 4xx or 5xx error code, the high-level client tries to parse the response body error details instead and then throws a generic ElasticsearchException and adds the original ResponseException as a suppressed exception to it.

Asynchronous Executionedit

Executing a ResizeRequest can also be done in an asynchronous fashion so that the client can return directly. Users need to specify how the response or potential failures will be handled by passing the request and a listener to the asynchronous shrink-index method:

client.indices().shrinkAsync(request, RequestOptions.DEFAULT, listener); 

The ResizeRequest to execute and the ActionListener to use when the execution completes

The asynchronous method does not block and returns immediately. Once it is completed the ActionListener is called back using the onResponse method if the execution successfully completed or using the onFailure method if it failed. Failure scenarios and expected exceptions are the same as in the synchronous execution case.

A typical listener for shrink-index looks like:

ActionListener<ResizeResponse> listener = new ActionListener<ResizeResponse>() {
    @Override
    public void onResponse(ResizeResponse resizeResponse) {
        
    }

    @Override
    public void onFailure(Exception e) {
        
    }
};

Called when the execution is successfully completed.

Called when the whole ResizeRequest fails.

Shrink Index Responseedit

The returned ResizeResponse allows to retrieve information about the executed operation as follows:

boolean acknowledged = resizeResponse.isAcknowledged(); 
boolean shardsAcked = resizeResponse.isShardsAcknowledged(); 

Indicates whether all of the nodes have acknowledged the request

Indicates whether the requisite number of shard copies were started for each shard in the index before timing out