| 123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475 | [[index-modules-history-retention]]== History retention{es} sometimes needs to replay some of the operations that were performed on ashard. For instance, if a replica is briefly offline then it may be much moreefficient to replay the few operations it missed while it was offline than torebuild it from scratch. Similarly, {ccr} works by performing operations on theleader cluster and then replaying those operations on the follower cluster.At the Lucene level there are really only two write operations that {es}performs on an index: a new document may be indexed, or an existing document maybe deleted. Updates are implemented by atomically deleting the old document andthen indexing the new document. A document indexed into Lucene already containsall the information needed to replay that indexing operation, but this is nottrue of document deletions. To solve this, {es} uses a feature called _softdeletes_ to preserve recent deletions in the Lucene index so that they can bereplayed.{es} only preserves certain recently-deleted documents in the index because asoft-deleted document still takes up some space. Eventually {es} will fullydiscard these soft-deleted documents to free up that space so that the indexdoes not grow larger and larger over time. Fortunately {es} does not need to beable to replay every operation that has ever been performed on a shard, becauseit is always possible to make a full copy of a shard on a remote node. However,copying the whole shard may take much longer than replaying a few missingoperations, so {es} tries to retain all of the operations it expects to need toreplay in future.{es} keeps track of the operations it expects to need to replay in future usinga mechanism called _shard history retention leases_. Each shard copy that mightneed operations to be replayed must first create a shard history retention leasefor itself. For example, this shard copy might be a replica of a shard or itmight be a shard of a follower index when using {ccr}. Each retention leasekeeps track of the sequence number of the first operation that the correspondingshard copy has not received. As the shard copy receives new operations, itincreases the sequence number contained in its retention lease to indicate thatit will not need to replay those operations in future. {es} discardssoft-deleted operations once they are not being held by any retention lease.If a shard copy fails then it stops updating its shard history retention lease,which means that {es} will preserve all new operations so they can be replayedwhen the failed shard copy recovers. However, retention leases only last for alimited amount of time. If the shard copy does not recover quickly enough thenits retention lease may expire. This protects {es} from retaining historyforever if a shard copy fails permanently, because once a retention lease hasexpired {es} can start to discard history again. If a shard copy recovers afterits retention lease has expired then {es} will fall back to copying the wholeindex since it can no longer simply replay the missing history. The expiry timeof a retention lease defaults to `12h` which should be long enough for mostreasonable recovery scenarios.Soft deletes are enabled by default on indices created in recent versions, butthey can be explicitly enabled or disabled at index creation time. If softdeletes are disabled then peer recoveries can still sometimes take place bycopying just the missing operations from the translog<<index-modules-translog-retention,as long as those operations are retainedthere>>. {ccr-cap} will not function if soft deletes are disabled.[float]=== History retention settings`index.soft_deletes.enabled`::  Whether or not soft deletes are enabled on the index. Soft deletes can only be  configured at index creation and only on indices created on or after 6.5.0.  The default value is `true`.  deprecated::[7.6, Creating indices with soft-deletes disabled is  deprecated and will be removed in future Elasticsearch versions.]`index.soft_deletes.retention_lease.period`::  The maximum length of time to retain a shard history retention lease before  it expires and the history that it retains can be discarded. The default  value is `12h`.
 |