Rollover Index API
editRollover Index API
editRollover Request
editThe Rollover Index API requires a RolloverRequest
instance.
A RolloverRequest
requires two string arguments at construction time, and
one or more conditions that determine when the index has to be rolled over:
RolloverRequest request = new RolloverRequest("alias", "index-2"); request.addMaxIndexAgeCondition(new TimeValue(7, TimeUnit.DAYS)); request.addMaxIndexDocsCondition(1000); request.addMaxIndexSizeCondition(new ByteSizeValue(5, ByteSizeUnit.GB));
The alias (first argument) that points to the index to rollover, and the name of the new index in case the rollover operation is performed. The new index argument is optional, and can be set to null |
|
Condition on the age of the index |
|
Condition on the number of documents in the index |
|
Condition on the size of the index |
Optional arguments
editThe following arguments can optionally be provided:
request.getCreateIndexRequest().waitForActiveShards(ActiveShardCount.from(2)); request.getCreateIndexRequest().waitForActiveShards(ActiveShardCount.DEFAULT);
Sets the number of active shard copies to wait for before the rollover index API returns a response |
|
Resets the number of active shard copies to wait for to the default value |
String mappings = "{\"properties\":{\"field-1\":{\"type\":\"keyword\"}}}"; request.getCreateIndexRequest().mapping(mappings, XContentType.JSON);
Add the mappings to associate the new index with. See Index mappings for examples on the different ways to provide mappings |
Synchronous execution
editWhen executing a RolloverRequest
in the following manner, the client waits
for the RolloverResponse
to be returned before continuing with code execution:
RolloverResponse rolloverResponse = client.indices().rollover(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 execution
editExecuting a RolloverRequest
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 rollover-index method:
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 rollover-index
looks like:
Rollover Response
editThe returned RolloverResponse
allows to retrieve information about the
executed operation as follows:
boolean acknowledged = rolloverResponse.isAcknowledged(); boolean shardsAcked = rolloverResponse.isShardsAcknowledged(); String oldIndex = rolloverResponse.getOldIndex(); String newIndex = rolloverResponse.getNewIndex(); boolean isRolledOver = rolloverResponse.isRolledOver(); boolean isDryRun = rolloverResponse.isDryRun(); Map<String, Boolean> conditionStatus = rolloverResponse.getConditionStatus();
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 |
|
The name of the old index, eventually rolled over |
|
The name of the new index |
|
Whether the index has been rolled over |
|
Whether the operation was performed or it was a dry run |
|
The different conditions and whether they were matched or not |