OpenSearch/docs/reference/index-modules/translog.asciidoc

99 lines
4.5 KiB
Plaintext
Raw Normal View History

[[index-modules-translog]]
== Translog
Changes to Lucene are only persisted to disk during a Lucene commit, which is a
relatively expensive operation and so cannot be performed after every index or
delete operation. Changes that happen after one commit and before another will
be removed from the index by Lucene in the event of process exit or hardware
failure.
Because Lucene commits are too expensive to perform on every individual change,
each shard copy also has a _transaction log_ known as its _translog_ associated
with it. All index and delete operations are written to the translog after
being processed by the internal Lucene index but before they are acknowledged.
In the event of a crash, recent transactions that have been acknowledged but
not yet included in the last Lucene commit can instead be recovered from the
translog when the shard recovers.
2015-05-05 15:32:41 -04:00
2015-05-05 16:01:58 -04:00
An Elasticsearch flush is the process of performing a Lucene commit and
starting a new translog. Flushes are performed automatically in the background
in order to make sure the translog doesn't grow too large, which would make
2015-05-05 16:01:58 -04:00
replaying its operations take a considerable amount of time during recovery.
The ability to perform a flush manually is also exposed through an API,
although this is rarely needed.
2015-05-05 16:01:58 -04:00
2015-05-05 15:32:41 -04:00
[float]
=== Translog settings
The data in the translog is only persisted to disk when the translog is
++fsync++ed and committed. In the event of a hardware failure or an operating
system crash or a JVM crash or a shard failure, any data written since the
previous translog commit will be lost.
2015-05-05 15:32:41 -04:00
By default, `index.translog.durability` is set to `request` meaning that Elasticsearch will only report success of an index, delete,
update, or bulk request to the client after the translog has been successfully
++fsync++ed and committed on the primary and on every allocated replica. If
`index.translog.durability` is set to `async` then Elasticsearch ++fsync++s
and commits the translog every `index.translog.sync_interval` (defaults to 5 seconds).
The following <<indices-update-settings,dynamically updatable>> per-index
settings control the behaviour of the translog:
Decouple recoveries from engine flush In order to safely complete recoveries / relocations we have to keep all operation done since the recovery start at available for replay. At the moment we do so by preventing the engine from flushing and thus making sure that the operations are kept in the translog. A side effect of this is that the translog keeps on growing until the recovery is done. This is not a problem as we do need these operations but if the another recovery starts concurrently it may have an unneededly long translog to replay. Also, if we shutdown the engine for some reason at this point (like when a node is restarted) we have to recover a long translog when we come back. To void this, the translog is changed to be based on multiple files instead of a single one. This allows recoveries to keep hold to the files they need while allowing the engine to flush and do a lucene commit (which will create a new translog files bellow the hood). Change highlights: - Refactor Translog file management to allow for multiple files. - Translog maintains a list of referenced files, both by outstanding recoveries and files containing operations not yet committed to Lucene. - A new Translog.View concept is introduced, allowing recoveries to get a reference to all currently uncommitted translog files plus all future translog files created until the view is closed. They can use this view to iterate over operations. - Recovery phase3 is removed. That phase was replaying operations while preventing new writes to the engine. This is unneeded as standard indexing also send all operations from the start of the recovery to the recovering shard. Replay all ops in the view acquired in recovery start is enough to guarantee no operation is lost. - IndexShard now creates the translog together with the engine. The translog is closed by the engine on close. ShadowIndexShards do not open the translog. - Moved the ownership of translog fsyncing to the translog it self, changing the responsible setting to `index.translog.sync_interval` (was `index.gateway.local.sync`) Closes #10624
2015-03-27 05:18:09 -04:00
`index.translog.sync_interval`::
How often the translog is ++fsync++ed to disk and committed, regardless of
write operations. Defaults to `5s`. Values less than `100ms` are not allowed.
`index.translog.durability`::
+
--
Whether or not to `fsync` and commit the translog after every index, delete,
update, or bulk request. This setting accepts the following parameters:
2015-05-05 15:32:41 -04:00
`request`::
2015-05-05 15:32:41 -04:00
(default) `fsync` and commit after every request. In the event
of hardware failure, all acknowledged writes will already have been
2015-10-26 16:43:25 -04:00
committed to disk.
`async`::
`fsync` and commit in the background every `sync_interval`. In
the event of a failure, all acknowledged writes since the last
automatic commit will be discarded.
--
`index.translog.flush_threshold_size`::
The translog stores all operations that are not yet safely persisted in Lucene
(i.e., are not part of a Lucene commit point). Although these operations are
available for reads, they will need to be reindexed if the shard was to
shutdown and has to be recovered. This settings controls the maximum total size
of these operations, to prevent recoveries from taking too long. Once the
maximum size has been reached a flush will happen, generating a new Lucene
commit point. Defaults to `512mb`.
`index.translog.retention.size`::
When soft deletes is disabled (enabled by default in 7.0 or later),
`index.translog.retention.size` controls the total size of translog files to keep.
Keeping more translog files increases the chance of performing an operation based
sync when recovering replicas. If the translog files are not sufficient,
replica recovery will fall back to a file based sync. Defaults to `512mb`
Both `index.translog.retention.size` and `index.translog.retention.age` should not
be specified unless soft deletes is disabled as they will be ignored.
`index.translog.retention.age`::
When soft deletes is disabled (enabled by default in 7.0 or later),
`index.translog.retention.age` controls the maximum duration for which translog
files to keep. Keeping more translog files increases the chance of performing an
operation based sync when recovering replicas. If the translog files are not sufficient,
replica recovery will fall back to a file based sync. Defaults to `12h`
Both `index.translog.retention.size` and `index.translog.retention.age` should not
be specified unless soft deletes is disabled as they will be ignored.